What Is a Bug Report? Meaning, Definition, and Good Vs. Bad Examples

TL;DR:

• A bug report is a documented record of unexpected behavior in a website or app.
• A strong bug report template makes bugs easier to reproduce, prioritize, and fix.
• The difference between a good bug report and a bad one comes down to specificity and context.
• The best bug reports include steps, expected vs. actual results, environment details, and visual evidence.

Bug reports seem simple. You find something broken. You log it. The development team fixes it.

However, in reality, there’s more that goes into a bug report than you might think. A bad bug report creates delays fast. Developers can't reproduce the issue, QA gets pulled into follow-up questions, and bugs sit in the backlog because nobody has enough context to act.

In this guide, you'll learn what a bug report is, what goes into a reusable bug report template, and what separates a good bug report from a bad one. You'll also get a practical template and clear examples you can use right away.

What is a bug report?

A bug report is a documented record of unexpected behavior in a website or application, containing enough context for developers to reproduce the issue, understand its impact, and fix it.

What makes a bug report good?

A good bug report is more than a casual message in Slack or a paragraph in an email thread. A proper report creates a paper trail. It keeps the issue searchable, trackable, and tied to the wider QA process instead of getting lost in chat.

Bug tracking is the process of logging and monitoring bugs during website or software testing. Large systems can have hundreds or thousands of defects that need to be evaluated, prioritized, and tracked over time. As a result, bug reports are usually captured inside a project management and bug tracking tool rather than dropped into an ad hoc conversation.

An effective bug report also reduces back-and-forth. Instead of a developer replying with "Which page?", "Which browser?", or "Can you send a video?", the key facts about the reported bug are already there. That process speeds up bug triage, makes prioritization easier, and lowers the chance that a real issue gets ignored because the report was too vague to act on.

One quick distinction before going further: this guide is about the QA sense of "bug report" – a written record a person creates to describe a defect. That's different from a system-level bug report file, like the diagnostic export Android generates through adb bug report, or the one Apple's Feedback Assistant collects from developers. Those detailed reports capture device logs and stack traces automatically, rather than a description, steps to reproduce, or the context a QA bug report provides.

If you want the detailed step-by-step process to creating a well-written bug report, read our guide on how to write a bug report.

What goes into a bug report template?

A bug report template turns random bug logging into a repeatable process.

Consistency makes triage faster. When every report follows the same structure, your team spends less time decoding the issue and more time fixing it.

If you're ready to write one right now, follow our guide on how to write a bug report that is linked above for the full step-by-step process. Or read on to learn what a bug report is made of, field by field:

Bug ID and title

A bug ID gives the issue a unique reference inside your system. The title should summarize the problem in one line. It needs to be specific enough that a developer can understand the issue without opening the full report.

Description

The description explains what's happening and where the bug appears. This is the place for context, not a duplicate of the steps field. A good description helps the reader understand the scenario, affected flow, or business impact.

Steps to reproduce

This field is the most important one in the report. List the exact actions needed to trigger the bug in order. If the developer can't reliably reproduce the issue, the fix gets slower.

Expected behavior vs. actual result

This section removes ambiguity about the reported bug. Write two short statements: what should happen and what actually happens instead. You need to make the defect instantly clear to anyone reviewing the issue.

Severity and priority

These fields are related, as they both help teams separate major from minor bugs, but they're not the same. Bug severity describes how serious the bug is from a technical or user-impact perspective. Bug priority describes how urgently the team should fix it from a business perspective. A bug can be high severity but lower priority, or vice versa, depending on the release context.

Environment details

Environment details tell the team where the bug occurs. That usually includes the browser and browser version, operating system, device, screen resolution, and URL. If you write bug reports without that context, bugs that only appear in a specific setup, like mobile Safari, can be dismissed as "not reproducible."

Screenshots, video, and logs

Visual evidence makes a bug report much easier to action. A screenshot shows exactly what the reporter saw. Video helps when the issue depends on timing or a multi-step flow. Logs add technical context that speeds up debugging.

This is where modern bug report software helps a lot. Marker.io is a bug tracking system that auto-captures metadata, screenshots, technical logs, browser, OS, webpage, and screen size, and it also supports session replay, so teams can see what happened before the issue was submitted. The reporter does less manual work, while the developer gets more usable context in one place.

Visit our article on bug report templates for the template you need, which you can then copy and adapt.

What makes a good bug report vs. a bad bug report?

A good bug report is specific, reproducible, and complete. A bad bug report is vague, missing context, and forces the developer to guess.

That's the real difference. One helps the team move straight into diagnosis. The other creates more admin work before the fix can even start. Here are the elements that separate good from bad bug report writing:

• Specific title instead of a generic complaint
• Clear steps to reproduce instead of guesswork
• Expected vs actual result instead of "it's broken"
• Environment details instead of missing context
• Visual evidence instead of a bare text note
• Severity and priority instead of blank fields

Software quality problems are expensive at scale: according to Tricentis's 2026 Quality Transformation Report, one in five organizations lose more than $1 million a year to poor software quality, and nearly half lose between $500,000 and $1 million.

Here's a quick side-by-side to see the definition in action.

A bad bug report example

Title: Checkout broken
Description: The checkout doesn't work. I tried it a few times and it failed.
Steps to reproduce: [Not provided.]
Expected result: It should work.
Actual result: It doesn't.
Severity: [Not provided.]
Priority: [Not provided.]
Environment: [Not provided.]
Attachments: [Not provided.]

Why this is bad:

• The title is vague.
• There are no reproducible steps.
• "Doesn't work" doesn't explain the failure.
• There's no browser, device, or URL.
• No screenshot or video is attached.
• The developer has to start by investigating the report itself.

A good bug report example

Title: Safari iPhone: "Place Order" button stays disabled after selecting PayPal on checkout page
Description: On the mobile checkout flow, users who select PayPal are returned to the checkout page, but the Place Order button stays disabled. This prevents checkout completion.

Steps to reproduce:

1. Open the checkout page on an iPhone in Safari.
2. Add any product to cart and proceed to checkout.
3. Fill in shipping details.
4. Select PayPal as the payment method.
5. Complete the PayPal popup flow and return to checkout.
6. Observe the Place Order button.

Expected result: After returning from PayPal, the Place Order button becomes active and the user can complete checkout.
Actual result: The Place Order button remains disabled, so the order cannot be submitted.
Severity: High
Priority: High
Environment:

• Browser: Safari 17
• OS: iOS 17.5
• Device: iPhone 14
• Screen size: 390 x 844
• URL: /checkout

Attachments:

• Screenshot of disabled button
• Session replay
• Console log showing validation error after PayPal redirect

Why this is good:

• The title describes the issue clearly.
• There is a concise but detailed description.
• The steps are specific and testable.
• Expected and actual outcomes are easy to compare.
• The environment makes the issue easier to reproduce.
• Visual and technical evidence are included.
• Severity and priority help triage the issue quickly.

Here's a quick comparison of the two:

Final thoughts

A bug report is the record that helps your team reproduce an issue, assess the impact, and move it through triage without wasting time.

Creating tracked issues with detailed information, using a solid bug report template, is what separates a report your developers can act on from one that stalls in the backlog. Most importantly, it helps your team fix bugs.

If you want the bug reporting process to be easier on both sides, use bug report software. Marker.io captures screenshots, advanced technical metadata, technical logs, environment details like browser and OS, and session replay automatically, so reporters don't have to gather everything manually and developers get the context they need in one place.

Bug report FAQs

What does it mean when your phone says "bug report"?

That error message is part of Android's built-in diagnostic feature, not the kind of bug report this article covers. Tap it, or trigger it as a developer via adb bug report, and Android packages device logs, stack traces, and system state into a file engineers use to debug device-level issues, identify software bugs, and understand what happened when an app crashes.

A QA bug report is different: it's a written record a person creates to describe a specific problem in an app or website, along with steps to reproduce it, which is what this guide is about.

What should a bug report include?

A bug report should include a clear title, description, steps to reproduce, expected result, actual result, severity, priority, environment details, and attachments like screenshots or logs. The goal is to make the issue actionable without extra follow-up.

What is the difference between a bug report and a bug ticket?

In many teams, the terms are used interchangeably. When people distinguish between them, they usually refer to the bug report as the submitted evidence of the issue, while the bug ticket is the tracked item created in the bug tracker to manage that issue through triage and resolution.

What makes a bug report good or bad?

A good bug report is specific, reproducible, and complete. A bad bug report is vague, missing context, and hard to verify, which slows down debugging and increases back-and-forth.