Practical QA guide · 10 min
How to Write an Effective Defect Report
Write clear, reproducible, evidence-backed defect reports with useful titles, expected and actual results, severity, context, and linked test coverage.
Written and reviewed by ShiftQA Labs QA Education Team · Updated September 2, 2026
Browse Lessons modules
Lead with the failed behavior
A title such as “Checkout broken” is difficult to search and triage. A stronger title names the condition and consequence: “Guest checkout displays a success message after the payment request returns 500.” It distinguishes the symptom without guessing at the root cause.
State the expected result from an agreed requirement, business rule, design, contract, or reasonable quality expectation. Then record the actual observation precisely. Avoid combining several unrelated failures into one report simply because they appeared during the same session.
Make reproduction efficient
Include the smallest reliable set of preconditions, data, actions, and environment details. Identify build, browser or device, account role, route, and occurrence pattern when relevant. Remove credentials and personal data from reports and screenshots.
Evidence should clarify the report, not overwhelm it. A focused screenshot, console entry, network response, video segment, or data comparison is more useful than an unfiltered log dump.
Separate severity, priority, and confidence
Severity describes impact on the product or user. Priority reflects when the organization should address the issue. They influence each other but are not interchangeable. A visible typo can be urgent before a campaign while remaining low severity; an unlikely data-loss path can be severe even if scheduling requires discussion.
When evidence is incomplete, classify the item as a risk to validate or an inconclusive test rather than overstating it as a confirmed defect. Trust improves when reporting preserves uncertainty honestly.
Worked example
Evidence-backed search defect
Product search shows unrelated results when the query contains a hyphen.
- 1Title: Product search ignores the term after a hyphen and returns unrelated items.
- 2Precondition: catalogue contains “blue-shirt” and unrelated products; search index is current.
- 3Steps: open /products, enter “blue-shirt”, submit search, and inspect displayed results.
- 4Expected: results match the complete query or a clear no-results state appears.
- 5Actual: the interface appears to search only “blue” and includes unrelated blue products.
- 6Impact: users cannot reliably find products whose searchable names contain hyphens.
- 7Evidence: query screenshot, result list, request payload, response excerpt, and linked failed test execution.
Frequently asked questions
Questions testers ask
Should a defect report propose a fix?
A recommendation can help, but avoid presenting an unverified implementation guess as the confirmed root cause. The primary job is to describe the failed behavior and evidence accurately.
How much evidence should I attach?
Attach enough focused evidence to demonstrate and reproduce the result. Prefer relevant excerpts over large unsorted logs.
What if the failure cannot be reproduced?
Preserve the original evidence and mark current reproduction as intermittent or inconclusive. Record conditions investigated rather than closing it solely because one retry passed.