Bug report template generator

Turn rough notes into a clear bug report. Fill in the title, steps to reproduce, expected and actual result, environment and severity, then copy it as plain Markdown, a GitHub issue, a Jira ticket or a Linear issue.

What makes a bug report useful

A developer should be able to read a bug report once and reproduce the problem without asking a single question. That takes six things:

  • A specific title. Say what broke and where: "Checkout: Pay button stays disabled after entering a valid card" beats "Payment broken".
  • Numbered steps to reproduce. Start from a known state (logged out, empty cart, a fresh account) and write one action per step.
  • Expected result. What should have happened. This shows whether it is a bug or a misunderstanding of how the feature works.
  • Actual result. What happened instead, including exact error messages. Copy them; don't paraphrase.
  • Environment. Browser and version, operating system, device, screen size, app version or build number, and the account or test data used.
  • Evidence. A screenshot with the problem circled, a short screen recording, and console errors or logs if you can get them.

How to write good steps to reproduce

  1. Reproduce the bug yourself at least twice before reporting it, and note if it only happens sometimes.
  2. Remove steps that don't matter. If the bug happens without step 3, delete step 3.
  3. Include the data you used: the exact email format, the file you uploaded, the coupon code.
  4. Write what you clicked using the visible labels ("Click Save changes"), not positions ("the button on the right").
  5. If it only happens on one device or browser, say so, and say where it works fine.

Choosing a severity

Severity describes how bad the bug is for users. Priority describes how soon the team will fix it. They often match, but not always: a typo on the homepage has low severity and can still get high priority.

  • Critical: data loss, a security problem, money charged incorrectly, or a core flow (signup, login, checkout) blocked for most users with no workaround.
  • High: a major feature is broken or a core flow fails for some users, and the workaround is hard or unknown.
  • Medium: a feature misbehaves but users can work around it, or the bug affects a less important flow.
  • Low: cosmetic issues, typos, minor layout glitches and small inconsistencies.

Not sure? The bug severity calculator asks six quick questions and suggests both a severity and a priority.

GitHub, Jira and Linear formats

All three tools accept Markdown-like text, but each has its own habits:

  • GitHub issues read well with short headings and a checklist for acceptance. Add labels like bug and a severity label after pasting.
  • Jira uses its own wiki markup in many setups (h3. for headings, # for numbered lists, {code} blocks). The Jira tab produces that format. In newer Jira editors that accept Markdown, the Markdown tab works too.
  • Linear uses Markdown and has a built-in priority field. The Linear tab suggests the matching priority (Urgent, High, Medium, Low) so you can set it when you paste.

Bug reports from beta testers

Beta testers rarely write perfect bug reports. Give them a short template (this generator's Markdown output works well in a form or a shared doc), ask for a screenshot, and accept rough reports gracefully: rewrite them yourself before passing them to developers.

An AI beta tester skips that cleanup step. It files every bug it finds with numbered steps, expected and actual results, the environment, a severity, annotated screenshots and a recording of the moment it broke, and can send the bugs straight into your tracker.

Let an AI beta tester do it for you

An AI beta tester opens your website, web app, Android or iOS app or browser extension in a real browser or on a phone, signs up, clicks through every flow like a real user, and files bugs with steps, severity, annotated screenshots and recordings, then sends a report with a quality score.

Bug report generator: FAQ

What should a bug report include?

A specific title, numbered steps to reproduce, the expected result, the actual result, the environment (browser, OS, device, app version), a severity, and evidence such as screenshots, recordings or console errors.

What is the difference between severity and priority?

Severity is how much the bug hurts users or the business. Priority is how soon the team should fix it. Severity is set by whoever reports the bug; priority is usually decided by the product owner.

Does the Jira output work in every Jira version?

The Jira tab uses Jira wiki markup, which works in Jira Server, Data Center and the classic editor. Jira Cloud’s newer editor converts Markdown as you paste, so the Markdown tab works there too.

Can I detect my browser and OS automatically?

Yes. Click “Detect my environment” and the generator fills in your browser, operating system and screen size from your current device. Edit it if the bug happened on a different device.

Is anything I type saved or uploaded?

No. The bug report is generated in your browser and nothing is sent to a server. Copy it before you close the page.

How long should a bug report be?

As short as possible while still being reproducible. Usually three to eight steps and one or two sentences each for expected and actual result. Put long logs in an attachment.

More free beta testing tools

Related beta testing guides