What Does a Bad Bug Report Look Like (And How to Make it Right!)

Testing software is hard work. It has only become harder today, especially when “vibe coding” is a thing and new apps or updates ship at breakneck speed. However, bugs ship just as fast. And, for a quality assurance professional or a PM, nothing feels more maddening than spotting a critical bug, reporting it, and then hearing back from developers: “I can’t reproduce this. What does that even mean? It doesn’t have enough info”.

A bad bug report wastes everyone’s time, causes delays, and may leave team members in disarray during follow ups, bug triage meetings, or sprint retrospectives. Luckily, writing effective bug reports is just about following a simple format with a few tweaks that works unequivocally.

Also Read: Bug Tracking Metrics: What to Measure and Why they Matter?

Before moving ahead with the granular details and examples, here’s a quick summary table for it.

Here, we’ve drilled down on the parts of a typical bug report that might throw a developer off guard after receiving it for debugging. Plus, it covers examples and steps to how to make them right.

Example 1: Missing Visual Proof (Screenshots or Videos)

A bug report with missing or unannotated visual proof forces the developer to scour through text to guess what the screen looks like. And this doesn’t do a favor to anyone.

• Example: Explaining a weird or incorrect layout bug using only words ("The text is sort of hiding behind the image on the left side").
• Why it is bad: Words can be misunderstood or may not even make any sense for taking further debugging actions. Visuals cannot.

How to Provide Good Proof using Visuals for Bug Reports

• Take a screenshot or record a quick video of your screen when the bug happens.
• If you take a screenshot, it's best to add annotations or markups to highlight the issue area. For instance, you can use an arrow or draw a red box around the exact problem area.
• Attach the file directly to your bug report ticket.

Example 2: The Vague Title

A bad bug report often starts with a lazy title. If a developer looks at a title and has no idea what part of the app is broken, there’s a pretty good chance that the bug report gets outright rejected. Or it may remain buried in the backlogs there until someone accidently stumbles on it or not.  

• Example of a Bad Bug Title: "The button is broken" or "App crashes when I click"
• Why it is bad: Which button? What app page? What happens when it crashes?

How to Write a Good Bug Title for a Bug Report

A good title instantly tells the developer exactly what is wrong in one sentence.

1. Name the page or feature you are on.
2. Name the action you took.
3. Name the result you got.

The Good Example: "Checkout Page: 'Pay Now' button freezes the screen when using a Visa card."

Example 3: Unclear Bug Reproduction Steps

If developers cannot reproduce the bug on their own system, they just cannot fix it. A bad report just says what went wrong, but not how to reproduce it with clarity and complete context.

• Example of Bad Steps to Reproduce: "I tried to log in and got an error screen. Please fix it."
• Why it is bad: The developer does not know what username you used, what page you started on, or what buttons you clicked before the error happened.

How to Add Steps to Reproduce for a Bug Report

Writing a numbered list works best. Here’s how:

1. Go to www.xyz.com/login.
2. Enter the test email "test@test.com" and password "12345".
3. Click the "Submit" button.

Expected Result: It should take me to the user dashboard.

Actual Result: A blank white screen appears with a "500 Error" text.

Also Read: What are the Key Challenges in Bug Reporting Workflows (And How to Tackle Them)?

Example 4: Missing System and Browser Info

While documenting a bug, there may be cases when the error shows on the reporter’s computer but the same feature/function works perfectly fine on the developer's system. Why? Because the reporter might be using browsers or phones different from the one used by developers. A bad report leaves these details out. Or worse. It may not contain all the critical info required for fixing.

• Example: "The video does not play."
• Why it is bad: The video might work on Google Chrome, but break on Apple Safari. If you do not tell the devs you are using Safari, the developer might test it on Chrome, see it works, and close your ticket.

How to Include the Right System Info

What works best is to list out your setup at the bottom of your report.

• Device: iPhone 13 / Dell Laptop
• Operating System (OS): iOS 17 / Windows 11
• Browser: Chrome Version 120 / Safari Version 16

Also Read: What are the Most Common Challenges in Debugging (with Examples)?

Example 5: Missing Console Logs and Network Requests

While visual proof shows a developer what broke on the screen, technical logs show them why it broke behind the scenes. A bad report expects the developer to guess what the server or browser was doing at the time of the crash.

• Example of Bad Technical Context: "The page loaded forever and then crashed".
• Why it is bad: The developer doesn't know if this is a frontend UI freeze, a slow database query, or a blocked API call (like a CORS error).

Pro Tip: For complex API bugs, what works best is to export and attach a HAR (HTTP Archive) file.

How to Include Technical Context for Bug Reports

1. Open the browser’s Developer Tools (F12 or Right-Click > Inspect).
2. Take a screenshot of the Console tab (especially any red text/errors).
3. Take a screenshot of the Network tab (look for failed requests in red, like 404 or 500 status codes).

Also Read: How to Easily Download and Share Chrome Console Logs for Bug Reporting?

Example 6: Missing Environment, Build, and State Data

Software behaves differently depending on exactly where and how it is running. A report that just says "iOS 17" is good, but missing the app version or the specific user state can still lead to a "works on my machine" response.

• Example of Bad Environment Data: "Tested on Staging server."
• Why it is bad: Staging servers get updated constantly. The bug might exist in Build #104 but was already accidentally fixed (or worsened) in Build #105. Additionally, the bug might only happen to users with a specific account setting.

How to Include Good Environment Data

• Environment: Production, Staging, or Local.
• App Version/Build: e.g., v2.4.1 (Build 890).
• Test Data/State: Include the specific User ID, Account Tier (e.g., "Free User" vs "Premium User"), or product ID used during testing.

Example 7: Not Including Bug Frequency and Severity

Not all bugs happen 100% of the time, and not all bugs are showstoppers. A bad report leaves the developer and PM guessing how urgently the bug needs to be fixed and how hard it will be to reproduce.

• Example of Bad Frequency Reporting: "The app crashes when I submit the form."
• Why it is bad: If the developer tries it once and it works, they might assume you made a mistake. If it’s a "flaky" bug that only happens sometimes, they need to know that upfront so they can test it multiple times.

How to Include Frequency/Severity Info

1. Frequency: Does it happen every time? (e.g., "Frequency: 5/5 times" or "Frequency: Intermittent, ~1/10 times").
2. Severity/Impact: Does this block a core feature, or is it just a minor visual glitch? (e.g., "Severity: Critical – blocks all user checkouts").

Example 8: Reporting Multiple Bugs in the Same Report

Sometimes QA may find multiple bugs on the same page and put them all in one big ticket to save time. And this can be a nightmare for PMs and developers to handle.

• Example: "Home Page issues: The logo is too small, the login link is broken, and the footer is blue instead of black."
• Why it is bad: Different developers might need to fix these different issues. If one developer fixes the logo but not the link, do they close the ticket or keep it open? It causes a mess.

How to Report Multiple Bugs 

It's best to stick to the golden rule: One Bug = One Ticket.

• Make a separate report for the logo.
• Make a separate report for the login link.
• Make a separate report for the footer color.