Finding bugs is easy, reporting them is where a lot of up and coming testers get in trouble. A defect report that is too long can be just as bad as one that is too short. Developers are instant gratification junkies, and do not want to read 5 paragraphs of information that may or many not relate to the issue at hand. After reading a dozen bug essays, anyone will say “just get to the point!”

On the other extreme, I’ve seen a bug report that read “The application is broken.”

So, here are some small pointers to anyone who wants to write better bug reports.

First:
The best format for writing a defect seems to be

• Brief description (Subject)
• Detailed description
• Steps to reproduce

Second:
A lot of defect tracking applications give you a subject text field. Use it! It’s very helpful to scan through hundreds of defects without having to read each one all the way through. Describe the bug in one sentence in the subject line giving plenty of information but not going too far into detail.

Example:
Good: Registering a duplicate user does not give “user already exists” error
Good: Page layout breaks in Internet Explorer, but looks good in Firefox

Bad: 12:30PM on Staging server, user registers once, registration successful, user registers a second time with same username, the registration page does not break

Third:
Detailed description is a description of the defect that is much more in-depth then the subject line. However, don’t go over board, if you can’t describe the defect in 4 sentences, you do not know what the defect is!

Fourth:
Finally, the steps need to be nice and detailed. A list of 1 line commands that are easy to follow. You will be surprised how often a defect cannot be replicated if not done in exact sequence.

Example:

1. Navigate to login page
2. Type in valid username
3. Leave password blank
4. Submit
5. User is logged into the application, no error is given
   

Fifth:
Always, always, always, always! include a screenshot of the issue. It’s not hard, does not take a lot of space, and your developers will thank you for it

Sixth:
Only include the information that is relevant to the defect. If the issue happens on all the browsers, you do not have to mention each one of them individually. However, if the issue happens only on one sound card out of a hundred, do report the discrepancy. The idea is to reduce the white noise as much as possible.

Seventh:
Required fields are important, and don’t forget to fill them out appropriately; or suffer the fate of the defect being dropped into obscurity. Go look in your current bug-base, how many defects have been untouched for months because you forgot to assign it to the appropriate team.

Eight:
If you cannot replicate the defect THREE (3) times in the row, the bug does not exist. There is rarely a good reason to insert a defect into bug-base if you do not fully understand it. If you can’t replicate it each time, you don’t understand it.

Ninth:
Contrary to what some people will say, it is “OK” to have a joke somewhere in the defect. But don’t get carried away. Never insult a developer with your defect, or write anything you will regret the whole company seeing. This is just common sense.

Tenth:
No one who is not trained in the above rules is allowed to add defects into the database! It is much more efficient and productive to have the Salesperson show you the defect in action, and let you type it up, then to let them do it.

Example of good defect report

Subject: Forgot password does not recognize valid email accounts on IE6

Body: When the user attempts to submit the forgot your password link in Internet Explorer 6, the username is not recognized. Internet Explorer 7 and Firefox all work just fine

Step:

1. Use IE6
2. Go to home page
3. Click on “Forgot Password” link
4. Type in valid email
5. Submit
6. Receive error
   

   Error