Understanding Bug Tickets

Bug tickets is a common term in the realm of Software Quality Assurance. While, this may sound like a simple concept, coming up with an effective bug ticket is not that simple. Missing out on simple components makes the entire difference between effective bug tickets and otherwise.

A bug ticket is a formal issue report used in software tracking tools such as Jira to document, track and fix software errors.
Not to be confused with a bug report which is a document that records defects in a software.
Think of a bug ticket as a structured tool to...

• Communicating status of a bug
• Track the status of a bug

... from identification through to resolution, ensuring that they are systematically addressed by development teams.

---

Before we identify the components of a bug ticket, it is important to understand tips for writing an effective bug ticket.

Clear Title

This should be concise yet descriptive. Should summarize the issue in a few words.

• Avoid generic titles like "Problem with login"
• Replace this with specifics such as "Login button not functional on mobile devices"

Detailed description

Descriptions should be detailed and clear allowing developers to not only understand the issue but also have easy time reproducing it.

Stick to the scope

• The goal of a bug ticket is communicate and track status of a bug with a focus on resolving it. Straying away from the scope of the ticket with unnecessary information distracts from the main issue.
• Create a new ticket any related bugs unless they specifically impact the resolution. We always want to have small manageable bug tickets as opposed to one "catch them all"

Stay Engaged

It is important to maintain open communication in order to facilitate a smooth resolution process.

• Provide updates i.e. new observations related to the bug promptly on the ticket.
• Provide clarification if needed. Developers will require additional information to resolve the bug. As a tester, you therefore need to understand the bug inside-out.
• Verify - When the bug is resolved, ensure it has been successfully addressed. Defect Lifecycle

Components of a Bug Ticket

Title

This is a unique title providing a general understanding of the bug. Think of it as the affected feature and the specific problem. e.g. Application Crash on "Login" button click.

• Feature affected - Login
• Specific problem - System crash

Description

A brief description about the issue. Should give the developer context on what to look for.

Steps to Reproduce

Provide a numbered list of steps to replicate the bug. This is a crucial component.

• Note that a developer cannot fix a bug they can't reproduce.

• Start with the initial state to the point where the problem occurred.
  For example if "clicking on the checkout button" leads to a 404 page

  • Attach URL where this is initiated e.g. http://example.site/checkout NOT http://example.site/404

• Be specific and mention the specific actions/ conditions that trigger the bug.

Expected Result

Describe what should happen if the bug did not exist. This should be clear, but avoid being too verbose. An effective expected result would look like;
Given a user is on the registration page, when they’ve filled in the required fields and click on the ‘Sign Up’ CTA, then the user has successfully signed up for an account.

Actual Result

Highlight the error that is occurring.
Given a user is on the registration page, when they’ve filled in the required fields and click on the ‘Sign Up’ CTA, then the application crashes and the user is unable to create an account.

Environment

It is important to understand which environment an error is happening in order to help with setting priority.
Include information such as;

• Environment e.g. Production, QA, Development
• OS
• Browser used
• Device used (Mobile, Tablet, Desktop) and version where possible

Visual

This helps the developer understand the exact issue happening without any investigation on their end. This increases the speed of fixing.
Include error logs, screen recordings, videos, screenshots...

Priority

While this is set by business team, identifying the priority will ensure that developers are addressing the work that is most important first.
This could include: blocker, major, high, medium, low, etc.