One of the important deliverable in software testing are Bug reports. Writing a good bug report is an important skill of a software tester. In order to document a well-written bug report, tester requires a combination of testing and communication skill. The bug report is a medium of communication between tester and developer when the tester uncovers a defect. The bug report explains the gap between the expected result and the actual result.
A bug report should have the following:
- The Title
- Steps To Reproduce
- Test Data
- Expected and Actual Results
A good title helps reduce duplicate issues and accurately summarize the issue. Include the specific name of the components involved in your bug in the title. A good summary will not be more than 50-60 character.
You can avoid generic problems in the title. For example:
- ABC is not working properly
- Issue with the page
When we define a title we should specify what makes it “not working”.
Bad – “Application crashed”
Good – “Canceling from Change Password dialog caused application crash”
Bad : Issues with GUI on navigation bar.
Good : Navigation bar is wrapping to a second line.
Steps To Reproduce
This is body of the report. This section tells how to reproduce the bug. We should keep the section concise and easy to read. The number of steps should be short and to the point. It is better to write prerequisite to reduce the number of steps. It’s a good exercise to reproduce the bug by following the steps you’ve just outlined. This will help ensure you’ve included everything the developer will need to reproduce it as well.
If the bug is specific for the particular scenario it is better to give the test data, so that developer can recreate the scenarios.
Expected and Actual Results
When describing expected results, explain what should happen, not what shouldn’t happen.
Instead of writing “The app got crashed”, we can write as “The user should take to XYZ screen”.
When describing actual results, describe what did happen, not what didn’t happen.
Instead of writing “The user wasn’t taken to the page”, we can write as “The user remained in the ABC page”.
Attachments add the bug value by offering proof. The attachment can be images, videos or log files.
Images are an essential part of the bug report. The bug reports should be effective enough to enable the developers to reproduce the problem. Screen shots should be a medium just for verification.
- If you attach screen shots to your bug reports, ensure that they are not too heavy in terms of size. Use a format like jpg or gif, but definitely not bmp.
- Attach the image files directly to the report. Don’t put images in a Word document or a zip file.
- Highlight the areas of bug in the image.
Video should be provided if the steps are complex. Actions in the video should match the steps listed in the bug report. Videos should be trimmed to only show the bug.
Make it a point to attach logs from the logs. This will help the developers to analyze and debug the system easily. If the logs are not too large, say about 20-25 lines, you can paste it in bug report. But if it is large enough, add it to your bug report as an attachment. Avoid proprietary file types (like .docx). Use .txt instead.