Don’t forget when commenting bugs

Be explicit when reporting bugs!

Some aspects unsaid, others unclear, missing and fuzzy reproduction steps. All things that contribute to decreasing the quality of bug reports and comments, which eventually can slow down a tester’s (and a dev’s!) work.

Here’s a little list of what I think shouldn’t be missing when describing or commenting a bug:

  • Build number: explicitly write the build number in which you found the bug or you used to verify it has been fixed.
  • Use plain English: its not kool if u write it like this. It’s actually annoying. Also, a proper use of punctuation will increase readability.
  • No abbreviations/acronyms – unless you expand them first.
  • Clear reproduction steps: even though you think a step is obvious, write it. It might not be that obvious when you – or someone new – will have to test the bug again after three months.
  • Bonus: if the bug has to undergo triaging, write a very brief summary (“Still present”, “Looks good yet some other problems appeared”) right after the build number and left some empty lines below it (so it’s visually separated from the rest). You’d be amazed how much time you will save.

The starting point

Start Your Engines - by marksweb

Start Your Engines – by marksweb

I love testing, and I’d really like to get better and better at it.

That’s why I’ve decided to start this blog. To write about the aspects of the job I’d like to pinpoint, create some sort of personal best-practices, eventually hone my skills, and, who knows, generate some reaction and engage in new conversations with fellow testers.