Bugs provide unique tools for communication of problems between QA and engineers. Too often, QA engineers enter environments where bugs are written like this:
Title: Something broke
Description: I did some stuff, it broke, I don’t quite know what, or how it broke, but I swear it broke. Developers fix this, it’s super important!
Obviously the above bug report is awful. Zero information is provided to developers or other app-owners. Over time I’ve found a good format for writing good quality, reproducible bugs. This format is system independent, so can be used in nearly any Bug Tracking system(Mozilla, JIRA, Trac, Test director, etc etc). It does take into assumption that some fields are available on the bug tracking system. If they aren’t, just put “Field name:
Title: This is a general description of the bug in 1 sentence or less
Priority: The bug priority, usually ranked 1->5 or trivial->blocker. Different organizations have different descriptions of each priority type but I like to stick with the following for myself:
(1)Blocker: Testing can not continue, the system is down, some unrecoverable state. There is no work around.
(2)Critical: Testing can not continue down this path, but there may be a work around.
(3)Major: Testing can continue, but this is a client visible issue that will bite us sometime in the future. It might impact a large client
(4)Minor: Testing can continue, no large client impact.
(5)Trivial: Spelling mistakes, grammar, image problems, etcetera
Steps to Reproduce: This is a numerical list of the exact steps you took to reproduce the bug. If the bug is not reproducible following these steps, the bug should not be filed. I can’t stress the importance of filing reproducible bugs. For example to “Save As” a document in Microsoft Word 2010 the steps are
1) Click File
2) Click Save As
3) Enter a file name in the file name field
4) Click save
Actual Results: This is where you write down what actually happened. For the above steps the actual results are:
The file was saved
Expected Results: This is where you write down what you expected to happen. The above steps had the expected result:
File should be saved
The above fields are a bare minimum for filing any bug on any system. Things like screenshots, attachments, firebug results, stack traces, etc are always useful but if the bug is truly reproducible with the steps provided above, are extraneous information.