QAcommunication
6 min
It’s Not a Bug, It’s a Feature – Communication Challenges Faced by Developers and Testers
There are many misunderstandings between testers and developers in their daily work. We’ve gathered our experiences to show you some common triggering situations that can be easily solved. It takes a bit of work from both sides but the friendly atmosphere at work is worth it.
How to report a bug?
It is obvious that how we report a bug has an impact on the developer’s reaction.
I’ve noticed that sometimes junior developers feel like a bug is their mistake. This is a challenge to report an issue in such a way that the dev can feel that a bug belongs to all of us. How to do this?
I think this is a difficult question. All of us are different, but there are some rules QA should follow. Firstly I think we should consider if we need to contact the software developer or just create a new bug in our issue tracker. Let’s focus on the first one as the second is easy.
Sometimes it’s better to write or talk with a developer about an issue. The receipt is easy: remember that a bug is ours, not mine or yours. With this mindset, the relationship will be much simpler.
Before you decide to ping a developer you should be sure that your bug is a bug. After that, provide details and conduct the conversation as if you were talking about a common goal.
But it's not a bug…
It happens that you hear “it's not a bug”. You can protect yourself from this kind of response in several ways. For example by reproducing the bug path several times or by reading the documentation carefully. But no matter what you do, sometimes it just happens, and there are two possible paths to what will happen next.
In fact, it's a bug. If you are sure of your right, you will have to prove it somehow to a developer. Prepare a set of evidence like relevant parts of the documentation, feature requirements, and ticket description or if you don't have any of them, prepare a good explanation of why the raised issue is painful for end users. Yet don't try to “kill” anyone with your evidence, it's really not the point. Try to have a constructive conversation and work together on achieving a similar point of view.
During my career, I've been several times in a situation, where despite my huge effort and certainty, the issue I raised has been marked as non-bug. I ’ve presented the requirements from the feature ticket, I’ve pointed out an inconsistency in the software, I’ve explained why the given behavior of the app might be confusing to users, and all of this went for nothing. It was just moved to “Won’t do”, end of the story. The only comment on that is if you ever face a similar situation, you should keep in your head that you did your best and you can’t fix everything.
And what if it's really not a bug? It may happen that you will miss some details that distort your point of view, or you just won’t foresee some use cases because you are fresh in a project. Try to learn a lesson from it for the future.
Which bug is a real bug?
It’s really common for testers to raise absolutely everything they consider as an issue. In general, it's not bad behavior, but if you do so, you have to be prepared that some of those raised issues will be instantly closed or will get lost in the depths of the backlog. Don’t take it personally. It might be that current priorities or business goals are not allowing us to spend time on some minor issues. The knowledge of what is worth raising and what is not comes to us in parallel with our experience in a given project, and sooner or later we will know which decision is the correct one.
Who is guilty?
In the past, I was working with a team who always was wondering who is guilty after a bug occurred in production. We had some meetings to talk about it and the official goal of these meetups was to consider how to avoid such situations. Very good idea, but in practice, the guilty one was always sought. I felt like only one person could be responsible for a bug. In this case, the dev always felt guilty. I didn’t feel comfortable with it.
From my point of view, the whole team is responsible for a bug. We are a squad, we work together and we share responsibility. In my opinion, it is very important to know about it and work in that way. Otherwise, a team will never be a well-coordinated one. Try to imagine how to report a bug to the person who treats it like an offense.
Refresh the page
Not only QA should follow some behavior rules. I’m sure that every tester at the beginning of their career path heard “refresh the page” after finding a bug. I don’t know why devs are telling this, but it’s definitely annoying and spoiling the relationship. For sure, software testers refreshed this page quite a few times. 🙂
Sometimes even if the tester checks every path and is sure that THIS IS A BUG and tells about it in a very polite way, the developer still can’t take it. The same is with QAs, sometimes devs have the right that a bug is not a bug, but the tester doesn’t want to accept it. From my point of view, there should be a team lead role to maybe organize some workshops which will allow you to look at your relationship from a different perspective.
Mind your attitude
It’s crucial to know what and why you are doing it. A common misconception across junior testers is having a conviction that the more passive-aggressive you are, the better. Or that being a QA is about pointing out someone's errors and bragging about it. I’ve met a guy who was working in an IT company, but in a non-technical position. He was thinking about switching to a technical position and he chose a QA role as his development path. During our conversation, I heard a magical sentence from him: “Finally, I will be paid for pointing out someone's errors”. And he was not joking 🙂.
Keep calm and carry on
It’s not a piece of cake to build a strong relationship between developers and testers, but with a little bit of flexibility from both sides, it is possible to achieve something really well-working.