How To Write A Better Bug Report
Bug Reporting is a very major & important part of the software testing. In Software Testing, Bug reporting is referred as the reporting of issues observed by the tester to the developer so that it should be fixed at the earliest. The bug report comes into picture when the QA’s completes the test cases execution and an issue/defect/problem/mistake/error is found. Bug Reporting is crucial & important part in the software testing life-cycle, but still it’s much less practiced. A better and more effective bug report requires skills which can be mastered through continuously using these tools.
What is a Good Bug Report?
A bug report is termed as good-one if it is clear, to-the-point and easy to understand which include only one bug and not point to a collection of bugs. A good bug report must have the below format:
1. Numbered – Every bug in the Bug Report should be uniquely numbered so that it will be easy for everyone to identify the issues.
2. Specific – The bug reported should be clear, concise and to-the-point. Avoid using unnecessary details in the bug description.
3. Reproducible – The process to reproduce the bug should be described clearly in steps because if a developer is not able to reproduce a bug than it will never gets fixed.
4. Results – It should have the expected result and the actual result
To create a good report you should take the screenshots of the failures or errors occurred to highlight the defect/bug. In a good bug report, tester should use suggestive tone instead of a commanding tone with the developer and do not assume on its own that the developer did a mistake, so bug report should not use bold words directly. The bug report should clearly state that where the bug was identified so that it can be easily reproduced by the developer. These tools even help testers to maintain the bug duplicacy because all these listed bugs can be reopened and assigned back to developer, if issues are getting regressed.
Reporting a Bug
The basic format of a bug report should include the below mentioned data points:
- Reporter: Tester name and tester email address
- Product Version: It state the product in which tester has found the bug and version
- Component: The component or the module of the product where the tester identifies the bug
- Priority: Priority defines the importance of the reported bug. It ranges from P1 to P3. (P1 priority bugs are considered as the highest priority means ‘fix the bug quickly’ and same way P3 bugs are considered as the least priority means ‘fix it when you have time’)
- Severity: Severity is termed as a blocker, critical, major, minor, trivial. It also defines the importance of the bugs, if a bug’s severity is blocker then it should be fixed on priority and if it is trivial then it can be fixed anytime
- Status: It defines the current state of the bug i.e. OPEN, CLOSED, READY for DEV, DEV In Progress, QA READY, QA in PROGRESS
- Assign To: Attach the name & email of the developer if you know who is responsible for the component
- URL: URL of the page where the actual bug occur
- Summary: The summary of the bug report in less than 30 words
- Description: This is where tester should state and describe the bug with all the required device details
Tools for Bug Reporting
For the bug reporting we can use any of the tools like- Bugzilla, Bugherd, JIRA, Marker etc. Among all these tools Bugzilla and JIRA is widely used in the companies. These tools are made to reduce the QA’s efforts because these logged bugs are self explanatory and also help the QA’s to maintain the bugs. Remember that a better bug report ensures that the issues listed in it will be fixed at the earliest.
