Escaping the Communication Black Hole in QA — Dev relationship
I’ve begun my software development career about 13 years ago and I am convinced that IT world is not so perfect, as people may think. From unrealistic deadlines and ridiculous requirements, to poor project management and small budgets, all these can turn perspective project into a nightmare.
Proper team relationships (I am talking about an ability to listen and hear each other) can not only save project from failure but also helps to unify the development process. Of course, one of the most controversial relationships is between QA and Dev.
It’s hard to believe, but this is a very common situation. Nobody talks about how QA should interact with developers and how developers should interact with QA. So, I will try to bring the light on communication between QA and developers and explain how you can unify project development thanks to QA-Dev relationship
Recently, we’ve developed a big project for enterprise company and one of the biggest issues for me was communication with QA. I spend so much time trying to understand what was the essence of the request and what I supposed to do. Sometimes I felt like one of the three monkeys in “Don’t See, Don’t Hear, Don’t Speak”. The reason of such misconception was simple. Tickets were very one-sided, describing only what’s wrong rather than what’s expected, it was difficult to figure out the right direction to move on.
Reporting a bug seems a very simple task. In the ideal world when QA engineers find a bug, they create a report in a tracking system. But in the reality they just contact developers directly by email or messenger to discuss a bug. But let’s dive into this process a bit deeper.
How long it takes to fix a bug?
It depends on how complex the bug is. Usually, reproducing a bug is the most difficult part. I am not talking about simple cases like “fix a wrong title” or “add a missing comma”.
For example, let’s analyze the bug with wrong currency conversion when you have a multi-currency online store. How the bug report might look?
Very likely it will say “There is a wrong price in the block on a product page”. And that’s it, just a short info about the bug without providing the idea of how this should work and why it’s actually wrong. As a result, developer needs to contact QA with a question — how to reproduce it? And both will spend near 15–20 minutes on a small meeting to discuss a very simple thing.
Instead, bug report might look like this:
How to reproduce:
1. Login as test@test.com user
2. Go to customer settings
3. Change customer currency to EUR
4. Go to product detail page (SKU: AB101010)
5. Pay attention to the top price block.
Current Result:
Product price is $98.01
Expected Results:
Product price should be €80
Sure, such a report takes more time to write (QA needs to find a way to reproduce a bug with 100% result). But let’s do some calculations:
Report a bug — 10 minutes (only QA involved)
Try to reproduce a bug — up to 1 hour (only Developer involved)
Discuss with developer — 20 minutes (QA and Developer involved)
Fix a bug — 30 minutes (only Developer involved)
In total: 10 + 60 + 20 + 20 + 30 = 140 minutes. 2 hours and 20 minutes in total
Using bug report scheme that includes reproducing instructions would save a ton of time. Let’s calculate:
Provide a “good” bug report — 20 minutes (only QA involved)
Try to reproduce a bug — 10 minutes (only Developer involved)
Fix a bug — 30 minutes (only Developer involved)
In total: 20 + 10 + 30 = 60 minutes.
As you see, such a methodology saves about 1 hour and 20 minutes (which is insane!). For the developers (and employers) time is the most valuable resource so it makes no sense to encourage a workflow where developers need to spend time on boring things. Yes, they can, but every employer would prefer not to pay for work that resulted because of inefficient process.
Besides, QA saves some time as well so it’s a win-win situation.
Another problem we avoid in this case is distraction. If you ask a developer to make a list of top 10 things they hate the most, distraction will be one of them. In case of using improved bug report template, QA and developers don’t distract each other. They both work independently using bug tracking system.
I can talk infinitely about what programmers hate (years of experience have left their mark), but let’s get back to where we’ve started. While working on a project, I’ve set a limit for myself — 5 minutes to reproduce a bug. And if I couldn’t reproduce it in 5 minutes I’d resolve it with an explanation “can’t reproduce”.
Sure, such an approach did not satisfy QA. This situation caused some tension and we needed a solution. After a productive brainstorming we came up with an easy and efficient solution:
Each bug report must contain only three fields:
- How to reproduce a bug?
- Current results.
- Expected results.
Just three simple steps, help us improve our interaction in several times
At the beginning it was difficult for QA to switch to a new format. But when they got used to it, bug reporting (and fixing) process became smooth as never before. The next release was launched in time and without overtimes. Now we continue working on this project using improved bug report template and it works like a charm for us.
In the next article, I’ll describe how to make releases predictable.
