Golden rules for bug reporting

Introduction
Read these simple golden rules for bug reporting. They are based on years of practical testing experience and solid theory.
Make one change request for every bug
- This will enable you to keep count of the number of bugs in the application
- You'll be able to give a priority on every bug separately
- You'll be able to test each resolved bug apart (and prevent having requests that are only resolved half)

Give step by step description of the problem:
E.g. "- I entered the Client page
- I performed a search on 'Google'
- In the Result page 2 clients were displayed with ‘Google’ in their name
- I clicked on the second one
---> The application returned a server error"

Explain the problem in plain language:
- Developers / re-testers don't necessarily have business knowledge
- Don't use business terminology

Be concrete
- Errors usually don't appear for every case you test
- What is the difference between this case (that failed) and other cases (that didn't fail)?

Give a clear explanation on the circumstances where the bug appeared
- Give concrete information (field names, numbers, names,...)

If a result is not as expected, indicate what is expected exactly
- Not OK : 'The message given in this screen is not correct"
- OK: 'The message that appears in the Client screen when entering a wrong Client number is "enter client number"
--> This should be: "Enter a valid client number please"

Explain why (in your opinion) the request is a "show stopper"
- Don't expect other contributors to the project always know what is important
- If you now a certain bug is critical, explain why!

Last but not least: don't forget to use screen shots!
- One picture says more than 1000 words
- Use advanced toold like SnagIt (www.techsmith.com/screen-capture.asp)

When testers follow these rules, it will be a real time and money saver for your project ! Don't expect the testers to know this by themselves. Explain these rules to them and give feedback when they do bad bug reporting!