Writing a good bug report

I thought a quick summary and a few tips on how to write good bug reports might be useful for people who want to report problems but don't have much experience testing software.

Here's a brief summary made up of chunks from various sources

What are the qualities of a good software bug report?

1 ) Good bug titles:
We have lots of bugs in the database. Lots. It is important for the bug title to include words that someone else might use to look up the bug. A good rule of thumb that I use is before I even start to write up the bug report, I search for the bug. Well, we all should first search for the bug before filing, but what I do a little differently is record what words I used to try to query the bug with. I make sure I use those words somewhere in the bug title.

2 ) Reproducible:
If your bug is not reproducible it will never get fixed. You should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing step. Step by step described bug problem is easy to reproduce and fix.

3 ) Be Specific:
Do not write a essay about the problem. Be Specific and to the point. Try to summarize the problem in minimum words yet in effective way. Do not combine multiple problems even they seem to be similar. Write different reports for each problem.

4 ) Reproduce the bug three times before writing bug report:
Your bug should be reproducible. Make sure your steps are robust enough to reproduce the bug without any ambiguity. If your bug is not reproducible every time you can still file a bug mentioning the periodic nature of the bug.

5 ) Write a good bug summary:
Bug summary will help developers to quickly analyze the bug nature. Poor quality report will unnecessarily increase the development and testing time. Communicate well through your bug report summary.

6 ) Read bug report before hitting Submit button:
Read all sentences, wording, steps used in bug report. See if any sentence is creating ambiguity that can lead to misinterpretation. Misleading words or sentences should be avoided in order to have a clear bug report.

7 ) Elaborate on your error logs:
Sometimes more information is needed than a simple error log from bugswatter or other similar addons. Explain what you were doing to trigger the error, and any side effects it caused. Also if you do provide an error log (And you always should if one occurs) please provide the full text, it really does mean something to us. A list of the addons you're running can also sometimes be useful, but we don't need 10 copies of it.

8 ) Keep an eye on your reported bugs:
Nothing is more frustrating to an author than being unable to reproduce a bug, and being unable to contact the reporter. The dev team will often ask for more information, or suggest other courses of action to try, so check back regularly, or have the forum notify you about replies to your topics.

Hopefully these should help both the users and the dev team when dealing with bugs, but remember the most important thing: until it's properly released, WIM 3 is beta software, it WILL have bugs, and it WILL be missing features. Please report the former, and just be patient on the latter.
(Define: Beta software - A version of a software product released to the public for use and testing with no guarantee from the originators that the program is free of bugs)

Navigation

sponsors

statistics


	test stamp