Get the bugs fixed
Get the bugs fixed

A Bugging Bug Report

It was an early Tuesday morning. The sun was shining through the windows warming up the air as I was walking down hallway to get my daily morning coffee. The office was quiet and calm and was only lit up by the sunshine reflecting off the small particles of dust floating around. I greeted a few of my colleagues who were staring into their screens with a mumbling “Good morning” and a brief smile as I passed by.
As I got closer to the coffee area I could hear the machine rumble as it was most likely brewing a steaming hot espresso. I remember thinking how glad I was that my desk was not located close enough to hear this all day, and then I heard a surprisingly lively discussion for such an early hour. It was Anna and Bree, two of the testers in my team. Anna seemed a bit agitated over something.
“Good luck with getting that one fixed.” Anna smirked and rolled her eyes. “I’ve reported lots of bugs to that team but they NEVER fix them!
“Oh?” Bree looked slightly surprised. “I’ve had no problems with getting my bugs fixed. I usually get my bugs fixed from that team”.
Anna frowned. She looked at Bree suspiciously and asked loudly: “Really? HOW?”
“Uhm, I report the bug in our system and then I go and talk to them”
Anna was clearly annoyed. “But I do that too! How come you get your bugs fixed, and I don’t?!”

Why aren’t the bugs taken care of?
This was not the first time I came across bugs not getting fixed. In my experience I would say it is quite common. But the question is: Is this a problem?
There are many definitions of a bug. I personally like this definition: “Anything that threatens the value of the product. Something that bugs someone whose opinion matters “(reference James Bach http://www.satisfice.com/glossary.shtml#Bug).
When bugs don’t get fixed, it might be a problem. There may also be many reasons for this. In Anna’s case, there were many potential reasons worth considering both from Anna’s perspective and from the receiver of the bug report’s perspective:
— The receiver didn’t like Anna.
— The receiver didn’t trust Anna.
— The receiver did not understand the bug report.
— The receiver did not have the time to try to reproduce the bug.
— Anna had a bad attitude when informing about the bug she found.
— The bug couldn’t be reproduced.
— The bug seemed unrealistic: “A user would never do that”.
— It wasn’t a bug. It’s was a feature.
— It wasn’t a bug. The feature was not yet implemented.
— It would take too much time to fix the bug.
— The bug was too risky to fix.
——–

In Anna’s and Bree’s case the main reason turned out to be communication. When I started to analyze the situation, most of the bug reports Anna filed were lacking information about the problem. It was not clear to the programmers how to reproduce the bug. A few times they did not understand what the bug was about. When Anna communicated face to face with the programmers, they did not trust her. The programmers did not find her story compelling because most of the time Anna just stumbled upon a bug and was not able to tell them how she found the bug. Often Anna would just attach the error log in her bug report hoping the programmers could tell her what went wrong.

Bree on the other hand managed to write her bug reports with just enough information for the programmers to reproduce the bugs. What stood out the most was Bree’s ability to highlight some of the potential consequences of the bug.

Was there a problem here? Did it need to be addressed? Yes! I found one example where Anna had found had found a severe bug which was very difficult to reproduce. Because of her inability to clearly communicate how to reproduce the bug and what the potential consequences might be if the bug was not addressed, it didn’t get fixed and was found in production.

The problem was not isolated to Anna. This was a very important project, and so there were many poorly written bug reports being created by concerned stakeholders from outside the testing team.

Eventually, the problem with bug report quality became so serious that the project manager limited access to only include members of the project team. He became concerned about all the time being spent to understand and reproduce the reported bugs. On the other hand this resulted in loss of important information in an early stage of the development of the product.

Getting your bugs fixed
I have plenty of similar stories and events such as the one just told. They all have one thing in common, serious bugs not getting fixed.

As a tester, you will likely be remembered by the bugs you find. A bug report can then be considered one of the most important products that you produce.
You may be remembered as the lousy tester who files hundreds of poorly written bug reports. Or you may be remembered as the heroic tester who found some rather serious bugs and helped save your company’s reputation and your customer’s businesses. Who would you prefer to be?

If you want to be the latter I recommend you have a look at e.g. Bug Advocacy to learn more about the subject. http://www.testingeducation.org/BBST/bugadvocacy/

 

https://i0.wp.com/www.testingcircus.com/wp-content/uploads/bug-software-testing-circus.jpg?fit=500%2C356&ssl=1https://i0.wp.com/www.testingcircus.com/wp-content/uploads/bug-software-testing-circus.jpg?resize=150%2C150&ssl=1Maria KedemoArticlesTest Report,Testing ArticleA Bugging Bug Report It was an early Tuesday morning. The sun was shining through the windows warming up the air as I was walking down hallway to get my daily morning coffee. The office was quiet and calm and was only lit up by the sunshine reflecting off the...