Back to List

How to Create a Readable and Useful Bug Report

Blayne Roselle Blayne Roselle  |  
Jun 25, 2019
Creating a bug that is both readable and provides enough detail is a must-have skill for a Quality Assurance Analyst. Not only will it help when it comes time to retest, but it also provides credibility with your development team. In the content below, I will share the best practices for creating a bug.

Bug Definition

It is common practice to differentiate between a defect and a bug. A defect is frequently defined as an error found in the Production environment. But a bug is frequently defined as an error found by a tester while testing in a “test” environment. However, in the steps below, I will use the terms interchangeably.  Simply put, a bug/defect is defined as a variance between expected and actual results.

Bug Creation

This exercise focuses on the process of bug creation regardless of what bug tracking tool is used. Different bug tools will have different fields to complete. When creating a bug, the following should be considered:

Step #1

In general, be direct, precise, and use simple language.

Step #2

In the Title section of the bug tracking tool, create a title that is easily searchable, and include the following information:
  • User Story or Product Backlog Item (PBI) number
  • Title of the User Story or PBI
  • Description of the defect

Example: PBI-12345_Create Login screen_Username field only allows 10 characters – max should be 15

Step #3

In the Steps to Reproduce section, create a summary of the bug, and include the following information:
  • Brief description of the bug
  • Environment
  • Version or build number of the environment
  • Browser (establish an agreement with your developers that if a browser is not listed, then the issue applies to all browsers being tested. However, if a browser is listed, then the issue is specific to that browser)

Example: The maximum number of characters the Username field is allowing is 10. According to Acceptance Criteria, the maximum number of characters the Username field should allow is 15. This was tested in the Dev environment (v1.0.212). (If this was browser specific, then add, “using the latest version of Chrome.”)

Step #4

List the minimum number of steps necessary to recreate the bug. Then execute the steps and verify that the listed steps recreate the bug.

Step #5

List the Expected Results. Example: “The maximum number of characters allowed in the Username field is 15”.

Step #6

List the Actual Results. Example: “The maximum number of characters allowed in the Username field is 10”.

Step #7

Assign the bug (determined by the Development team ahead of the project):
  • Business Analyst
  • Product Owner
  • Lead Developer
  • Developer assigned to the User Story

Step #8

Assign a Severity/Priority to the bug:
  • Critical – A Critical bug indicates that the defect impacts critical functionality or critical data AND there are no workarounds.
    • Example: On the Login screen, when clicking the “Login” button, the application displays a system error.
  • High – A High bug indicates that the defect impacts major functionality or major data. There may be a workaround in some instances, but the workaround may be complex or cumbersome.
    • Example: On the Login screen, Requirements state that the Name field must allow between 8 – 15 characters, but the application only allows 10 characters to be inputted.
  • Medium – A Medium bug indicates that the defect impacts minor functionality or noncritical data AND there is an easy workaround.
    • Example: On the Login screen, user must click the “Login” button twice to advance to the next screen
  • Low – A Low bug indicates that the defect does not impact functionality or data and does NOT need a workaround. 
    • Example: Misspelling/grammatical issues

Step #9

Add a screenshot (or video) to support the steps to reproduce:
bug creation report


Following the guidelines above will you help you create a bug that is both readable and provides the detail needed to easily reproduce.


Love our Blogs?

Sign up to get notified of new Skyline posts.


Related Content

Spring 2019 Kentico User Group
Apr 17, 2019
Location: Waukesha County Technical College - Pewaukee Campus - 800 Main Street, Pewaukee, Wisconsin 53072 - Building: Q, Room: Q361
Blog Article
Accelerating Flow in the IT Value Stream
Bob SchommerBob Schommer  |  
Jul 21, 2020
Every CIO grapples with how to rapidly turn customer needs or good business ideas into working software to meet the demands of a VUCA (volatile, uncertain, complex, and ambiguous) world. With traditional waterfall development methodologies, it frequently takes months (or even years) before...
Blog Article
How API Integrations Can Give Your Business One Source of Truth
Nick DopkinsNick Dopkins  |  
Feb 25, 2020
As an organization grows, so does its IT stack and the amount of applications it manages. If left unchecked, this can result in a multitude of disjointed programs that duplicate data, repeat logic, and know nothing about each other.   Implementing API integration to formulate one source of...
Blog Article
Fabric React Primer on Components, Controls and Theming
Will SpieringWill Spiering  |  
Nov 12, 2019
React is one of the most used and beloved JavaScript libraries for building user interfaces. There's no shortage of UI frameworks out there to help make developing great React apps quicker and simpler. You may have heard of a couple of the really popular ones like React Bootstrap or...
Blog Article
Using Hooks to Reactify a Plain JavaScript Library: A Walkthrough
Andrew PetersenAndrew Petersen  |  
Aug 06, 2019
React Hooks make it really easy to wrap a vanilla JavaScript library with a React component so you can easily reuse it throughout your app and stay in "React Mode".In this walkthrough I'll be focusing on a single library, Shave.js, but the techniques and ideas should be applicable...