The First Bug Martin Jansson
Last week I entered the first bug in a bug system for a new service that I just started to work on. Me and my team spent quite some time in getting it right, setting the standard for bugs to come. If the first bug is crappy, the rest can be as well. We considered the format, what was included in form of logs etc, how to reference to the build, the configuration setup, the ever so important title and the to-the-point-repro-steps. We did not add any expected result, it was too obvious. If had, it would have made some of the stakeholders go Duh! most probably. We even tried to make sure that the pinpointing task would be so much easier. As I see it, we made a good case for getting it prioritzed to get fixed.
I even set up some guidelines on how to report bugs with some nice references to BBST Advocacy course and other great materials from blogs.
Being first has its advantages. You set the level of expectation and hopefully you set your own ambition for what is to come.
Good start!
Well-written bug reports typically has quite a big impact on developers’ view of testers.
When I start reporting bugs I also am very careful about the order of them; I want to report something really important first, and minor ones as a tail (to avoid someone thinking I am looking for trivial stuff.
Yes, I agree. This time the developer was with us when we reported the bug. The one entered was the most important one as he saw it.