Continuous Test Orchestration And Execution Platform Online
Perform automated and live-interactive testing on 3000+ real desktop and mobile devices online.
Advanced Guide On Writing A Bug Report
Arnab Roy Chowdhury
Posted On: August 9, 2018
5 Min Read
A bug that is well described has the capability to reduce the time taken to replicate the defect and resolve it. However, the perfect bug describing is a skill overlooked by many organizations. Bugs can cause delay to the release of an application and during testing phase or when the app is at production, developers tend to overlook bugs that are not properly described. This can spoil business relationships between an organization and their clients and may also lead to a company’s loss of reputation in the industry. In this article we will discuss how to write a bug report effectively, that will help developers to replicate and resolve the issue.
Check If It is Really A Bug
Often, testers fail to test a critical functionality because of environment issue or user error and log it as a bug. This leads to a waste of time for both the developer and the tester. Before writing any bug report the tester should
- Reproduce the issue again in different environments
- Make sure there is no environment issue
- Check with the requirement specifications and make sure whether the functionality is really failing or is it supposed to behave the way it is currently doing
Once you have made sure that all these criteria have been fulfilled, you can go ahead to file a bug report.
Be Specific in the Overview
A good bug report should contain
- A precise summary section to make the bug report unique and easily identifiable
- A brief overview that gives a developer clear understanding of the issue.
Often, the summary itself gives the developer an idea of what the bug is. For example, “Button is not working in iPhone X”. By looking at the summary, developer understands that the issue is with a certain button at iPhone X. A properly explained overview will give the developer an idea of the scenario in which the error can be reproduced. While describing the overview, the tester must make sure to
- Provide relevant information on why the issue is a bug
- Provide detailed information on how to reproduce it
- Provide information on the business requirement
Uniqueness of the Bug
Testers often make the mistake of reporting a same bug multiple time. An enterprise grade bug reporting tool should have indexing and a proper directory to find out bugs that have been reported. So, the next time a bug is easily detected, instead of reporting it, you must
- Go through the defect logs and find out if the same bug or a bug similar to it already has not been reported.
- Before reporting the bug, give it a unique bug id and make the title such that it can be found easily in the index.
- In bug report tools, there are criteria where the severity of the bug can be mentioned. The bug may be minor, major, critical or in worst case a blocker. How soon the bug needs to be fixed depends on its category.
Steps to Reproduce
This is the most important part of the bug report. It helps the developer to replicate the issue in development or production environment. This is the phase where the tester teaches the developer how to recreate the bug in their own environment. While writing this section, instead of a brief summary, focus on.
- Step by step guidance to observe the impacted functionality
- Mention the environment and platform details and also the user type, whether the issue is happening for a specific user or all users.
- Don’t forget to attach screenshots. These act as solid evidence to your report and also helps the developer to compare the report with the scenario recreated on their system.
Before reporting a bug, the tester should describe how a functionality or part of an application is expected to behave. Sections from the requirement specification consisting the business requirements can also be attached here so that the developer can understand how the application should actually work. This is known as expected behavior. For example, “On clicking the ‘Logout’ button, user should log out from the application”.
The second section of the behavioral report contains the subject matter of the bug. The observable behavior. This consists of how the functionality is behaving and how much different it is from the expected behavior. While writing this section, terms like “not working”, “defect” should be avoided. A developer never likes someone else to tell them that their code is wrong. Give specific details on how the functionality is not working as expected. For example, “On clicking the ‘Logout’ button, the application closes and error report is displayed showing ‘session terminated”.
Follow Up on the Reports
A job of a tester is not only to report bugs, but also to make sure that the bug has been fixed. After the report has been submitted, follow up with the developer and share that you are willing to help. Sharing a word of encouragement while following up on the report is a nice thing to do. A developer who feels encouraged about his work is more likely to fix a defect than a developer who gets annoyed by reading a poorly written bug report.
After focusing on the above-mentioned points, you will soon be able to write a high-quality bug report. Bug report should be focused on since they are an important mode of communication between a developer, a tester and the management. A great bug report that leads to quick fixing of the defect will not only increase the quality of the product but will also ensure that you have a good working relationship with the developers.
Got Questions? Drop them on LambdaTest Community. Visit now