How to be a bug reporting superstar

“A good bug report is one that describes the problem well enough that anyone can understand and reproduce the bug, regardless of their individual knowledge of the product and without talking to the person who wrote it.”

Anyone wanting to be involved with the testing of software needs to be skilled in writing bug reports that can effectively capture the details of a problem in a way that is useful to the rest of the group.

The rest of the group means other developers, project managers, product managers, testers, people who are both technical and non-technical but need to understand the nature and severity of the problem so that they can organize, plan, and take appropriate action.

Lets take a look at what is needed in a bug report and why:

1. A descriptive title

One that contains specific key words and terms to enable categorization.

not good: “Page does not load”
good: “ Contact us page - Server 500 Error when clicking on My Account”

2. The test environment details

In which the problem was found – the specific system, device, or OS, and any relevant configuration options for the test environment. This identifies if the bug is environment specific.

? build # of the product under development
? type of hardware on which test was run, e.g. iPhone, iPad, Mac
? configuration of hardware, e.g. 8Gb iPhone 3G, 32Gb iPad 3G
? OS version / build # on that hardware
? any special conditions, e.g. on wifi, after low battery warning

3. Bug Type

Choose the correct Bug Type for the issue, for example whether it is functional, GUI or Technical. This will identify who the bug should be assigned to.

4. A set of steps

To recreate the situation. These should start with the first thing you do like “1. point browser to www.domain.com”, include any relevant configuration steps, be atomic, be specific, end with the action that causes the problem to be visible.

Ensure all steps are clear and concise, for example:

1. Point Browser to www.domain.com
2. Click “My Account”
3. Enter email “[email protected]” into email textbox
4. Enter password “password” into password textbox
5. Click “Go”…

While these steps may sometimes seem unnecessary, they are very valuable when you want to verify the bug and even more so when there is more than 1 tester testing the product. When a bug has been fixed it will be put back to the testing team to verify the fix and the only way to ensure the bug is fixed is by running the exact same steps as the original bug, without these steps you can not guarantee the consistency of the tests run.

5. The expected behaviour, and why you expected this specific behaviour.

This leads to more Aha! moments than you would imagine. Many of the details left out of the description will appear here.

6. The actual behaviour

This allows the rest of the group to identify if this is actually a bug or if the product is working as designed.

7. The severity of the issue.

When this happens, how bad is it?

It’s important to be clear on your reasoning as to why you have given the severity you have, so that others can understand and support your decision. One note to remember, your job as a tester is to give the bug a severity level THIS IS NOT PRIORITY – it is the Stakeholders/Project Managers decision to give the bug a priority level which will take into consideration many things including the severity you have given.

8. The frequency of the issue.

How often does this occur? Always? Once?

The general nature of a problem is often not enough to characterize that problem. One also needs to know the frequency. Is a crash always a Critical bug? No, not if it was only seen once in 6 months of development. Is a pixel alignment issue always Minor? No. not when it appears at an obvious point in every launch. Frequency can make a big difference to the overall severity and therefore priority of a problem.

9. Evidence

Some of the evidence that you could supply is as follows:

? A user story this allows anyone reviewing your bug to identify what you are trying to do and also puts the bug into a scenario
? Screenshots
? Video/recorded screenshare
? Log Files (especially for iOS)
? Browser matrix (if web based testing – a list of all browsers that are affected by the bug)

Although the above may seem like it requires a lot of time and work, an extra minute spent adding the above information to a bug report can stop the back and forth between development team and tester along with hours of engineering time, if it keeps someone from investigating the wrong thing, on the wrong device, without knowing that it only happens on the local network with yesterday’s build.

The details above also give management a clear picture of the issue, and enable them to make good decisions about the priority of bug fixes. It’s good to know that the bug that Marketing is freaking out about happened only once, on an old build, and on prototype hardware.

You’ll find that bugs that are clear, especially those that provide a test case in the form of a sample project, will get investigated and resolved more quickly. You will also build credibility as a tester and you will be taken more seriously in your role.