The Problem - Focus on your goals and the reasons you’re writing a bug report in the first place. Make sure the title and description are about the problem, and not the less important details.
Generally, a good bug report will outline the steps taken to reproduce the bug, the environment(s) in which the bug was seen, the observed behavior compared to what was expected, and a decent “executive summary” that succinctly details the problem. However, there is no one standard template and varying best practices will depend on your company and its needs.
Why are the titles of my bug reports so important?
A clear bug title can summarize the core problem as well as the environment affected by hooking an observer into opening the bug and reading the details. A title can also serve as a reminder of the bug content when you are viewing reports or lists of bugs. Remember, someone will be trialing the bugs you log and deciding where they fit in the development plan. As a tester, you have the responsibility of searching for bugs to avoid logging duplicates. It seems only fair that we should all set a good example in our bug titles to ensure they’ll captivate an external observer. The title should not be generic (e.g., Error on Application), neither should it be too long. A good length would be one sentence that provides the highlights of the issue, as well as a way for a user to understand how they could run into it.
The description is the area where you can add all the extra details needed to support the bug report. At the same time, don’t write too much, or include irrelevant information and expect people to read it. 3 to 10 lines should be enough in 80% of cases. A bug report description should always include the steps needed to reproduce it, the consequences of the bug, and the suggested/expected behavior:
One of the biggest and most common testing problems is to overestimate the severity of your bugs.
You may be happy you have found a bug, and you want it fixed, but giving it the wrong level of seriousness will only make the others lose valuable time. They may prioritize poorly, finding out that a bug report is not as severe as was indicated, leading to a “boy that cried wolf” scenario. When in doubt, it’s always a good idea to consult your fellow QA peers about the severity of the bug report.
When working with a structured bug tracking system, we have fields that categorize our issues. Examples of these fields are modules, infrastructure, browser, OS, etc. Make use of these fields as they will help your team categorize (and in some cases reproduce) the bug correctly.
Naming attachments logically and consistently is incredibly useful. At a basic level, labeling screenshots as ‘before’ and ‘after’ takes away any potential confusion for the recipient of the report. When you’re dealing with more complicated bugs, you can both name your screenshots logically and reference the names of the screenshots accordingly. Anything you can do to minimize confusion and communication errors is invaluable. Examples of useful screenshots:
You should continue following up on your bug reports and provide comments when necessary. Comments are especially important when a developer or other stakeholder does not understand the bug, and either rejects it or delays it. You are the owner of your bugs, and certainly have a say on them, so you should make sure that they hear what you say. This behavior will always add value and make your clients understand that their project is being taken care of with great attention.
References:
