Soft skills

Tips for talking with developer

• Sometimes tester encountered issues when talking to developers. Among the reasons are :
  • Imposter syndrome
  • Language barrier
  • Experience gap
  • Lack of confidence

Here how you can communicate effectively with developers:

1. Tester are not the enemies to the developer
   • Some believes tester is the opposing forces in the teams and bottleneck to teams.
   • Instead, both skilled engineers doing specific jobs to help create the same thing, which is great working software for your customers.
   • The software tester's job is to professionally critique a developer's work. Doing that can make it feel as if you're purposefully nitpicking at times. But the aim are basically the same thing which is to deliver good, realiable and high quality software
2. Ask question
   • Developers usually enjoy talking about their work. Ask and document it for your referrences next time. We dont want to keep asking the same thing over again.
   • Admit if you dont have knowledge about something related to the ticket, by doing this maybe can spark conversation and have a session together with dev to do pair testing.
3. Collabrate
   • Ask how things work and maybe show you examples of code
4. Understand their position
   • See things from their POV
   • Avoid using dismissive language i.e How hard can it be? It just a small fix
   • Be clear and concise in explaining your founding
5. Dont be a rockstar tester
   • Rockstar tester → testers who have approached developers with lists of bugs and Post-Its and huge grins on their faces.
   • Be kind and constructive when deliver the bug/issue found.

Building team communication skills

1. Its okay to disagree
   • As a software tester, your opinion and your mission on the project might be completely different to other people's such as your development team, your business analyst, or even your product owner.
   • A team works best when everyone is honest and admitting that you don't agree something is part of that. Just bear in mind that ultimately, you can disagree with something, but you may need to accept that a manager or a product owner may see things differently.
   • Example:
     • Let's say that you've identified a bug. This bug isn't serious now, but it's serious enough that you're unhappy about it. You raise it, but no one agrees it's worth spending time to fix. You disagree, the devs disagree and you get yourself an impasse.
     • This is where constructive escalation comes in. The manager or product owner would take everything onboard and then decide what to do.
     • There's a chance that your bug will get ignored as non-critical or simply not a bug at all. At this point, it's important that you accept this. That's the project manager's decision, and their decision is kind of final.
     • As a tester, yours was to raise the bug and advocate its fixing. If it's getting ignored, all you can do is note it down.
2. Be nice where you can
   • Be nice where you can, but don't be a pushover.
   • It's important that you set your own boundaries for this kind of thing. Doing this means that not only are you letting people know what your boundaries are, but you may also find out what theirs are too.
3. Communicating verbally
   • Talking not only brings you closer to your peers, but also encourages sharing.
   • If working remotely, maybe can schedule a call , share your screen and have a meaningful collabration between you and your developer/team members
   • Human connection and interaction is the best way to build that team feeling.

Quality responsibility