What is a bug? | Everything about Bugs a QA should know!

First thing first, let's quickly define it and jump to real world picture understanding

A bug is an error or flaw in an application that causes it to behave in unintended ways or produce incorrect results.

Not every bug is a bug!

But why?

Before reporting a bug/issue its highly recommended to check for its occurrence count. As if it is reported by a client (end-user) than it might not be the first time it's occurring.

Also, always make sure to know and share bug attribute (characteristics) before filing or showing your findings to development team or product managers.

What are bug characteristics?

1) Severity

2) Priority

3) Steps to reproduce

4) Issue description

5) Scenario (if more then one mention all of them one by one)

6) Expected Result & Actual Result

7) Additional information (which can help to resolve the issue)

Some of the top characteristics mentioned above are incomplete without their proper description and why they are used in a bug report (or ticket). Let's dive deep into it:

Severity & Priority

More precisely the impact of a bug on the system. It can be broadly categorized into:

• Critical: Meaning a system can fail if this kind of bug occurs like application not working, data persistence issues or data corruption.

Example:

Logging in a application as a valid user, but you get access to some other user's account. This is a critical bug because it can cause unwanted data breaches.

• High: Only difference between critical and high severity bug is the probability of occurrence. These issues can cause system failures but they occur in a specific scenario which can be bypassed by following another application flow.

Example: Discount availing service in Ecommerce applications fails on checkout but it can than be invoked in another transaction.

• Medium: Issues which do not stop the normal usage of the application. Until a specific scenario occurs. But these do not hinder normal usage of the application.
• Low: These bugs can easily be overlooked even by the clients as well. They could be a slight alignment issue in certain pages of the software, spelling mistakes, or low-impact usability issues like adding keyboard shortcuts for frequently used features, etc.

Note: Critical, High, Medium & Low terms can change but the true meaning remains the same.

Reproducibility

Ability to consistently replicate an issue. Now to demonstrate this reproducibility we need to provide "Steps to reproduce"

The information could be:

• Version of the Software
• Specific logs when the error occurred.
• API logs in log management tools like (ElastiSearch, Graylog, etc)
• Log files in the machine where the application is running.
• Network or console tab logs in case of web applications
• Specific configuration in which the error is occurring.
• Platform in which the software is running. It could be a web-based application, mobile app, desktop app, or any platform.
• Proxy traffic to get API calls, logs etc. in case of mobile applcations

With the information provided, the product managers can decide whether it’s truly a bug or a hidden gem, uncovering any quirks in the requirements. The developer can easily use the information in the bug report to swiftly spot it, squash it, and get back to their coffee break!

Issue Description

High level information which outlines the issue. Basically can provide a summary about the bug.

Now there 2 key areas to understand:

1) Issue Headline: This should display the bug/issue concern

2) Issue Description: This should provide a brief summary about the bug.

Example:

Issue Headline: Unable to add products the cart

Issue Summary: When user tries to add items with product category "mobile phones" than cart display "empty cart, please add products to purchase" message.

Scenario

When does an issue/bug occur? If it occurs several times in different ways than its better to mention each scenario separately with its steps to reproduce.

Expected Result & Actual Result are self explanatory, hence skipping it.

Additional Information

There are other attributes like:

• Environment (the place where the application is run)
• Attachments (screenshots or screen records) related to the bug
• Assigned To (person/team the bug is reported to)
• Status (current state of the bug “assigned”, “in progress”, “fixed”, etc)
• Comments/Notes (other observations, possible workarounds, root cause)

When this information is collected from the QA, a bug report is filed

Note: Only submit a bug report if you are certain about the issue. If unsure, always seek approval from the responsible party beforehand.

The point of writing a problem report (bug report) is to get bugs fixed” — Cem Kaner.

QA & SDET free resources video: https://youtu.be/BQtrEgplpDA?si=quZzU6E4IKY8SxgH

I hope this helps article provides the necessary understanding to create an effective bug report which maximizes the throughput of developers. Let me know in comments, if I missed any critical aspect of bug reporting!

-x-x-

Watch latest SDET & AI Trends on my YouTube channel: Link

Get access to 1050+ SDET Interview Q&A for 2025: Link

#japneetsachdeva