How to write a bug report: template and example

Part of Bug reporting

The seven parts of a good bug report

1. A specific title. Say what breaks and where: "Checkout: promo code removes the shipping line", not "Checkout broken".
2. Environment. App version or URL, browser and version, operating system, device, and the account or role you used.
3. Steps to reproduce. Numbered, in order, starting from a known state. Each step should be one action.
4. Expected result. What should have happened.
5. Actual result. What happened instead, including any error text word for word.
6. Frequency and severity. Does it happen every time or sometimes? How badly does it affect the user?
7. Evidence. A recording or screenshot, console errors, logs, and the exact time it fails in the recording.

Copy-and-paste template

Title: [Area] What breaks, in one line

Environment
- App version / URL:
- Browser and version:
- OS and device:
- Account / role:

Steps to reproduce
1.
2.
3.

Expected result:
Actual result:

Frequency: Always / Sometimes (x of y tries) / Once
Severity: Blocker / Major / Minor / Cosmetic
Evidence: recording link at the failure time, screenshot, console errors

A bad report and a good one

This example is illustrative.

The second report can be picked up by anyone on the team. The first one starts a chain of questions.

Why a recording helps

Written steps leave gaps: the thing you did without noticing, the tab you had open, the pause before the error. A screen recording closes those gaps. Narrate it: say what you expect, then show what happens. Share a link that opens at the moment it breaks, so nobody has to watch six minutes to find the ten seconds that matter. If you are new to recording, start with how to screen record in Chrome, and cut long takes down with the free video trimmer.

Write the report faster with Bug report mode

RecBeam's Bug report mode turns the recording into the written report:

1. Choose Bug report mode in the extension before you start.
2. Reproduce the problem and say what you expected and what happened.
3. RecBeam transcribes it and drafts a title, overview, numbered steps to reproduce, acceptance criteria, what actually happened, a suggested severity and the timestamp of the failure.
4. Review and edit the draft, then file it to GitHub or Linear with a link back to the recording at the failure moment.

Detection runs only on recordings made in Bug report mode, and nothing is filed until you review it. It is part of the Business + AI plan; see pricing. Teams who work this way are described on the Engineering and QA page.

Common mistakes

• Putting several bugs in one report. File each problem separately so each can be fixed and closed on its own.
• Describing the symptom without expected and actual results. "It does not work" tells a developer nothing.
• Leaving out the environment. Many bugs only appear in one browser, one version or one account type.
• Skipping the steps because they feel obvious. They are obvious to you, not to the person reading the ticket.
• Guessing the cause. Report what you saw. Mention a suspected cause separately if you have one.

Questions

Keep reading