How to write an Effective Bug Report - Part 1

Use some reporting tool of your choice like Bugzilla. There are many free reporting tools available, some of the useful links are as follows,

Bugzilla

Bug Genie

Three free bug-tracking tools
126 Hand-picked Defect Tracking Tools
9 Free And Open Source Bug Tracking Softwares

1. After installing bug tracking software, do read its Bug Reporting Guidelines section, it will really help.

2. Select component, platform, OS etc

3. Set priority (most of the times it is assumed the duty of a tester but its logically incorrect).

4. Set severity
Here arise some questions like, What is priority? What is severity? What is the difference between priority and severity? What considerations should one have in his mind while setting priority and severity?

Severity is the one that states how bad or critical, is the bug. It is usually reported by the tester to the developing team. Priority is the level that determines which bug needs to be fixed first, whether it is of high priority or can it be resolved (not fixed in this release) or can it Wait (low level), it is usually determined by the developing team or the Project Manager. For details on severity and priority you can click here.

5. Summary should be precise and compact. A good summary should quickly and uniquely identify a bug, means after reading summary reader gets an idea about the whole bug just like the name of a novel gives you an idea about what you are going to read in next 500 pages.

6. Description should contain comprehensive details. Here your first audience, the developer who fixes the bug, needs clear and unambiguous steps to follow in order to reproduce the symptoms. The more information you provide the better it should be. The developer needs precise detail about “what you did” and “what you saw”. Your second audience, the person or group who decides the fate of the bug, needs to understand the consequences of choosing not to fix the bug. This audience needs information that can grab their attention and also help them see implications of not fixing the bug at the time you reported it. So the key point here is, that your description should be clear and easy to understand, do not use big difficult words so that the developer needs to consult a dictionary to understand the bug :)

Here I want to divide description in two portions, Without Screen-shot and With Screen-shot.

	1.	In first case (Without Screen-shot) Write complete description in the description area and do not attach any screen-shot with it. In this case somehow it will become difficult for the tester (reporter at the moment) to report and cover the bug completely and at the same time developer also faces some difficulty while understanding the bug, I am not saying that developer didn’t understand your point in the bug but he have to spend more time to understand and may be bored while reading the bug. As a reporter it is your duty to convince the developer to read the whole text or focus on your reported bug.
	2.	About the second case (With Screen-shot) I will tell you a very effective way to attract the developer in my next blog (because this one is becoming very lengthy) and that is very important, so don’t miss that.

7. Do not report two bugs in a single bug report, in this case developers fix one bug and leave the other, I had been a victim to this.