Introduction
As a tester, our basic aim is to decipher bugs. Whenever a new build is received to the testers for testing, the primary objective of each and every tester is to find out as many bugs as possible from every corner of the application to make the application bug free. To accomplish this task, we perform many different testing techniques. We check GUI, verification checks, integration test, functional check, security check and many more, which makes us drill deep into the application.
It as a well known fact that bug awareness is of no use until it is well documented, which creates a role of bug reports. Bug reports play an important role in Software Development Life Cycle (SDLC) in the various stages as they are referenced by testers, developers and managers, which makes bug reports an important stage.
Once the bugs are reported by the testers and are submitted to the developers to work upon, there may exist a cold war between them regarding the bug reported. The best tester is not the one who finds most of the bugs, but is the one who gets most of the bugs fixed.
Bug Reporting: An Art
The first aim of the bug report is to let the programmer know, where and how his code failed in a module of an Application. The bug report gives the programmer a detailed description and steps so that the programmer can verify is the bug valid or invalid. In case the development team is not able to replicate the reported bug using Bug Report, there can be back flows from the development team saying that it is not a bug, cannot reproduce, and many other reasons.
Hence it is very important that the Bug Report must be prepared by the testers with utmost proficiency. It should describe the following three things-
As follows:
![]()
Image Source: minisryoftesting.com
What we did
- Module, Page/Window names, which we navigate to.
- All the test data entered and selected.
- Buttons and the proper order of clicking.
What we saw
- GUI flaws.
- Missing or no validation messages.
- Incorrect Messages.
- Incorrect navigation pages.
What we expected to see
- GUI flaws: Give proper screenshots with highlight.
- Correct language or message.
- Correct validation messages.
- Mention the actual navigation page.
Some tips for effective bug reporting
Bug description should be clearly identifiable
A bug description is a short description that briefly describes, what exactly is the problem?. A description can require a few steps to be produced, but it should be clear and meaningful.
Bug should be reported after building a proper context
Pre-conditions for reproducing the bug should be properly defined in the bug report, so as to reach the exact point, where the bug can be reproduced.
Steps should be clear with short and meaningful sentences
Nobody wants to study an entire paragraph or a long sentence. The sentences should be small, clear and easy to understand. Make your report step wise by numbering it (1,2,3..).
Cite examples wherever necessary
Instead of writing an ambiguous statement like enter invalid data, try to mention the real data/value entered. For ex, enter the phone number as 12365478!A.
Give references to specifications
It is always suggested to mention the section and page number for the reference, when any bug arises, which is contradicting the SRS or any functional document.
Avoid passing any kind of judgment in the bug description
A tester should always be polite and should not be judgmental, so as to keep his bug up and meaningful and to avoid the controversies between them.
Assign severity and priority
It is the role of the tester to assign the proper severity and priority to the bugs. Severity is the state or quality of being severe, which defines the importance of the bug from the functional point of view. Priority defines when and how fast the bug should be fixed.
Severity Levels can be:
- Show Stopper
- High
- Medium
- Low
Priority Levels can be:
Provide screenshots
This is the best approach to make everyone understand the bug more clearly. For any error found, Server error, GUI issue, message prompts or any other, screenshots should be saved and attached in the bug report.
Conclusion
No doubt that your bug report should be a high quality document. The main focus of a tester should be on writing the good bug reports and spending some time on this task, because this is the main communication point between the tester, developer and manager. Thus, a bug should always be written in a clear, concise and precise manner, so that it gives an exact location of the bug in the extensive/exhaustive software map.