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!
Recent Comments