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?

  1. Reproduce a detected problem.

  1. 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:

BR1_en

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).

BR2_en

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.

BR3en

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):

BR4

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.

BR5en

What NOT to do:

  1. 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!

BR6_en

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.

  1. 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.

BR7_en
Lyubov N.
November 08, 2017
recent
Machine Learning: from Science Fiction to Real Business It’s High Time to Launch Your Own Apps for Business Cryptocurrency Mining: How to Find Your Gold Mine Limiting your Expenditures and Risks: IT Contractors Vs. Outsourcing Teams
recommended
Everything You Want to Know About Mobile App Development App Development Calculator Infographics: Magora development process The Best Mobile Apps for Businesses App Development Post Launch Activity
categories
News Technologies Design Business Development
Logo Magora LTD
close
Get in touch
Logo Magora LTD
close
Thank you very much.

Your registration to the webinar on the 24th of May at 4 p.m. GMT was successfuly completed.
We will send you a reminder on the day before the event.
Magora team
Registration for a webinar

"GDPR compliance: Workflow Automation"
Date: 24.05.2018 Time: 4 p.m. GMT