Bug reporting is an important and major aspect of software testing. Some teams discuss minor bugs with developers directly, while most companies make it a point to report the bugs irrespective of its severity. This way, we do not “bug” the developers too much and, the tester who finds it next will not spend duplicate efforts reporting the same bug again.
If a bug is not documented, the developer fails to understand the bug or worse, reject it.
Another impact is that management may fail to understand the impact of the bug and let it be in the production to hear about it from the customers later.
The objective of a good bug report is to help the developer and the management to understand the bug. Some basic guidelines to keep in mind are:
1. All the relevant information must be provided with the bug report
2. Simple sentences should be used to describe the bug
Expert testers consider bug reporting nothing less than a skill. We have compiled some tips that will help testers master them better:
1. Report reproducible bugs: While reporting a bug, the tester must ensure that the bug is reproducible. The steps to reproduce the bug must be clearly mentioned. All the prerequisites for the execution of steps and any test data details should be added in the bug.
2. Be concise and clear: Try to summarize the issue in a few words, brief but comprehensive. Avoid writing lengthy descriptions of the problem.
Describe the issue in pointers and avoid paragraphs. It’s important to provide all the relevant information, it helps the developers to understand the issue without any additional to and fro of the bug. The developer must clearly understand the underlying problem with the bug report.
3. Report bugs early: It is important to report bugs as soon as you find them. Reporting the bug early will help the team to fix the bug early and will help to deliver the product early.
4. Avoid Spelling mistakes and language errors: Proofread all the sentences and check the issue description for spelling and grammatical errors.
If required, one can make use of third-party tools for eg. Grammarly. It will help the developer to understand the bug without any ambiguity and misrepresentation.
5. Documenting intermittent issues: Sometimes all bugs are not reproducible. You must have observed that sometimes a mobile app crashes and you have to restart the app to continue. These types of bugs are not reproducible every time.
In such scenarios, testers must try to make a video of the bug and attach it with the bug report. A video is often more helpful than a screenshot because it will include details of steps that are difficult to document.
For example, a mobile app crash while switching between applications or sending an app to background and bringing it to the front.
6. Avoid duplication of bugs: While raising a bug, one must ensure that the bug is not a duplicate of an already reported bug. Also, make sure to check the list of known issues and open issues before you start raising bugs. Reporting duplicate bugs could cost duplicate efforts for developers, thus impacting the testing life cycle.
7. Create separate bugs for unrelated issues: If there are multiple issues reported in the same bug, then it can’t be closed unless all the issues get resolved. So, separate bugs should be created if issues are not related to each other.
For example, Let’s say a tester comes across two issues in an application that are in different modules. One issue is in compose email functionality where the user is not able to compose an email and another issue is that the user is not able to print an email. These issues must be raised separately as they are independent of each other.
8. Don’t use an authoritative tone: While documenting the bug, avoid using commanding tone, harsh words, or make fun of the developer.
Important Details To Mention In The Bug Report
There are various bug reporting tools available in the market like Jira, Bugzilla, TFS, Asana. Depending on the project cost, one must select the bug reporting tool.
Excel or Word can also be used for reporting bugs for small projects. Irrespective of the tools used for logging the bug, some details must be captured by the tester in the bug report.
Below are the important details that should be mentioned while creating a bug report:
1. Bug ID: Each bug should be given a unique identification number. Bug reporting tools automatically provide a unique number to the new bugs that are raised. This field helps to identify the bug easily.
2. Summary: A brief summary of the issue should be provided. The summary should be a concise statement that helps to identify the problem. Bug titles should be easy to understand, which would help in identifying the issue easily.
A good bug summary helps managers review the bugs quickly during the bug review meetings.
3. Description: Description should be provided in the bug in order to help the developer in understanding the bug. It should be in simple language which a developer can understand easily.
All the details about the environment and the type of user privileges must be mentioned. For eg. any prerequisite for executing test steps like any configuration or test data.
Let’s look at another example, Mobile app crashes while switching to a module, where the user doesn’t have access. In these scenarios, user privileges details must be mentioned in the prerequisite along with the URL of the admin page to modify the user permissions.
4. Test Steps: Test steps should be mentioned in detail. Test steps will help the developer to replicate the issue in their own environment.
5. Actual Results: The actual result of the test steps must be mentioned.
6. Expected Results: Expected results corresponding to failed steps must be mentioned which would help the developer to know the exact behavior to adapt while fixing the bug. This section will also be helpful while retesting the bug.
7. Reporter: Name and email of the reporter of the bug should be mentioned. In bug reporting tools, these are automatically fetched from the user profile. It would help the developer or reviewer to easily identify who reported the bug. In case of any discussion required around the bug, developers can reach out to the reporter.
8. Reported date: Date, when the bug is raised, should be mentioned. This will help in identifying the release in which the bug occurred.
9. Assignee: Bug should be assigned to the product owner or development manager. They can review the bug and plan the fix as per the bandwidth of the team member and module expertise. In some cases, bugs can be left unassigned and added to the bugs queue, from where developers can pick them according to the priority.
10. Severity: It is defined by the tester for bugs depending upon the impact on the application. Severity can be as follows:
i. Blocker: Blocks development and/or testing work and/or the actual use of the system/product (e.g. crash upon starting the app)
ii. Major: Major loss of function, with no workaround, other parts of the product/system still work
iii. Normal: Normal loss of function, or other problem, where a difficult workaround is present
iv. Minor: Minor loss of function, or other problem where a workaround is present for the functionality
11. Priority: It is defined for a bug by tester/product owner considering severity, probability, business needs, time, and resources available.
i. Critical: Bugs that are mission-critical to the core functionality of the application and for which there are no workarounds.
Note: These bugs should be extremely rare and this category should only be used if encountering a team/user blocking situation.
ii. Urgent: Bugs that are related to the core functionality of the application, and have to be fixed urgently within the sprint.
iii. High: Bugs that do not affect any critical user functionality, and have workarounds. These bugs can be fixed in the next sprint.
iv. Normal: Bugs that do not interfere with core functionality and are just annoyances that may or may not ever be fixed.
v. Low: Whatever gets defined as low might be kept at the backlog and might be closed as a known issue.
12. Component: Sometimes an application is classified into multiple modules and these are then mentioned under the component field while a bug is reported. It becomes easier to analyze which module has problems. When bugs are assigned with corresponding components mentioned, it becomes easier for the development manager to assign the bug to respective team members based on their area of expertise.
13. Affected Version: It is the version of the application on which the bug is reported.
14. Fix Version: it is the version of the application on which bug is fixed. The application version on which bug is retested successfully is updated by a tester.
15. Date Closed: It is the date on which bug is closed by the testing team.
16. Target version: It is the version of the application on which bug is targeted to be fixed.
17. Status: A software bug follows a cycle. According to where it is in the cycle, a status is assigned to it. For eg. When a new bug is created, its status is assigned as open. Later on, it goes through various stages like In Progress, Fixed, Won’t Fix, Accepted, Reopen, Verified, etc. These stages vary in accordance with different bug reporting tools.
18. Attachments: Screenshots, videos, logs should be attached for the failed steps. Screenshots should be highlighted for the issues which help the developer to easily visualize the issue. Videos and logs will help to reproduce the issue with the required steps.
Best, if suggestions to fix are incorporated if known.
Conclusion
A bug report is an important document and writing a good bug report is a skill. While reporting the bug, testers should include all the relevant details which will help a developer in analyzing the issue. It is a communication channel between the developer, tester, and manager.
Best practices of reporting the bug should be shared with each testing member. Testers should be encouraged to write a good bug report and help convey how exactly the bug appeared.
A good bug report will help to save the cost of fixing bugs and will help in creating a good rapport between team members.
Write simple automated tests. Identify bugs and publish detailed reports with the help of Testsigma
