Don’t be the bearer of bad news

An inevitable action in our lives often requires us to give a piece of unwanted news to someone we don’t really want to give it to.

Whether it’s telling them they didn’t get a job, their car has a flat tyre, or they have a grubby mark on their face. No-one wants to give someone some news they’d rather not hear or be the person who is seen to be criticising the actions of someone else.

Software testing can be difficult sometimes for this reason. The bug reports we raise and the very nature of the job can often be seen as a negative activity to developers.

And I can understand why, if a developer writes a piece of software and they’re proud of what it does and how it was constructed. It can be quite deflating for them to see a tester to get a hold of it and raise six bug reports in quick succession.

However, it is important to remember that evaluating software and reporting bugs is part of the job as a tester. It comes with the territory and is never a personal attack on the developer’s abilities or skills.

While the relationship with the development team can be strained at times. It doesn’t have to be that way. We are all human beings after all, and we all require them same things in life to make a healthy relationship work.

So what can we do to shift the mindset of a developer from “Here we go again…”. when they see a tester approaching their desk with a problem. To one that allows them to see that testers are providing valuable insight into the quality of the software and testing isn’t such a negative activity.

Shift the tone.

Here’s a scenario. A tester lands at your desk with a problem they have discovered.

“Hey, I just tested x feature, and it doesn’t work properly. I’m raising a bug report, but I just wanted to give you a head up that we need to get it fixed.”


“Hey, how was your weekend? Awesome, I loved that movie you recommended. I just thought I’d stop by and mention that I’m testing x and I’m noticing a few problems. I’m raising a bug report. But there are a few things not working. Could you possibly look?”

The second option is the way I think most of us would prefer to receive some bad news.

First, the tester is opening up with a conversation. A standard opener, but this isn’t just an excuse to use a little small talk.

Psychologically, this will enable the developer to associate the tester not just as a source of a problem, but as a friend and a source of positive feedback in the team.

Also, the tone of the message is changed from “here’s a problem I’m notifying you of,”. To “Here’s a problem, let’s solve it together”.

Testers are not developers enemy

We are all trying to achieve the same outcome and arrive at the same destination. We just have different modes of transportation.

Collaborate with your development team, make them understand the issues you are raising and the process you went through to discover the bug you are reporting.

It may also be useful for a member of the development team to sit with QA for a few hours and see what you do to get a better understanding. They will have likely had little experience on the QA side of things (depending on their background), so this would be a great learning opportunity for them.

So in conclusion, try to open up to your development team in a way that they see you not as a source of problems. But as a friendly team who provide important insight into the quality of their software and no just a source of problems.

Posted by Kevin Tuck

Kevin Tuck is an ISTQB qualified software tester with nearly a decade of professional experience. Well versed in creating versatile and effective testing strategies. He offers a variety of collaborative software testing services. From managing your testing strategy, creating valuable automation assets, or serving as an additional resource.

Leave a Reply