Bug report template
Updated 2026-11-12 · 3 min read
A bug report succeeds when a developer who has never seen the feature can reproduce it in two minutes. This template has the fields that make that possible, with a good example next to a bad one.
Copy-paste version for Jira or any tracker
Title: [Area] short description of what is wrong
Environment: Build/version, URL, browser + version, OS, device, account used
Preconditions: State needed before step 1
Steps to reproduce:
1.
2.
3.
Expected result:
Actual result:
Reproducibility: Always / Sometimes (x of y) / Once
Severity: Critical / Major / Minor / Trivial
Priority: High / Medium / Low (suggested)
Evidence: Screenshot, video, console log, network request/response
Notes: Workaround, first seen in build, related tickets
The Excel file has the same fields in columns, with drop-downs for severity, priority and status.
A bad report and a good one
Bad
Title: Login not working Description: I tried to log in and it did not work. Please fix.
The developer must now ask: which login, what error, which browser, which account. The ticket sits for two days.
Good
Title: [Login] "Sign in" button does nothing when the password contains a space Environment: Build 2.14.1 (staging), Chrome 130 on Windows 11, account
[email protected]Steps: 1. Open /login. 2. Enter the email. 3. Enter the passwordTest pass 1(contains a space). 4. Click "Sign in". Expected: The user is signed in, as the account has this password set. Actual: Nothing happens, no message, no network request. Console showsTypeError: Cannot read properties of undefined (reading 'trim'). Reproducibility: Always (5 of 5). Works withTestPass1. Severity: Major (users with spaces in passwords cannot sign in). Priority: High (suggested). Evidence: screen recording and console screenshot attached.
Field guide
- Title. Start with the area in brackets, then say what is wrong. Searchable titles avoid duplicates.
- Environment. Most "cannot reproduce" replies come from a missing build number or browser.
- Steps. Numbered, one action each, with the exact data. Remove steps that are not needed to trigger it.
- Expected vs actual. Say what you expected and why (requirement, similar feature, common sense).
- Reproducibility. Honest numbers. For intermittent bugs write how many times out of how many.
- Severity and priority. Propose them and say why; the owner can change priority. See severity vs priority.
- Evidence. A 10-second screen recording often saves a conversation. Include the browser console and the failing network request, with tokens and personal data blurred out.
Habits that get bugs fixed
- One bug per report. If two things are wrong, file two.
- Search for duplicates before filing.
- Reduce it: find the shortest steps that still fail.
- Stick to facts and keep the tone neutral. "The page crashes" beats "the developer broke the page".
- Check the fix, update the ticket and close it.
Downloads
Quick answers
What should a good bug report contain?
A specific title, the environment (build, browser, operating system, device), numbered steps to reproduce, the expected result, the actual result, severity and priority, and evidence such as a screenshot, a video or logs.
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.
