Logging Bugs Like a Pro

Tips and hints for reporting bugs more effectively.

This article serves as a brief guide on best practices when it comes to reporting bugs. Encouraging QA testers, clients, and other project stake-holders to follow these habits makes life easier for the development team when it comes to tracking down and fixing a bug. The end result is less time wasted in going back-and-forth finding out the details of a bug. The act of submitting a bug in a formalised way is very important – having a record of the bug means it wont get lost or go away. The other benefit is someone has clearly taken responsibility for dealing with the problem (i.e. a bug should be assigned to a person).



When submitting a bug, it’s a good idea to give it a short, descriptive title. It may seem like a chore, but it assists developers to quickly identify what a bug is when looking at a list of bug titles. It also helps in future when trying to recall what an old bug was about.

To create a good title, all you need to do is think to yourself “what exactly is the problem?” The first thing that pops into your mind is usually a good title. Examples of good bug titles would be: ‘my login details aren’t being saved’, ‘the photo gallery page crashes in IE’, or ‘tax totals on invoice report are not accurate’. Some examples of unhelpful titles would be: ‘error on page’, ‘the system is busted', or ‘the system doesn’t work when I use it’. A good bug title may also include what screen the error occurs on and describe only one problem at a time (e.g. “sign-up page crashes when I enter a long username”).

Probably the most important aspect of a helpful bug report is to give the steps required to reproduce the problem. All you need to do is give a step-by-step account of what you were doing when the bug appeared.

For example;

* Login as a standard user
* Go to ‘My Profile’
* In the ‘Surname’ field, enter O’Brien
* Click the ‘Save’ button.

You’ll see the page has a script error and doesn’t save the surname.

Example of an unhelpful bug report;

There’s something wrong with the profile page. It crashes, my computer reboots, and the cat goes and scratches the couch.

A few simple habits can enhance a bug submission significantly. For instance; using asterisks as bullets, giving just enough detail to be able to recreate the bug (one line is unlikely to help, a novella adds little benefit), and, at the end of the steps, say what went wrong (e.g. “the page has an error”, “data goes missing”).

When logging a bug, a priority rating is often assigned to it. Most bug tracking systems have choices like low, normal, or high. A low priority bug would be something which just looks bad (e.g. a spelling mistake, misaligned controls, etc). A high priority bug would be a page crash, data corruption, or vanishing data. All other bugs would fall into the category of normal. An accurate priority rating is worthwhile since it allows more pressing bugs to be fielded first (e.g. it would be more important to fix a broken login page before a UI issue).



Occasionally, a situation may occur where it’s hard to tell if something really is a bug, it may instead best be categorised as a ‘feature addition’. As a general rule of thumb, its a bug if; a script error occurs, data goes missing or is corrupted, the system behaves in a manner in which it was not intended too (i.e. not to spec).