One of the important deliverables in software testing is Bug reports. Writing a good bug report is an important skill for a software tester. In order to document a well-written bug report, the tester requires a combination of testing and communication skill. The bug report is a medium of communication between the tester and the 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
- Attachments
The Title
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 characters.
You can avoid generic problems in the title. For example:
- ABC is not working properly
- The 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 the navigation bar.
Good: The navigation bar is wrapping to a second line.
Steps To Reproduce
This is the 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 prerequisites 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.
Test Data
If the bug is specific to 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 “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 “The user remained on the ABC page”.
Attachments
Attachments add the bug value by offering proof. The attachment can be images, videos, or log files.
Images
Images are an essential part of the bug report. The bug reports should be effective enough to enable the developers to reproduce the problem. Screenshots should be a medium just for verification.
- If you attach screenshots 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 bugs in the image.
Video
The 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.
Log Files
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 them into the 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.
Have questions? Contact the software testing experts at InApp to learn more.
