Use the template right away
Bug report
1. Page (URL)
The exact address where the bug appears — copied, not described.
2. Element
Which element on the page: “the submit button of the contact form”, not “the button”.
3. Environment
Device, browser + version, operating system. The field most reports skip — and the one that decides reproducibility.
4. Steps to reproduce
Numbered, from a fresh page load: 1. Open… 2. Click… 3. Type…
5. Expected result
What should have happened — one sentence.
6. Actual result
What happened instead — including the exact error message, if any.
7. Evidence
Screenshot or screen recording. Best: a pin on the live page that carries all of the above automatically.
8. Severity
blocker (core flow unusable) · major (broken, workaround exists) · minor (wrong, no damage) · cosmetic (polish)
A good report vs. a typical one
Typical: “The contact form is broken.” — Which page? Which browser? Broken how? Three questions before anyone can start.
Good: “On /contact, the submit button (iPhone 15, Safari 18, iOS 18) does nothing after tapping. Steps: open page, fill all fields, tap send. Expected: success message. Actual: nothing happens, no error shown. Screenshot attached.” — Reproducible on the first try.
Or skip the form entirely
In bepeq, the reporter pins the bug on the live page — URL, element, device, browser and OS are captured automatically. The Pilot asks a follow-up if the description is vague. The report arrives complete without anyone filling in a template.
Start bepeq for freeClient
“Not sure about the section up top.”
✦ bepeq Pilot asks back
What exactly bothers you: color, image or text?
Hero image brighter, headline higher contrast.
readyRelated templates and guides
About this template
Created by David Malewski, founder of bepeq (DAMA Solutions GmbH), based on real QA rounds in web projects. Free to use and adapt. Last updated July 13, 2026.
Common questions about bug reports
What should a bug report include?
Seven fields: the page URL, the exact element, the environment (device, browser, OS), numbered steps to reproduce, the expected result, the actual result, and evidence (screenshot, recording, or a pin on the live page). Plus a severity rating so the fixing order is obvious.
Why do bug reports need the environment info?
Because most front-end bugs are environment-specific: they exist in Safari but not Chrome, on a 375-pixel phone but not on the office monitor. A report without device, browser and OS turns fixing into guessing — and costs a full question-and-answer round trip per bug.
How do I get clients to write usable bug reports?
Don’t send them a form — give them a tool that fills the form for them. When a client pins their comment directly on the live page, the URL, element position, device, browser and OS are captured automatically. The client writes one sentence; the report still arrives complete.
What severity levels make sense for web projects?
Four are enough: blocker (page or core flow unusable), major (function broken but a workaround exists), minor (wrong behavior without real damage), cosmetic (visual polish). More levels create debates instead of clarity — the point is the fixing order.
One bug per report or a list?
One bug per report, always. Collected lists (“10 things I found”) can’t be assigned, tracked or closed individually — the fifth item gets lost in the done-ness of the other nine. Tools that pin each finding separately enforce this automatically.