How to write a good bug report
It is always necessary to file a bug clearly so that the developer who fixes the bug can reproduce it with ease. In short a good bug report should be easy to understand and should not be confusing.Points to consider while writing a bug:
1. Verify the problem you found is a new bug and NOT a duplicate.
2. Write precise and clear steps to reproduce the bug. A good bug report provides enough information to make the test easy to recreate.
3. Always include the expected behaviour.
4. Don't point out two or more issues in the same bug report. If you feel there appears another different issue when you follow the same steps, raise it separately, otherwise there is a chance that it get missed. In other words multiple bugs should not be grouped into one.
5. Don't disguise a feature request as a bug. You can't submit a bug report that says "This screen doesn't have a delete button". That's not a bug. "Well, it's not a correct screen. It doesn't have a delete button!" Okay, it's not a perfect screen. Why wasn't there a delete button in the original spec?
6. Attach logs in case of a crash / exception.
7. Try reading the bug report before hitting the submit button so as to check twice that everything you have written is correct and makes sense.
8. The quality of information in bug reports can crucially influence the resolution of a bug as well as its resolution time. Reports that contain all the necessary information can make resolving the bug somewhat easier.
9. Bug morphing is the phenomenon that occurs when a bug changes from one issue to a completely separate issue within the same bug report. Sometimes it happens quickly, and sometimes the morphing is drawn out over days or months. Regardless of the situation, bug morphing is never a good idea.
Bugs that have morphed are difficult to analyze for root cause. They also can cause confusion with product support or sustained engineering when they are reviewing product issues or searching to see if an issue a customer is seeing is caused by a known defect. If a bug begins to change in a bug report, it is crucial to stop and open a new bug for the new issue.
10. No bug is too trivial to report - small bugs may hide big bugs. Moreover clearly separate fact from speculation.
Also see:
a. Bug writing guidelines
b. Bug reporting guidelines
c. Balaji Kothandaraman
d. corsiKa♦
e. Making Software: What Really Works, and Why We Believe It By Andy Oram, Greg Wilson
f. Crystal Clear: A Human-Powered Methodology for Small Teams By Alistair Cockburn
g. How We Test Software at Microsoft By Alan Page, Ken Johnston, Bj Rollison
h. Managing Software Development By Samuel Menaker, Sheetal Guttigoli