Bug reports are one of the most important work products in software testing. View my video, How to write Bug Report in Software Testing | Bug Reporting in Software Testing | Bug Report Example, or read on.
We know that a truly great bug report is the result of thorough isolation of the bug and its accurate documentation, among other things. But, it is very common to have a tight schedule. So, the software tester may not be able to spend too much time on perfecting the bug report. If they do, they run the risk of not being able to complete the planned tests in time.
We know that a truly great bug report is the result of thorough isolation of the bug and its accurate documentation, among other things. But, it is very common to have a tight schedule. So, the software tester may not be able to spend too much time on perfecting the bug report. If they do, they run the risk of not being able to complete the planned tests in time.
In this common project situation, if you want to write a high quality bug report every time, just focus on getting the basics right. Use the following checklist to ensure the quality of your bug report. Note that few data items in your bug report may be static in a single test run. It is useful to create the bug report as a local document so that you can reuse as much of the existing data as you can.
1. Does the title of your bug report accurately summarize the issue?
2. Is the application name (and component name) mentioned?
3. Is the application version and build mentioned? Note: possible static data
4. Does it have the requirement (required behavior)?
5. Does it have the steps to reproduce the issue? Note: If you have a written test case that failed, you can paste that test case up to the step which failed.
6. Does it mention the observed behavior? Note: You can use screenshots or video clips here.
7. Does it mention all the data required to reproduce the issue?
8. Is the severity correct?
9. Are the name/ address (e.g. URL) and configuration (hardware and software configuration) of the server mentioned? Note: possible static data
10. Is the client configuration (e.g. O/S, browser) mentioned? Note: possible static data
11. Is it assigned to the correct team or person?
12. Is it copied to the correct people?
Out of the above data items, I consider title, steps to reproduce, observed behavior and required behavior as most important.
You can take the above checklist and customize it to your project needs. Execute the checklist to review your bug report before submitting it. This way, you would double-check that your data is correct and that no important data is missing. Ensure that you write a high quality bug report every time.
Nice list. Notice that for a website testing you can automatically include contextual details (URL, screenshot, OS, browser and previous actions) with your bug report using BugDigger http://bugdigger.com
ReplyDeleteNice post!!
ReplyDeleteI appreciate this content which is very useful for me. Great job!