Couple of weeks ago I realised something. As an Agile tester it’s really hard to communicate bugs! Testers are known for bringing bad news, but it is not easy to do it correctly. Specially when you’re in a Scrum Team and the heat is really on with bugs or issues flying all around.
Imagine you are selling your house and a potential buyer is coming to check out your property within one hour. Your home is a complete mess and you really need to clean the house. You start straight away and work hard to get the job done. You’re vacuuming every corner and you’re polishing every vase on the table. Quality without compromise keeps popping in your head. Then your real estate agent comes in and checks the place out. You hear him mumble while he’s investigating your home. You’ve done the best you can and then he starts telling you what you’ve done wrong. He tells you that the potential buyer is totally into Feng Shui and he thinks the place doesn’t look in balance at all. It’s kind of frustrating isn’t it? How could you possibly know? Think about how you would you react to your agent.
Some people avoid seeing or bringing bad news altogether. They put them off as long as possible and sometimes dodge them. If you really want to be successful and competent at what you do, you should not be afraid of receiving and communicating bad news. Real winners actually try to spot them as soon as possible. Winners are up for challenges and they deal with them.
In traditional waterfall projects testers work together testing the product. But there is no challenge in communicating bugs through Excel sheets or other electronic tools. It does not talk back or show emotions. Communicating them with your testing teammates isn’t hard either. You are all on the same “testing” side. Which is totally a bad practice in my opinion. In Software Development there should not be any sides. We build software together. We are all involved in changing people’s lives. I’ve met some testers who really didn’t care about faults or bugs in the product. They did not show any engagement with the product. Some of those testers were actually happy about finding a bug and were excited to show how it’s broken. This is bad…
There are many ways to deal with bad news. But the most important thing is we should stop avoiding bad news. Maybe it’s a no brainer, but stop finding excuses! Force yourself out of this habit. Yes, it’s painful, that sinking feeling in your stomach when you find out that things aren’t going like it supposed to. And yes, such pain is difficult to invite into your process. But in this situation it’s absolutely necessary. Bring on the bad news. Seek it out. Speculate on its possible sources.
Garbage In, Garbage Out
When you want to communicate an issue to a developer, try to understand that there might be a possibility that the required functionality is not well explained or understood. Garbage In, Garbage Out… Developers are already struggling with writing code. Don’t blame anyone for not knowing every little thing. Also communicate your finding with a concrete example. Being abstract confuses the situation even more, so show (or write down) the steps to reproduce the issue.
Everyone is responsible
Make sure you are not the only one reporting bad news or issues. Testing should be a team effort. Everyone should be involved with testing in order to get more insight of the product. Automating your tests will help, but try to build them with the whole team so everyone is engaged getting the testing/checking right. When something bad happens the whole team, including the tester, is responsible for not knowing this upfront.
It is not the symptoms of the problem that must be treated, but the cause
When you receive a bug from your teammate. Don’t fix it straight away. Try to find out where it came from and why you it occured this late. Most of the times it’s because of some obvious assumption you’ve made during your work. Make sure you verify and communicate any assumption with your teammates.
Help developers test
Recurring issues should be avoided. But when it happens don’t be too negative about it when you communicate this issue (again). When you see an issue coming back after a bug fix, try to help the developers build an automated (unit) test. Explain to your teammate why it’s important to make sure that this problem does not happen again.
Overcoming bad news
One of the things I’ve noticed working with “winning” Scrum teams is that they overcame any bad news / problems. Call them Agile or not, I don’t care. The team (including testers, developers, business analysts, etc) knew that there would be a large number of obstacles to be thrown into their path. Ignoring bugs was unacceptable. They tried to know as much as they could about the problem and formulate a strategy to “defeat” the situation. Communicating bad news lead them to stop wasting resources on a less important effort. They preferred to know about problems standing in the way of key users sooner rather than later.