Bug report template: steps, evidence and retest status

Copy this bug report template

Use one report for one independently reproducible failure. Select the field lists below as ordinary text. Replace bracketed fields, remove irrelevant rows and leave unknown values marked Unknown. Adapt the suggested report statuses to your team's workflow.

• Title: [Action + observed failure + relevant context]

• Status: [Observed / Confirmed / Fix proposed / Awaiting retest / Closed]
• Reporter and observation time: [Name or role; timestamp with time zone]

• Environment:
• Application and environment: [Product; production/staging/local]
• URL: [Exact route and relevant safe query state; remove secrets and personal data]
• Build or commit: [Identifier, or Unknown]
• Browser and version: [Name/version]
• Operating system: [Name/version]
• Viewport: [Actual width × height in CSS pixels; zoom and device scale if relevant]
• User state: [Signed out / approved test role; no credentials]
• Preconditions: [Required feature flag, safe fixture, starting state]

• Steps to reproduce:
• [Start from a named route and state]
• [Perform one action]
• [Perform the action that exposes the failure]

• Expected result:
• [Observable behavior required by specification or agreed expectation]

• Actual result:
• [What happened; exact message, visible state or destination]

• Reproducibility:
• [Observed failures / attempts; conditions; unknowns]

• Impact and triage:
• User impact: [Task affected and available workaround]
• Severity: [Suggested level + reason; use team's definitions]
• Priority: [Owner-assigned order, or Proposed + reason]

• Evidence:
• [Restricted screenshot/video/log link and what it proves]
• [Measurement or assertion result, if available]
• Missing evidence: [Unknown/unavailable evidence]

• Possible cause:
• [Hypothesis, clearly labeled; optional]

• Fix and retest:
• Fix reference and deployment: [Commit/PR/build; or None]
• Retest target/build/time: [Same route and equivalent conditions]
• Retest outcome: [Passed / Failed / Blocked / Not run]
• Evidence and remaining limits: [Links; untested paths]
• Resolution owner: [Who accepts closure]
• Changed or untested conditions: [Differences from original check; remaining coverage gaps]

Do not paste passwords, cookies, access tokens or customer records into the report. Evidence should be accessible to the people investigating it, with sensitive details removed.

Filled bug report example

Synthetic worked example; not executed. The application, build identifiers, observations and attempt counts below are invented to demonstrate the format. This is not a customer incident, an executed Sybqa run or evidence about a real website.

Title: Escape leaves mobile navigation open on the pricing page.

Status: Confirmed within this fictional scenario; no fix recorded.

Environment: Demo Shop, staging; https://demo-shop.example/pricing; synthetic build demo-a17; Chromium version Unknown; Windows version Unknown; viewport 390 × 844 CSS pixels; signed out. The navigation has an agreed requirement that Escape closes the open menu and returns focus to its trigger.

Steps to reproduce:

1. Open the pricing route with the menu closed.
2. Select the button labeled “Menu.”
3. Confirm navigation links appear, then press Escape.

Expected result: Navigation closes and keyboard focus returns to the Menu button.

Actual result: Navigation remains visible. Focus restoration cannot be assessed because the close action did not complete.

Reproducibility: Fictional observation: the menu stayed open in 2 of 2 invented attempts from the same starting state. Other browsers and viewport widths were not tested.

Impact: A keyboard user cannot dismiss the menu using the documented key. Selecting the Menu button again is a workaround in this scenario.

Severity: Proposed moderate functional/accessibility impact under the team's example definitions. Priority: Proposed for the next triage discussion; no release-blocking decision made.

Evidence: Illustrative example; no recording exists. A recording would need to show the starting state, open action, Escape input and menu afterward. A screenshot alone would not prove which key was pressed.

Possible cause: Unknown. Event handling is a hypothesis to investigate, not an established defect location.

Fix/retest: No fix proposed. Retest Not run. Closure requires checking the same requirement on the deployed fix under equivalent conditions.

Separate observation from hypothesis

You do not need to know the cause before reporting a bug. “The menu stays open after pressing Escape” is an observation. “The event listener is missing” is a possible explanation until someone checks the code. Keeping those separate gives the person fixing the issue a clearer starting point.

“Looks wrong” gives a developer little to reproduce. Describe a state or behavior: a required-field message is absent, a navigation destination differs from the approved route, or content overflows the measured viewport.

Name the source of the expectation. It might be an acceptance criterion, a documented keyboard interaction or an agreed design. If expected behavior is unclear, report a question needing review. Do not turn a preference about spacing or wording into a confirmed defect.

Record the actual viewport rather than “mobile.” Record a build when available rather than “latest.” These details help distinguish a persistent failure from a different deployment, session or layout.

Keep severity separate from priority

Severity describes the effect of the defect. Priority describes when the team chooses to address it. A broken primary journey and a small visual inconsistency have different consequences, but urgency also depends on exposure, workarounds and release plans.

Use your team's definitions. Explain observed impact and suggest severity when appropriate; leave scheduling with the responsible owner. Do not invent affected-user counts or revenue losses when those facts are unavailable.

Retest under equivalent conditions before closing

A merged change proves code entered a branch. It does not prove the right build reached the test target or that the original failure disappeared.

Retest the same claim after verifying the deployed build. Preserve the route, initial state, viewport and assertion where possible. Record changed conditions so a reader can judge whether the comparison is equivalent. If the browser version, role, fixture, feature flag or starting state differs, name the difference and keep closure awaiting review when it affects the assertion. A result on a different route or an unidentified build is not an equivalent retest by default.

Use Passed when the stated assertion was checked and held. Use Failed when it was checked and did not hold. Use Blocked when a prerequisite prevented the check, and Not run when it was not attempted. A passing retest covers the tested claim; it does not establish every browser, account role or business outcome.

Use available evidence for the handoff

Sybqa starts with a URL and an optional goal. You review the browser test plan, then inspect available recorded steps, screenshots and the evidence report. Use those observations to fill the template, share a fix brief and retest the original failure after a change. Sybqa does not edit or deploy your code.

Use the website launch checklist to choose an area to check, or the vibe testing workflow to turn a broad goal into a bounded assertion.

A read-only run or visible signup/payment screen does not prove the transaction completed. A screenshot alone does not prove keyboard input, persistence, email delivery or a payment outcome. Record the assertion and supporting evidence you actually have; keep missing proof explicit.

Inspect the website QA report example to see how evidence and coverage limits are presented.

Sources

• Sybqa vibe testing guide: reviewed plans, fix handoffs and retesting

Related

• Website launch checklist: 30 checks for AI-built sites
• Vibe testing: check AI-built sites with evidence

Try Sybqa on your site

Explore bugs, UI consistency and user journeys from a reviewed plan. Inspect browser evidence and visual review leads in the report. The free plan gives 10 runs a month without AI review after you sign up. See pricing.

Add your site link here and it will be waiting in the console after you create an account. Then describe one journey to check and review the test plan before any run starts.