Template
Bug report template and filled example
Capture a defect another person can reproduce. Includes a fictional report showing build details, precise steps, expected behaviour and safe evidence handling.
Download editable MarkdownHow to use this
Useful for: Testers, developers and support teams turning an observation into an actionable issue.
Write the title around the failing behaviour and the condition that triggers it. Describe one problem per report so triage and verification do not become several unrelated conversations.
Try the steps in a fresh session before sending the issue. Specify the starting data and permissions; hidden setup is a common reason a developer cannot reproduce a failure.
Keep expected behaviour separate from observed behaviour. Link the requirement or decision supporting the expectation, and mark assumptions that still need product confirmation.
Use test accounts and redact evidence. Record frequency and user impact without assigning a business priority you do not own; the triage team can decide that from the evidence.
Scope and limitations: The filled example is fictional and uses a test account. Remove confidential data, access tokens and customer information before sharing a report outside the team.
Document preview
# Bug report ## Blank template - Title: [action] produces [observed failure] when [condition] - Product / build / environment: - Browser or client / operating system: - Test account role and starting data: - Preconditions: - Steps to reproduce (numbered): - Expected result and requirement reference: - Actual result: - Reproduction frequency: - User impact and affected scope: - Evidence links (redacted screenshots, request IDs, logs): - Workaround / related issues: - Retest build, date, tester and result: ## Filled example — fictional Title: Removing the last basket item leaves the previous subtotal visible Environment: staging; build demo-42; desktop Chromium; standard test buyer. Precondition: a new basket contains one test product priced at 20 EUR. No discount or delivery charge is applied. Steps: 1. Sign in with the staging buyer account. 2. Add one unit of the test product to an empty basket. 3. Open the basket and confirm the subtotal is 20 EUR. 4. Remove the product and wait for the empty-basket message. Expected: the basket has no items and displays a zero subtotal, as specified in the basket acceptance criteria. Actual: the empty-basket message appears, but the subtotal remains 20 EUR until the page is refreshed. Frequency: reproduced in three out of three fresh sessions on the same build. Impact: a buyer can see an incorrect subtotal after removal. This observation does not establish that an incorrect payment is taken; checkout was not exercised in this reproduction. Evidence: attach a redacted recording and the test request ID to the private ticket. Workaround: refresh the basket page. Retest: pending a replacement build; repeat these steps and also check removing an item from a multi-item basket. Keep the reproduction independent of production credentials. A screenshot is supporting evidence, not a substitute for the starting state and steps.