How to Create a Good Bug Report
A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. Bugs are usually discovered during the testing. In order to fix detected problems, a Tester must inform a Developer about them, i.e. create a Bug Report.
What are the main goals of a Bug Report?
- Reproduce a detected problem.
- Learn more about it and its importance.
In order to reproduce a problem you need to list the operations that lead to it. Don’t add a new Bug right away. Repeat it first. If you can’t, then you’ve probably missed some crucial steps. Review what you did carefully. As soon as the course of actions is restored, minimise the number of steps. Then create a new issue in your Bug Tracking System:
Subject captures the essence of a problem. Use the principle “What? Where? When?” to define it: what’s wrong, where exactly, when does it happen (circumstances).
Description must include a step-by-step instruction on how to reproduce a Bug. Don’t add excessive steps and don’t miss necessary steps. Basically, you need to describe the following: sequence of actions, result received, and result expected.
If the initial data is required for bug reproduction - attach files. If the issue is visual – attach screenshots (you can make them with apps like Lightshot) and a link to the design. Add arrows and comments that demonstrate what needs to be fixed explicitly (for the best result, create a side-by-side comparison of the design and the existing implementation):
If the problem can’t be captured by a screenshot (flickering, shifting) – record a screencast (use screencast-o-matic, for instance). If you need to add error text (from a console or a sniffer), don’t copy and paste it into a description. Create a text file and attach it to your Bug. After that you’ll need to specify the environment, where the problem occurs: device, OS, browser. If it appears on more than one occasion – list them all. For example: Win8 Chrome, MacOS 10.9 Safari, Sony Xperia Z Android 4.4.2 Chrome. Bug Priority depends on the project specifics. Typically, specialists use the gradation below:
-
Blocker – a problem that blocks software functionality.
-
High – severe functionality problems that interfere with the main script/core features. They are the first ones to fix.
-
Normal – standard functionality/layout flaws.
-
Low – typos, minor layout flaws.
The issue must be assigned to the Developer responsible for this part of the functionality/layout.
Version - the one with the problem.
Development Category: functionality, back-end, front-end, layout problem, etc.
Add your Project Manager as a Watcher.
What NOT to do:
Don't report multiple issues as a single Bug.
One problem - one Bug. In case issues are connected or they come from the same module, just make them related. But don’t ever add them as a single Bug!
Why adding multiple problems into one Bug is such a bad thing? It slows down the bug fixing process. You see, after an issue has been resolved, a Developer reassigns it back for verification. Therefore, if you put multiple problems into one task, they won’t be able to send them for verification till everything is fixed. Whereas, when each malfunction is reported as a separate task, verification will proceed faster. This way Bug Lifetime (re-opening, closing) will be shorter and a product will be released sooner.
- Don’t create a Bug for cases not stated in an SRS.
If software behaves incorrectly according to your understanding, but there are no details about it in the SRS - it’s not a bug. Don’t waste a Developer’s time on unauthorised tasks. You may add such issues as Features after discussing it with your Project Manager.
Team Lead/ Senior Software Engineer
related
recent
recommended
