How to write a bug report

lyj20080

Bug reports should include following basic things.
1. Bug summary
2. A little more description than the Bug summary
3. Pre-condition & Steps to re-produce
4. Actual result
5. Expected result
6. Severity & Priority
7. Any screen shots, AUT (Application under test) logs.
8. AUT Version on which this defect\issues arises.
9. Frequency of the defect. Always\Sometime
Bug reports should be such that the developers get all the information they require to reproduce the defect. Here are some handy tips to do this.
1. Review each bug report yourself before filing it. Ask yourself these simple questions during this review
- Does the summary convey the gist of the defect?
- Have I put in all the information that I have collected for troubleshooting for this defect?
- Can I do anything else to help the developers?
- Is anything in the bug report creating confusion?
- Is the severity & priority justified?
- Am I putting in too many attachments? All of them are really required?
2. You will encounter defects that are not always reproducible, or not reproducible on all environments (Operating System, Database, etc). Mention your findings clearly. These defects have the highest probability of being marked invalid. Handle such defects with extra care and make sure you put in every piece of information in there.
3. Write that defect at the very next moment you find it. If you postpone it, you will forget some thing or the other, or spend more time in re-reproducing the issue.
4. While you are testing integration of more than one application or End to end testing which involves more than one application, make sure you specify correct version of all the application used