Reporting Software Bugs
Bug identification is only half the job, more important is to get it fixed and in order to get it fixed you must report it.
How you choose to report it, will decide how well and quick it will be resolved.
It is no secret that to transfer the knowledge of existence of a bug, it is necessary that the bug should be reported in a way that is identifiable, clear and understandable that is specifically described and reproducible.
To identify a bug it must have an identification number clearly assigned for each specific case.
This may include the test suite number and test case number.
Also, the testing environment and other specific conditions must be mentioned. The reporter details also should be included for traceability and to avoid looking for the same bug repeatedly.
The type of reporting and severity of impact on the software under test needs to be mentioned.
The report types are typically:
- Coding error
- Design error
- New suggestion
- Documentation issue
- Hardware problem
Also Read: Software Bugs Reporting Tools, Software Bugs and Bug Lifecycle
A good bug report will have following information:
- Unique Identification Number – It must have a unique identification number for communicating.
- Summary – One line summary capturing the essence of the problem with release number and module affected. This is important because when reviewing a long list of problem report, each record should tell the manager or whoever is checking about what the problem is, which functional area it belongs to and release/build it is seen in and uses the bug id to create further reports.
- Description – It should have details of the problem description, which explains the context in which the problem is seen. It should cover details of the documents being referred to for testing, feature or functionality being tested, pre-conditions, environment used, input values and actual results. Also, mention expected results.
- Steps to Reproduce – Clearly and precisely mention steps to reproduce the problem.
- Originator – Name and email contact of the person raising the defect.
- Product – Product Name being tested.
- Release Number – Usually work goes on in multiple releases in a company based on features. Hence, release number is important to be mentioned.
- Build Number – There is a concept of weekly and daily builds and the tester works on a particular release so this needs to be mentioned, in order to make it easy for the developers and others to refer to the exact version of code.
- Functional Area – Mention the module in which problem was first seen.
- Operating System – Mention the OS in which problem is reported.
- Priority – Urgency with which it should be handled.
- Severity – Impact of the bug on the system.
- Status – A defect starts from “new” state after being created and it is considered done only after it is “closed”. It goes through multiple state transitions in between known as the bug lifecycle. Every state must be captured
- Phase Detected – At which phase of SDLC and what type of testing exposed the bug.
- Phase Injected – At which phase it was introduced, knowing this is important to highlight what can we do to not let it pass on to next phase next time.
- Workaround – Steps followed to temporarily solve the problem in order to move ahead with test.
- Assigned To – Name and/or id of developer who works on it.
- Feedback – A developer should have an option to challenge the tester on the validity of the defect or request the tester for clarification. Hence, feedback is also an important section.
- Logs & Traces – Attach all the relevant logs and traces. If needed, attach screenshots. If size is high save it in some repository and provide the link in the defect.
- Regression (Yes/No) – It really is helpful if it is clearly mentioned with just a Yes or No on whether it is a regression or a new problem.
- Root Cause Analysis – A section covering root cause analysis is good idea along with defect details it helps everyone to understand the problem and get learning out of it for future.
Objective of reporting a bug should be to get it fixed.
Factors to consider while Bug Reporting:
- Since we are talking about bugs reporting, it seems apt to point out that it is important for testers to not get carried away by raising every other bug with high priority and/or high severity.
- Although the onus is on testers to set the priority/severity but it can and will be challenged if not in accordance with the quality standards followed by the organization and business requirements.
- As a tester it is your responsibility to not unnecessarily increase the defect count, for e.g., if two issues are identified where one is dependent on the other then one defect should be raised explicitly highlighting two issues instead of two.
- Another important criterion for bug reporting is quality of reproduction. If a tester reports a bug and the programmer cannot see the bug as reported it may not be fixed.
- Bugs are required to be reported with inclusion of all the specific test conditions so that we have every to reproduce the problem.
- It should be made sure that it is not an intermittent issue and after confirming clearly mention the steps to reproduce. If it is an intermittent issue, mention so, if there are sufficient logs developer might solve it but even if he won’t, at least everyone is aware of its existence and can add some debug trace to take care of it in future.
- Tone should be polite and firm when reporting bugs.
- Before submitting the bug report it should be checked rigorously for any ambiguity in description or improper wording.
- Any screenshot or other relevant document may be attached to the bug report for better understanding.
We have tried to cover this topic using our experience working with real time problems faced while reporting bugs, try to learn from them if you are starting as software tester.
If you are already working as software tester share your experiences and help us improve this post .