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. There are following Test Cases in a Bug Report:
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.
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.
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.