Effective Defect report does not help only developers to understand the defect but also helps the Entire team to know about the defect and off course helps QA team to during verification of the defect.
Most common fields in Defect Report are:
- Component ( Feature name)
- Build no.
- The severity of the defect
- Defect Summary
- Operating System
- Internet Browser ( in case of the web application)
- Steps to reproduce the defect
- Actual result
- Expected Result
- Additional information ( Error log, Error Messages, etc)
- Attachments ( images, videos for support defect and helps other to reproduce it)
Before reporting the defect to make sure that Defect is reproducible, the best way to reproduce the defect with fresh data. do not use legacy data, it may be corrupted due to testing.
Do the proper bug isolation, reduce the no. of steps to reproduce the defects.
Make sure that Summary of the defect is precise and specific so that other team member can understand the defect by reading the summary line. Do not write summary vague. something like.. XXXX functionality is not working. it very bad summary line.
Its very important to give the correct information about the Build no, Operating system and internet browsers. many times QA forgot to include these details which lead in time lost of developers, testers, and managers.
Severity is the most important parameter which QA/Lead needs to assign for the defect in the defect report. generally, there are 5 types of severity levels
- Blocker: for crash or major part of the application is not working
- Critical: Major failure in Features.
- Major: Logical errors, Major UI defects
- Minor: UI defects
- Wishlist: functionality is not present in the application, but nice to have, also minor usability issues can be logged here.
now coming to the core part of a defect report, Steps to reproduce the defect. make sure that steps are clear, precise and specific. add more and more details steps so that any team members ( Dev, Managers etc) can able to reproduce the defects. for the effectiveness of the defect separate actual and expected result. and in “expected result” demand expected behavior does not put open-ended statement.
- Open http://www.qeworks.com
- Click on “Login” Link on Top Right corner
- Enter Login details:
- UserName : Tester123
- Password: Password
- Click on “Login” button
Actual Result: User is getting Page not found the page
Expected Result: User should get the User area and user should able to log in.
Additional information: 404 error message
above example gives you a more clear picture about the effective defect report.