DO’S and DON’TS in Communication Between Developer and QA Engineer
By: Kuprii Yuliia
Tags: Development, QA, Communication, Team, Product

After years of being a QA Engineer, I decided to share some tips about communication with Developers. Here are my observations regarding that.

❌ DON’TS

Don’t distract a developer if it’s not urgent. Don’t come over to its desk right away. Ask via messenger first or schedule a meeting in advance. I realized that once I started coding myself. When you go with a flow and someone distracted you it takes a lot of time and energy to deep dive into this state of mind again. Such interruptions don’t add productivity at all.

Don’t be afraid to ask for help. You cannot know everything, and it’s OK to ask because it’s better than pretend you’re cool! Just make sure you understood the answer and don’t ask the same question twice. We are on the same boat and it will be good for everyone if each person has a paddle and we can move on to one direction.

Don’t trust a Developer’s words. You need to find evidence to a Developer’s confidence of “everything should be fine!”, or “I changed one string in the code, it won’t break anything”.

Don’t blame. It’s a road to anywhere. Don’t stick to the negative, try to solve the problem. Later we can decide how to avoid a particular case in the future. No one is perfect. Mistakes are inevitable. The main goal is to have the ability to react healthily and do your job.

Don’t assign a particular Developer to a defect. The same way as Developers close tickets without QA’s approval, it might piss off, period.

Don’t micro-manage Developers. “Did you check the defect?”, “How about now?”, “When you will fix the bug?”. It’s annoying and they don’t solve the problem faster. Just put yourself in Developers’ place.

Don’t take things too close to your heart and grow thick skin. Being emotional in a bad way is the shortest way to burnout. Don’t allow your feelings to be over good sense. You might stumble with arrogant people that you have to deal with. It can be applied to anyone actually. That is why thick skin is a must as well as tactfulness.

✅ DO’S

Exchange knowledge with a Developer. Let them know about your testing approaches, find the “access_key” for every Developer you have to work with. Provide information about how you are going to test the product. It can help to avoid part of bugs. However, it’s not always possible for a couple of reasons. First, lack of time. Second, company processes don’t allow to do that. And lastly, the Developer’s unwillingness to cooperate with someone for many reasons. But, if you could find the “access_key” I mentioned above it will be easier to maintain a healthy relationship and quite good product quality in a long run.

Learn to convince. It’s a useful skill if you want to work in an environment that can be improved a little bit for QA needs. Find support and bring your plans into reality. However, if you feel lonely in your statements, perhaps the idea you want to incorporate is not that great. So, don’t convince for a sake of convincing. Accept the fact you’re not always right and learn to listen and hear people around you.

Be honest. Otherwise, it will destroy your reputation very quickly. Or eventually. That depends on how a good liar you are. Won’t recommend it.

Be ready to defend defects you report. Sometimes you have to defend the importance of defects that need to be fixed. But you have to be sure in your statement. Through time it gets better as you bring up some real facts and reasons why the defect must be fixed. The ability to see a few steps further can help to save the company’s money.

Stay cold-minded under pressure. I know, it’s hard. When everyone keeps rushing you or your team it is difficult to resist against authorities. However, to say “No” is a part of our job, even if it’s not a popular opinion. This rule doesn’t work if someone pushed you to a wall or pointing a gun at your head.

Discuss test cases with the Developer. From my experience, it is very difficult to do. It requires time and dedication from both sides. As well as charisma and the ability to convince from the QA side. I’ve been up to this for a while and yet I couldn’t incorporate this approach. I see a huge benefit from such talks with a developer. However, I might not see something else that would tell me the opposite. What do you think?

Be precise in the defect description. Speak in the developer’s language if you can. In other cases keep your writing as simple as possible. It should be “lagom” in a Swedish way. Good sizing, structure, informative for a Developer and sufficient enough to remember what is a bug about and test the fix by the creator or any other tester in the team.

Encourage teammates to have a deep understanding of the product. Such awareness in the team will reduce the amount of silly defects. From my experience, silly bugs drain a lot of energy to report them. It’s better to predict those and focus on the more important stuff. Instead of reporting about wrong font-size test edge cases, security, performance, etc.

Be patient. Not everyone is pleasant, learn to cope with difficult, narcissistic people. It’s a general rule applicable to anyone.