Bad bug report
Cons
- Title: "Login bug" — no behavior, no condition
- Steps written as a paragraph instead of numbered
- "Doesn't work" with no expected vs actual
- No build number, browser, or test account
- No screenshot, log, or linked test case
Guide
How to write a bug report
How to write a good bug report with example: repro steps, expected vs actual, environment, triage fields, and a filled-in sample defect report.
Updated 5 min read
The minimum useful report
If a developer cannot reproduce the bug from your write-up, it will bounce back or sit idle. The minimum is: steps, expected, actual, environment, and one piece of evidence.
Bad vs good bug reports
Good bug report
Pros
- Title states condition + broken behavior
- Numbered repro from a clean starting state
- Expected and actual on separate lines
- Environment: build, browser, OS, test user
- Screenshot or log attached, linked TC step
Defect report format
Fields that speed up triage
| Field | Who sets it | Why it matters |
|---|---|---|
| Title | QA / reporter | Routes the issue mentally before opening the ticket |
| Repro steps | QA | Lets dev reproduce without guessing |
| Expected vs actual | QA | Clarifies the gap between spec and behavior |
| Severity | QA | Communicates user impact |
| Priority | PM / lead | Orders the fix against other sprint work |
| Component / module | QA | Routes to the right team |
| Environment | QA | Build, browser, OS, test account |
| Linked test case | QA | Traceability back to the failing step |
Bug report quality checklist
Before you click Submit, run the report through this list. It is the difference between a dev fixing it in one pass and the ticket bouncing back twice.
Bug report quality checklist
- Title leads with the condition and the broken behavior
- Numbered repro steps from a clean starting state
- Expected and actual results on separate lines
- Environment: build number, browser, OS, test account
- Severity reflects observed impact, not personal frustration
- One piece of evidence attached: screenshot, video, or log
- Linked to the failing test case ID and step number
Bug report template example
BUG-1042 — Checkout fails when coupon has trailing space
Title: Checkout fails when coupon code has trailing space
Severity: High | Priority: High | Module: Checkout
Environment: Chrome 125, Windows 11, staging build 408, user test.checkout@example.com
Steps: 1) Add item to cart 2) Open checkout 3) Enter coupon SAVE10 with trailing space 4) Click Apply
Expected: Discount applies and total updates
Actual: Spinner runs indefinitely, total unchanged, no error message
Evidence: Screenshot attached from CHECKOUT-03 step 4
Fields that speed up triage
- Severity: user impact (see <a href="/guides/severity-vs-priority" class="font-bold text-link hover:underline">severity vs priority</a>)
- Priority: fix order (often set by PM)
- Component / module: where to route it
- Regression: did this work before?
- Linked test case and step: traceability back to the run
From the runner
Failing a step in QA Workspace opens a defect drawer with the test ID, step number, expected result, and any screenshot you captured. You add a title and severity. Most of the busywork is already done.
Step-by-step
- 1
Write a specific title
Lead with the broken behavior: "Checkout fails when coupon code has trailing space".
- 2
List reproduction steps
Numbered steps from a clean starting state. Include test data you used.
- 3
State expected and actual
Expected: order total drops by 10%. Actual: spinner runs forever, no error.
- 4
Add environment details
Browser, OS, build number, test account, feature flags if relevant.
- 5
Attach proof
Screenshot, video, or log snippet. QA Workspace attaches the screenshot from the failing step automatically.