As a
programmer I am not only in charge of creating
code high up on the
scale of cool but also maintaining code. Creating new code, and the
maintenance of old code invariably creates
bugs,
mis-features, and
warts, be them intentional or not. As I
work in a medium sized company, we have a small
QA team that is in charge of making sure that such bugs are reported and fixed.
Using our bug tracking software we get bug reports and respond to them in a web based interface. Sometimes bug reports leave something to be desired.
Examples of Bad Bug Reports
- "Product doesn't work." -- You expected otherwise
- "When I load up settings stuff is sent to the console." -- So it's not supposed to do that? That's not my component anyway!
- "Bug happened again." -- That's nice, mind actually giving me information I can use?
- "The main screen doesn't look right." -- So?
- "Oh I didn't do anything special, it just happened." -- This reminds me of my tech support days when people told me "I didn't change anything!"
- "Do you want me to show you?" -- No, I want you to tell me what you did to do it.
Reports such as these are either marked invalid (best case senario) or the developers have to spend their time tracking down and trying to duplicate sometimes un-reproducable bugs (worst case senario).
Based on an excellent page at http://www.joelonsoftware.com/articles/fog0000000029.html there are 3 (and only 3) things a bug report should have in it:
- Steps to reproduce
- What you expected to see
- What you saw instead
Using these simple pieces of information a programmer can not only see exactly what went wrong, but can generally deduce where the problem is. Any of these three items is semi-useful on it's own, but all three combined togeather are almost assured to make your developers smile and get your bugs squashed faster.