How to report bugs developers can fix quickly

The bug report is the most-written and least-taught artifact in QA. A good one gets fixed today; a vague one bounces back with "works on my machine" or "need more info," and the bug rots in the backlog. The difference isn't effort — long reports can be useless and short ones excellent. It's whether the report lets a developer reproduce and locate the problem with minimum friction. This is the bug-report companion to writing test cases developers actually read.

The title is a one-line summary, not a category

Like a test case, the title is the only part guaranteed to be read — in a triage list of forty. Make it a specific, scannable statement of what's wrong and where:

• ❌ "Checkout broken"
• ❌ "Bug in payment"
• ✅ "Checkout: applying a second coupon removes the first instead of stacking"

A developer skimming the backlog should know what this bug is from the title alone.

Lead with reproduction steps

The single most valuable section, and the one to optimise hardest. Numbered, minimal, from a known starting point — strip everything that isn't required to trigger it:

1. Log in as a standard user with an item in the cart
2. Apply coupon SAVE10, then apply SAVE20
3. Observe the discount line

Minimal matters: if the bug reproduces in three steps, don't write ten. Every extra step is something the developer has to do and something that might be the "wrong" path that gets it closed as not-a-bug.

Expected vs actual — both, explicitly

State what should happen and what did, separately. "It's broken" forces the developer to guess what correct looks like:

Expected: both coupons apply; total reflects SAVE10 + SAVE20. Actual: applying SAVE20 silently removes SAVE10; only SAVE20 applies. No error shown.

The gap between expected and actual is the bug. Spelling out both also catches the case where you and the developer disagree on what correct behaviour even is — which is itself worth surfacing.

Add the evidence that localises it

Attach what turns "I believe you" into "I can see it":

• A screenshot or screen recording (a 10-second clip beats a paragraph for UI bugs).
• The exact error message, copied as text (not just "it errored").
• For anything technical: the failing request/response, console errors, or relevant log lines. A 500 with the stack trace is a near-instant fix; "the page broke" is a day of back-and-forth.

Specify the environment

Bugs that reproduce only in some conditions need those conditions: browser/device and version, OS, environment (prod/staging), user role, and any relevant data state. "Only on Safari", "only for accounts with no billing address", "only in staging" is often the clue that locates the bug — and its absence is why "can't reproduce" happens.

Note severity and impact, honestly

Help triage by saying what it costs: does it block a core flow, lose data, hit every user or a rare edge? Be accurate, not inflationary — a tester who marks everything critical gets ignored. "Blocks checkout for all users" earns urgency; "minor visual misalignment on the settings page" earns honesty and trust.

Where this fits

A clear bug report is the output of good testing — it's what makes exploratory findings actionable and what reviewers look for in a portfolio. The test case & plan templates include a bug-report format, and the common bugs library shows well-described defects by category.

Before you file a bug

• Title is a specific one-line summary (what's wrong + where), readable in a triage list
• Reproduction steps are numbered, minimal, from a known starting point
• Expected and actual are stated separately and explicitly
• Evidence attached: screenshot/clip, exact error text, failing request/logs
• Environment specified (browser/device, OS, env, role, data state)
• Severity/impact noted honestly, not inflated