Why writing a GOOD Bug Report is so important?

Bug reporting is essential for locating issues in development, and gives our developers the needed support to fix them quickly. While it may be tempting to write a 10-page report on what you discover, experience has taught us that the simpler and more succinct your report is, the better you’ll be able to help others solve the problem in the long run. Writing a good bug report isn’t hard, it can be tempting to do it in a hurry, without putting your full attention into it. Creating a bad bug report will cause at least one, if not all, of the following scenarios:

  • Reporting bugs quickly and incorrectly will most certainly cause you to have to re-write the whole report, or even spend more time trying to explain it to the developers.
  • Other peoples’ time will also be wasted reviewing the bug since they’ll be trying to make more sense of what you wrote.
  • By writing about a bug incompletely and/or incorrectly, you harm your reputation as a QA Professional.
  • You waste the time of the people who will probably need to re-test the fix for your bug report.

Things to keep in mind

  • The Problem. Keep your eye on the prize, or in this case, on the reason you’re writing a bug report in the first place. Make sure your title and description are focused only on that problem, and not on the less important details.
  • Length. Detail is appreciated, but leaving a wall of text about an issue makes it harder to follow and understand. Keep your report short, simple, and focused!
  • Proof. Some bugs only exist on one platform or OS, some can’t be reproduced at all. Make sure to include screenshots, videos, and logs so we can confirm and analyze what happened.
  • Related Issues. Are there any other actions that could cause the same problem? Are they relevant to mention in your report?

Is there a standard template for reporting bugs?

Generally a good bug report will outline the steps taken to reproduce the bug, the environment(s) in which the bug was seen, and the observed behavior compared to what was expected. This should all be headed with a decent “executive summary” that succinctly details the problem. However, there is no one standard template; there seem to be several different templates and best practices depending on the company and their needs.

Why are titles of my bug reports so important?

A bug title can summarize the core problem as well as the environment affected. This can be used to hook 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 that, at some point, someone is going to be trialing the bugs you log and deciding where they fit in the development plan. As a tester, you have the responsibility of searching bugs to avoid logging duplicates. You reap what you sow, so it seems only fair that we should all set a good example in our bug titles and take a second look at them 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. It should be one sentence, and provide the highlights of the issue, as well as a way for a user to understand how they could run into it.

Examples of good and bad titles

  • Good: “Unable to log into the system when username contains foreign characters”
  • Bad: “User cannot authenticate in Chinese”
  • Good: “Log rotation doesn’t work, grows until the disc runs out of space”
  • Bad: “Server crashes due to log size”

Why should description be concise, but also complete?

The description is the area where you can add all the extra details needed to support the bug report. On the other hand, you can’t write too much and really expect people to always read it. And of course, please don’t write irrelevant information. As a rule of thumb, 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 its suggested/expected behavior:

  1. Steps to reproduce. Outline all of the steps, sometimes even the trivial ones, needed to make sure that people who need to fix the bug can understand it correctly. Make sure to also include the data required to reproduce it (e.g. account names, strings, links, etc). The steps to reproduce are numbered from beginning to end so that developers can easily follow through and repeat the process. We should keep step numbers relatively whittled down; reproducing a bug that has 99 steps can be really hard to follow. Using the “>” symbol is usually a good way to do that.
    • For example: a) Go to settings > Profile b) Tap on More Options > Delete Account
  2. Consequences of the bug. Include what the user will experience if and when the bug occurs in the application. Again, sometimes this can be trivial, but other times it won’t be and you’ll need to make sure this information reaches the reader.
  3. Suggested/Expected behavior. Include the differing behavior, especially when you are reporting a bug that doesn’t create data-loss, but on the other hand makes the application uncomfortable or unusable to the end-user.

Setting the correct severity

One of the biggest and most common tester sins is to overestimate the severity of your bugs. Obviously you’re happy you found a bug and you want it fixed, but giving it the wrong level of severity will only make the person in charge of the bug lose valuable time. They’ll completely drop what they were working on, only to find out that the wrongly marked bug report is not as severe as you thought. You might be remembered as the “boy that cried wolf” and the next time you log a bug report marked with the correct severity, the developer will be skeptical about it. When in doubt, consulting your fellow QA peers about the severity of your bug report is always a good idea.

Make use of the categorizing fields

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. So make use of them! These fields will help the team categorize (and in some cases reproduce) the bug correctly.

How useful is it to name attachments in a logical and consistent manner?

Incredibly useful! At a basic level, labeling screenshots as ‘before’ and ‘after’ takes away any potential confusion for the recipient of the bug. When you’re dealing with more complicated bugs, you can both name your screenshots logically and reference the names of the screenshots accordingly. Basically, anything you can do to minimize confusion and communication errors is absolutely invaluable. Examples of useful screenshots:

  • Before/after
  • With a certain setting/without a certain setting
  • Numbered annotations attachments suggestive titles
  • Drag and drop attachments so they’ll show up as as thumbnails

Follow-up and comment

You should continue following up on your bug reports, and provide comments when necessary. This is especially true 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 say is heard. This behavior will always add value for your clients, making them understand that their project is being taken care of with great attention.   References: https://testlio.com/ https://www.utest.com/ http://qablog.practitest.com/ https://www.quora.com/