Every tester is familiar with the characteristics of a good bug report. Tons of blog entries and articles have been published about what makes a bug report good and what is advisable to avoid.
A bug report for me is like a sheet music. When someone reads it can replay its content without any misunderstanding. Musical symbols describe pitch, rhythm, tempo just like the “steps to reproduce” section in the bug report with just enough information.
Misreading can happen.
“The hardest thing to see is what is in front of your eyes.” – Friedrich Schiller
We all are limited by many things. But we are blessed with the gift of getting ourselves beyond our own limitations.
There is a big responsibility on the one’s shoulder when it comes to raising an issue. Have you ever felt the weight of it?
If you have ever been asked about any of your bug report that you raised, there is definitely something that should be improved in your bug reporting skill.
And let’s face it, it is a lucky scenario when the bug reporter was around who could provide more information or clarification. Who knows how much time was spent on trying to understand the bug report before the question was actually asked. Time is precious, why not to spend it wisely?
While sheet music contains ‘just enough information’, how much is the ‘just enough information’ at bug reports?
Too detailed step description won’t hurt, you might say.
What I say is that the reader can lose the attention easily. There still should be enough to give the context and reproducing issue contains no guesswork.
Understating the description of expected result could cause even bigger problems.
It can happen that the tester is not familiar with the product well enough, the statements in the expected result are not valid and contradict to product requirements. In this case, it is up to the developer to validate the bug report, which is unfortunate if that developer is a newbie in a distributed team. So much time can be wasted here.
The other tricky area is at setting the priority/severity incorrectly.
Working on a poorly categorized not so urgent issue distracts attention and time from resolving serious problems, while released known issue that sits in the backlog somewhere has a bad impact on the reputation of the product.
If you are confident in your bug reporting skills, I have a challenge for you:
Search for an issue that you have reported a year ago.
Is there anything that could have been written in a better way?