Testing mode

All qa.cafe features are currently free. Features and test data can change before launch.

Defect reportingPrintable checklistUpdated August 2026

Bug report quality checklist

Write defect reports that help a team reproduce the problem, assess risk, and choose the next action.

Download a clean Markdown copy and adapt it in your team workspace.

Download template No signup or tracking gate.
01

Lead with observable behavior

A useful title identifies the affected behavior, condition, and failure. Avoid titles such as Product is broken or Login issue. The reader should understand the problem before opening the report.

Describe the expected result from an agreed requirement, product rule, or consistent user expectation. Describe the actual result without guessing at the implementation cause.

  • Name the affected feature or journey.

  • Include the condition that triggers the failure.

  • Describe one observable failure in the title.

  • Separate expected and actual results.

02

Make reproduction efficient

Provide the shortest reliable sequence that starts from a known state. Include account role, data, environment, build, browser, device, or API client only when those details can affect the result.

State the observed frequency. If the failure is intermittent, describe how many times you saw it and what changed between attempts. Do not call a defect random when relevant state is unknown.

  • Start from a clear precondition.

  • Use numbered actions with exact values where they matter.

  • Remove actions that do not contribute to reproduction.

  • Record frequency and relevant state changes.

  • Confirm that attachments match the written steps.

03

Explain impact without inflating severity

Describe who is affected, what task they cannot complete, and whether a safe workaround exists. Add evidence of data loss, security exposure, financial effect, or operational cost when you have it.

Severity describes impact. Priority describes when the team chooses to act. Follow the team definition for each field and record uncertainty when evidence is incomplete.

Copy-ready structureMarkdown
Title: [Feature] fails to [expected behavior] when [condition]

Environment: [build, environment, client]
Precondition: [account, state, and data]

Steps:
1. [Action with exact input]
2. [Action]
3. [Action]

Expected: [Observable correct result]
Actual: [Observable failure]
Frequency: [Attempts and failures]
Impact: [Affected user or business task]
Workaround: [Available workaround or none known]
Evidence: [Logs, requests, screenshots, video, or query]
Notes: [Scope, comparison, or remaining question]

Use it with your team.

Keep the parts that support a decision. Change the rest to match your product and workflow.

Download Markdown