Bug report template for beta testers

A good bug report lets a developer reproduce the problem on the first try. This template has every field that matters and nothing extra. Give it to your beta testers, or ask your AI beta tester to file every bug in exactly this format.

Who it’s for

  • Beta testers who want their reports to get fixed
  • Developers tired of "it doesn't work" tickets
  • Product teams setting up a beta feedback process
  • Teams combining human beta testers with an AI beta tester

Updated 2026-10-19.

What makes a bug report useful

A developer reading a bug report needs to answer three questions fast: can I reproduce it, how bad is it, and where do I look. Every field in this bug report template serves one of those. Reports from beta testers that skip steps or the environment are the ones that end up marked "cannot reproduce".

The full template

TITLE: [Where] + [what goes wrong] + [when]
       e.g. "Checkout: Pay button stays disabled after editing the address"

SEVERITY: [Critical / Major / Minor / Cosmetic]
FREQUENCY: [Always / Sometimes (x of y tries) / Once]

ENVIRONMENT
  URL or screen: [link or screen name]
  Build / version: [e.g. 1.4.2 or commit / date]
  Device and OS: [e.g. Pixel 8, Android 15 / MacBook, macOS 15]
  Browser: [e.g. Chrome 130]
  Account / role: [e.g. free plan test user, admin]

STEPS TO REPRODUCE
  1. [First step from a clear starting point]
  2. [Next step]
  3. [Step where it breaks]

EXPECTED RESULT
  [What should happen]

ACTUAL RESULT
  [What happens instead, with the exact error text]

EVIDENCE
  Screenshot (annotated): [link]
  Recording: [link]
  Console errors / failed requests: [paste]

NOTES
  [Workaround, first seen, related bugs, anything you tried]

Short version for quick beta feedback forms

WHERE: [page or screen]
WHAT HAPPENED: [actual result, exact error text]
WHAT I EXPECTED: [expected result]
STEPS: 1. [ ] 2. [ ] 3. [ ]
DEVICE / BROWSER: [e.g. iPhone 15, Safari]
HOW OFTEN: [always / sometimes / once]
SCREENSHOT: [attach]

Mobile app variant

TITLE: [Screen] + [symptom]
APP VERSION / BUILD: [e.g. 2.3.0 (412), TestFlight or Play internal track]
DEVICE: [model]   OS: [iOS / Android version]
ORIENTATION: [portrait / landscape]   APP STATE: [fresh install / update]
STEPS / EXPECTED / ACTUAL: [as in the full template]
CRASH? [yes / no, time of crash for the crash log]
EVIDENCE: [screen recording, screenshot]

How to write a bug report, step by step

  1. Reproduce the bug once more from a clean start and note how often it happens.
  2. Write the title: location first, then the symptom. Avoid "Bug on page" or "Broken".
  3. Fill in the environment: build, device, OS, browser and account role. This is the field most often missing.
  4. List the steps, one action per step, starting from a state anyone can reach.
  5. Write expected and actual results separately, copying any error message word for word.
  6. Attach evidence: an annotated screenshot, and a recording for timing problems.
  7. Set severity by user impact, not by how hard it is to fix.

Example (fictional): a habit-tracking web app

TITLE: Habits list: checking in twice in one day counts as a 2-day streak
SEVERITY: Major          FREQUENCY: Always (5 of 5)
ENVIRONMENT: /habits, build 0.9.3, iPhone 15 Safari, free plan test user
STEPS:
  1. Log in and create a habit "Read 10 pages".
  2. Tap the check-in circle. Streak shows "1 day".
  3. Reload the page and tap the check-in circle again.
EXPECTED: The second tap is ignored or undoes the check-in; streak stays 1.
ACTUAL: Streak shows "2 days". No error shown.
EVIDENCE: annotated screenshot of the streak counter, 20 s recording.
NOTES: Does not happen without the reload.

Checklist before you submit

  • One bug per report, not three.
  • The title makes sense without opening the report.
  • Steps start from a clear state and someone else could follow them.
  • Build or version is included.
  • The error text is copied, not paraphrased.
  • Suggestions and opinions go to the feedback channel, not the bug tracker.

What to fix first

Critical bugs (a core flow is blocked, data is lost or payments fail) come first, then Major bugs that hit many users, then Major bugs in rarer flows. Frequency matters: an "always" bug in signup outranks a "once" glitch in settings. Cosmetic issues wait unless they make the product look broken.

Common mistakes

  • Several bugs in one report: each one can't be fixed and closed on its own.
  • Missing the starting state: steps that begin halfway through a flow can't be followed.
  • No version: a bug in last week's build may already be fixed.
  • Paraphrased errors: the exact text is searchable in the code; your summary is not.

Manual reports vs an AI beta tester

Human beta testers often forget the environment or the exact steps. An AI beta tester (betatest.ing) fills every field without reminders: URL, viewport, browser, the steps it took, console errors, failed requests, an annotated screenshot and a screen recording, in your own template if you paste it into the task. It does that on every build or on a schedule. What it doesn't replace: real users telling you something feels wrong, and bugs that depend on real-world conditions such as poor networks, push notifications, GPS or real payments.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Beta test [APP URL] and file every bug you find in exactly this format: TITLE (where + what goes wrong + when), SEVERITY (Critical / Major / Minor / Cosmetic), FREQUENCY (how many of your tries), ENVIRONMENT (URL or screen, device, browser, viewport, account type), STEPS TO REPRODUCE (numbered, from a clear starting point, one action per step), EXPECTED RESULT, ACTUAL RESULT (with the exact error text), EVIDENCE (an annotated screenshot of the broken state, a recording for anything involving timing or several steps, console errors and failed requests from the logs), NOTES (workaround, related bugs). Focus on: [FLOWS TO TEST]. One bug per report; put opinions and ideas in a separate "suggestions" list at the end. Try to reproduce each bug a second time before filing it. Do not make real payments or delete real data. End with a summary table of all bugs sorted by severity.

Fill in your details

Here, or later in the chat with your tester.

  • [APP URL] The link to the site or app you want tested.
  • [FLOWS TO TEST] e.g. "signup, creating a project, and the settings page".

What the AI beta tester checks

  • The flows you name, step by step, like a real user
  • Each bug reproduced a second time before it is filed
  • Console errors and failed network requests on every page
  • The environment: URL, browser, viewport and account type
  • Severity rated by impact on users
  • Suggestions kept separate from bugs

What you get

  • One bug report per issue in your template format
  • Annotated screenshots of each broken state
  • Screen recordings for multi-step or timing bugs
  • A summary table of all bugs sorted by severity
  • A separate list of UX suggestions

How to run it with betatest.ing

  1. Add your app as a project with a short description and a test login.
  2. Paste the task above and name the flows you care about.
  3. Read the summary table first, then open the critical and major reports.
  4. Copy each report into your issue tracker, or ask the tester to re-test them after a fix.

Tips

  • Add your own fields (component, sprint, customer impact) to the template before sending it.
  • Agree on what each severity level means and include the definitions in the task.
  • Ask for a re-test of open bugs after every deploy to close them with evidence.
  • Keep the same template for human beta testers so all reports look alike.

Bug report template: FAQ

What should a bug report include?

A clear title, severity, frequency, the environment (URL, build, device, browser, account), numbered steps to reproduce, the expected result, the actual result with the exact error text, and evidence such as an annotated screenshot or a recording.

How do I write steps to reproduce?

Start from a state anyone can reach, such as a URL or "logged in as a new user". Write one action per step, in order, and stop at the step where it breaks. Include steps you think are irrelevant if you are not sure.

What is the difference between severity and priority?

Severity is how badly the bug affects users. Priority is how soon the team will fix it. A typo on the homepage can be low severity but high priority; a crash in a rarely used admin screen can be the opposite.

Should beta testers report suggestions as bugs?

No. Keep bugs (something does not work as intended) separate from suggestions (something works but could be better). Mixing them makes the bug list harder to triage.

Can an AI beta tester follow my bug report template?

Yes. Paste the template into the task and the AI beta tester files each bug in that format, with the environment, steps, console errors, an annotated screenshot and a recording attached.

What is a good bug report title?

Start with where the problem is, then what goes wrong and when, for example "Checkout: Pay button stays disabled after editing the address". Someone scanning a list of bugs should understand each one without opening it. Avoid titles like "Broken" or "Bug on page".

What do I do if I can't reproduce a bug?

Report it anyway and set the frequency to "Once", with everything you remember: the time, the page, the device and what you did just before. Attach any screenshot or recording you have. If it happens again, add the new occurrence to the same report instead of filing a new one.

Should a bug report include a screen recording?

A recording helps whenever timing or a sequence matters, such as flickering, slow loads, double submits or animations that go wrong. For a static problem, an annotated screenshot is usually enough. Keep recordings short and start them just before the bug happens.

Related beta testing guides

  • How to write a bug report — A good bug report lets a developer reproduce the problem in minutes without asking a single question. Here is what to include, how to write each part, and an example you can copy.
  • Bug severity levels — A shared severity scale lets beta testers, developers and product managers agree on how bad a bug is in seconds. Here is a simple four-level scale with examples, plus how severity differs from priority.
  • Test case template — A test case is a short, repeatable check: start here, do this, expect that. A set of good test cases lets anyone, human or AI, run the same beta test on every build and get comparable results. Copy the template, see a filled-in example, and run your test cases with an AI beta tester.
  • Broken links checker — Broken links and JavaScript errors are cheap to fix and expensive to leave: they break flows, hurt trust and waste crawl budget. This page shows what to collect, how to group it, and a task your AI beta tester can run across your site.
  • Regression testing after deploys — Regression testing checks that what worked yesterday still works after today’s change. For small teams shipping often, a short regression suite run after every deploy prevents most "it used to work" bugs from reaching users.
  • Free tool: Bug report generator — Clean bug reports with steps, expected vs actual and environment, formatted for GitHub, Jira or Linear.

More in templates