Weak
Checkout broken. Button did nothing.
Missing context, setup, exact steps, expected behavior and evidence.
QA guide · Evidence-first reporting
How to write a bug report that another tester can reproduce
A useful bug report is not a diary entry. It is a compact evidence package that lets another person reproduce the problem, judge impact and decide what to do next.
Use this six-part report structure
- Title: behavior + context + result.
- Environment: browser/device/build/account state when relevant.
- Preconditions: the state needed before step 1.
- Steps: the minimum sequence that reproduces the problem.
- Expected vs actual: separate the requirement from the observed behavior.
- Evidence + impact: screenshot/video/log reference plus why the issue matters.
Weak vs stronger example
Stronger
Chrome 153 · Cart with 1 item · Pay now leaves checkout unchanged after valid form submission.
Then list exact steps, expected navigation, observed result, timestamp and screenshot.
Evidence checklist
- Can a teammate reproduce it without asking you a question first?
- Did you capture only relevant evidence, not unrelated private data?
- Does the title identify the user action and failure?
- Are expected and actual results written separately?
- Did you record environment and state that could change the outcome?
- Did you avoid guessing the root cause without evidence?
Practice task
Open the QA Lab and choose one finding. Write the report before reading the answer key. Then score it on reproducibility, evidence quality and impact reasoning.
Ferramenta gratuita
Revise a qualidade do seu bug report antes de enviar.
O QA Evidence Generator roda localmente no navegador, dá um score determinístico de completude, aponta lacunas e exporta Markdown ou HTML pronto para PDF.
Practice it
Use a real browser exercise, not only a definition.
The QA + Security Bug Hunt Lab gives you a self-contained storefront with intentional findings, reporting templates, scoring and an answer key.
Open the QA Lab on Gumroad ↗