Skip to content
← Back to Codex
QA7 min read

QA Fundamentals: Bug Reports That Get Fixed

A bug that's reported poorly is a bug that stays open for months. I've seen critical issues sit in backlogs for entire quarters because the report was a one-liner like "checkout is broken." The developer couldn't reproduce it, so they marked it "needs info" and moved on.

Writing effective bug reports is one of the highest-leverage skills a QA engineer can develop. A good report gets fixed in hours. A bad report gets triaged into oblivion.

The Anatomy of a Good Bug Report

Every bug report needs five things. Miss any one of them and you're adding friction to the fix:

1. A Specific Title

The title should tell a developer whether this bug is relevant to them without opening the ticket.

Bad: "Login doesn't work" Good: "Login fails with 500 error when password contains special characters"

Bad: "Page is slow" Good: "Dashboard takes 12s to load when user has 500+ projects"

The title is a search string. Six months from now, when someone hits the same bug, they'll search for it. "Login doesn't work" matches everything. "500 error password special characters" matches exactly this issue.

2. Steps to Reproduce

This is where most bug reports fail. The developer needs to see the bug themselves before they can fix it. Give them an exact recipe:

Steps to Reproduce:
1. Go to /login
2. Enter email: testuser@example.com
3. Enter password: P@ss&word!123
4. Click "Sign In"

Expected: User is logged in and redirected to /dashboard
Actual: 500 Internal Server Error is displayed. Network tab shows
        POST /api/auth/login returns 500 with body:
        {"error": "XML parsing error: unexpected character"}

Notice what's specific: the exact URL, the exact input that triggers the bug, what the API actually returned. A developer can reproduce this in 30 seconds.

3. Expected vs. Actual Behavior

Always state both. "It's broken" doesn't tell the developer what should happen. Maybe the developer thinks the current behavior is correct and you're misunderstanding the spec. Stating your expectation surfaces that disagreement early.

4. Environment Details

I've seen bugs that only reproduce on Firefox, only on Windows, only for users with a specific permission set. Without environment info, the developer tries it in their default setup, can't reproduce, and closes the ticket.

5. Evidence

Attach everything that helps:

A screenshot with a red circle around the broken element saves five minutes of "what exactly do you mean by 'misaligned'?"

Severity vs. Priority

These are different and getting them right determines how fast your bug gets fixed:

Severity is how bad the impact is:

Priority is how urgently it needs fixing:

A typo on the homepage is low severity but might be high priority (it's the first thing users see). A crash in an admin-only debug panel is high severity but low priority (three people use it). Understanding this distinction helps you communicate effectively with product managers.

Common Mistakes

The Novel

A 2000-word bug report that includes the entire history of how you found the bug, what you were trying to test, and your theories about the root cause. Developers skim. Put the reproduction steps first, theories last.

The One-Liner

"Search is broken." Which search? What did you search for? What happened? What should have happened? What browser? This ticket will sit in "needs info" forever.

Duplicate Without Checking

Before filing, search for existing reports. Duplicate bugs waste everyone's time and split the conversation across multiple tickets. If you find a duplicate, add your reproduction scenario as a comment — different repro steps often reveal the root cause faster.

Burying the Lead

If you found a security vulnerability or data loss bug, say so immediately. Don't bury "user passwords are visible in the API response" after three paragraphs of context. Lead with severity.

Opinion as Bug

"The button should be blue instead of green" is not a bug — it's a design opinion. File it as a suggestion or bring it up in a design review. Bug trackers should be for things that are objectively wrong: crashes, incorrect data, spec violations, broken functionality.

The Template I Use

## Summary
[One sentence describing the bug]

## Steps to Reproduce
1. [First step]
2. [Second step]
3. [...]

## Expected Behavior
[What should happen]

## Actual Behavior
[What actually happens]

## Environment
- Browser: [e.g., Chrome 125]
- OS: [e.g., macOS 14.5]
- User role: [e.g., admin, regular user]
- URL: [exact page URL]

## Severity / Priority
[e.g., Major / P1]

## Evidence
[Screenshots, recordings, logs]

## Notes
[Any additional context, workarounds, or theories about root cause]

What I've Learned

The best QA engineers I've worked with write bug reports that developers thank them for. Not because they're polite — because the reports are so clear that the developer can go from "reading the ticket" to "pushing the fix" in under an hour.

Every minute spent writing a clear bug report saves ten minutes of back-and-forth in ticket comments. It's the most undervalued skill in QA.