Short answer. A bug report template is a fixed set of fields — summary, steps to reproduce, expected result, actual result, environment and severity — that lets anyone reproduce and fix a bug without asking follow-up questions. Use the generator below to fill it in and get a report you can copy or download in seconds.
Free bug report template generator
Fill in the six fields below. The report builds itself as plain text or Markdown, ready to paste into an issue tracker, a chat message or an email. Report fields stay in your browser; the separate waitlist form sends only the details described beside it.
Do not enter passwords, API keys, session tokens, personal data or confidential customer details. Remove sensitive information from logs and screenshots before sharing. Privacy and reuse.
The generator needs JavaScript. If it does not load, use the field guide below to write your report locally.
Your bug report
Review this report for sensitive data before copying, downloading or sharing it. Privacy and reuse.
ShipperAG's private pilot specialists reproduce findings in Chromium only, attach the evidence and hand your team a report ready to sign off. Safari, Firefox and real devices are not covered. Join the waitlist to become a product partner.
Work email only. We'll only email you about the ShipperAG pilot. Unsubscribe anytime. Your report text is never sent (privacy and reuse).
What each field of a bug report should contain
Six fields cover almost every bug. Leave any of them out and the person reading the report has to come back and ask, which is slower for everyone than typing one more sentence now.
| Field | What it answers | Example |
|---|---|---|
| Summary | What, where and when, in one line. | Checkout button does nothing on Safari after a discount code. |
| Steps to reproduce | The exact path anyone else can follow to see the bug. | 1. Add an item. 2. Apply a discount code. 3. Click Checkout. |
| Expected result | What should have happened, based on the requirements or common sense. | The order summary shows the discount and the checkout page loads. |
| Actual result | What happened instead, stated as a fact rather than an opinion. | Nothing happens; the network tab shows a 500 response. |
| Environment / browser | Where it happened: browser and version, OS, device, app or build version. | Safari 17.4, macOS 14.5, staging build 482. |
| Severity | How badly it affects the product, so it can be triaged. | High — a major feature is broken, no workaround. |
A filled-in bug report, as an example
This fictional writing example illustrates the six fields; it is not a ShipperAG product result. You can document any browser here, but ShipperAG checks Chromium only: Safari, Firefox and real devices are not covered.
Bug report: Checkout button does nothing on Safari after applying a discount code
Severity: High
Environment: Safari 17.4, macOS 14.5, staging build 482
Steps to reproduce
1. Add any item to the basket
2. Apply the discount code WELCOME10
3. Click Checkout
Expected result
The checkout page loads and the discount is shown in the order summary.
Actual result
Nothing happens. No error appears on screen, and the network tab shows a 500 response from /api/checkout.
Notice what is missing: no opinions, no blame, and no guessing at the cause. A developer reading this has a clear path to reproduce the problem, which is the purpose of a bug report format.
How to choose a severity level
Severity describes impact, not urgency — that is priority, and your tracker may ask for both. Judge severity by what the bug actually breaks, not by who is asking about it.
| Severity | Meaning | Example |
|---|---|---|
| Critical | Blocks release, or a critical journey has no workaround: data loss, payment failure, security exposure. | Checkout charges the wrong amount on every order. |
| High | A major feature is broken with no workaround, but the release is not blocked outright. | Discount codes never apply at checkout. |
| Medium | A feature is broken but a workaround exists, or the impact is limited to a smaller group of users. | The discount banner does not update until the page is refreshed. |
| Low | Cosmetic, or a rare edge case with minimal impact on the user. | A discount label is misaligned by a few pixels. |
Severity and priority answer different questions. As BrowserStack explains, severity is set by the technical impact on the product, while priority is set by the business, so a high-severity bug in a rarely used feature can still sit behind a low-severity bug that is blocking a launch.
How to write a good bug report, step by step
Confirm the failure, record the shortest repeatable path and separate what should happen from what happened. Use the steps below as a checklist before sharing.
- Confirm it is a bug. Check it against the requirements or the acceptance criteria, not just what feels wrong, and search for an existing report first.
- Write a specific title. Answer what, where and when in one line, for example “Checkout button does nothing on Safari after a discount code” rather than “Checkout broken”.
- List the exact steps to reproduce it. Number them, include the data you used (a real discount code, a specific account), and say what you clicked or typed.
- State the expected and actual results separately. Expected is what should happen; actual is what happened, as a fact. Keep opinions and blame out of both.
- Record the environment. Browser and version, operating system, device, and the app or build version, since many bugs only show up in one combination.
- Add a severity, and evidence if you have it. A screenshot or short recording removes any doubt about what you saw.
Bug report mistakes that waste everyone's time
Missing context and vague descriptions make reports difficult to reproduce. Check for these common gaps before assigning an issue to your team.
- A vague title such as “It's broken” or “Doesn't work”, instead of what, where and when.
- Steps that skip a detail only the reporter knows, so nobody else can reproduce it.
- Expected and actual results blurred into one paragraph, or replaced with an opinion (“this is annoying”).
- No environment at all, on a bug that turns out to affect only one browser or device.
- Several unrelated bugs crammed into one report, so half of them get lost when it is triaged.
- A severity that is really a priority in disguise, decided by who is shouting loudest rather than the actual impact.
Where a bug report fits in your release process
A bug report documents one thing that is wrong. It is not the same as the website QA checklist your team runs before every release, or the UAT sign-off template a stakeholder signs to accept the build — a bug report is what you write when one of those checks fails. The release readiness checklist then asks whether every open bug has an agreed severity and an action (fix before release, fix after, or accept), so a known issue is a decision rather than a surprise.
Reproducing and verifying a bug is exactly the kind of check agentic AI testing can take on: running the steps in a real browser, confirming the actual result, and attaching the evidence, so the report that reaches a developer is already reproduced rather than a guess. See how ShipperAG works, the 13 quality areas it checks a release against, and who the private pilot is for. Checking accessibility too? Use the WCAG 2.2 quick check.
Sources: Mozilla, Bug Writing Guidelines; Simon Tatham, How to Report Bugs Effectively; BrowserStack, Bug Severity vs Priority in Testing. Checked 27 September 2026.
Privacy and reuse
The generator processes report fields only in this browser tab. It does not send those fields to ShipperAG or save them to browser storage. Copying puts your report on your clipboard; downloading saves a file on your device. Clear the form when finished, and check your clipboard and downloaded files before sharing your device.
The separate waitlist sends your email, optional team size and signup source, including a campaign tag when present, to ShipperAG to contact you about the pilot. It does not include your bug report. The site also records page visits and interaction events, without recording report text or field values; it honours Do Not Track and Global Privacy Control. Waitlist submissions can include a measurement reference connecting the signup to those events.
You may copy, adapt and share this template for your team's bug reports. Your own report content remains yours. Reusing the template does not mean ShipperAG has tested your product or verified the report. Share reports only with people authorised to see their contents.