Bug Report Template

Download bug report template (CSV)

A bug report is a request for a specific fix. It must tell an engineer what you did, what you expected, what happened instead, and how to see it again.

If any of those are missing, the ticket becomes a conversation. Conversations are slower than fixes.

Download the CSV, or copy the fields into Jira, Linear, Azure DevOps, or GitHub Issues.

What makes a bug report actionable

An engineer who was not on the call should be able to:

1. Land in the same starting state
2. Follow your steps
3. See the same actual result
4. Compare it to a stated expected result
5. Know how bad it is (severity) and how soon it should move (priority)

Screenshots help. They do not replace steps. “See video” with no timestamp and no environment is how bugs bounce.

This is the same bar we use on manual and functional testing work. The tracker can be yours; the content of the ticket should still look like this.

Severity vs priority

These are not synonyms. Mixing them is why “P1” stops meaning anything. The longer guide is severity vs priority.

Severity is impact on the user or the system if the bug is real.

Severity	Meaning
Blocker	Cannot continue the journey or the build is unusable
Critical	Major function broken; no practical workaround
Major	Function broken or data wrong; workaround exists
Minor	Limited impact; cosmetic or narrow edge
Trivial	Polish only

Priority is when you want it fixed relative to the release.

A typo on the checkout button can be Minor severity and P1 priority the day before launch. A crash in an admin export nobody uses this quarter can be Critical severity and P3 priority.

Write both fields. If your tracker has only one, put impact in the title or labels and say so in the test strategy.

Fields

Field	What to put there
Bug ID	Tracker key, or BUG-001 if you are still in a sheet
Title	Fault + where. “Sign-in accepts an empty password on Safari 17”
Severity / Priority	Impact vs urgency
Environment	Browser/OS/device/app build, or API base URL
Build / version	A hash, build number, or release name
Preconditions	Account state, feature flags, data
Steps to reproduce	Numbered, one action each
Expected result	What the spec or case said
Actual result	What you observed, not a theory about the cause
Evidence	Screenshot, recording, HAR, log snippet — with a filename or link
Status	Open, In progress, Fixed, Verified, Won’t fix
Related test case	TC-103 if it failed a written case
Notes	Intermittent rate, related tickets, “only with empty cache”

Do not put the root cause in Actual result unless you measured it. “Probably a race condition” belongs in Notes, if at all.

Blank bug report

Title: Severity / Priority: Environment / Build: Preconditions: Steps: 1. 2. 3. Expected: Actual: Evidence: Related test case:

The CSV download is this structure as columns, with one filled example row.

Good vs bad

Bad title: Login issue Better title: Sign-in accepts an empty password on Safari 17

Bad steps: Try to login and it doesn’t work Better steps:

1. Open /sign-in on Safari 17
2. Enter a valid email
3. Leave password empty
4. Press Enter

Bad expected: Should work properly Better expected: Validation blocks submit; no session is created

Bad actual: It’s broken Better actual: Request is sent; user lands on an empty authenticated shell

Bad evidence: “I can show you on a call” Better evidence: Screenshot of the empty shell plus a HAR of the sign-in request

The difference is not politeness. It is whether someone can start fixing after reading once.

Lifecycle (so “fixed” means something)

Status	Meaning
Open	Reproduced, fields complete, waiting for engineering
In progress	Someone is changing code or config
Fixed	A build is claimed to contain the fix — not yet retested
Verified	Original steps passed on the stated build
Won’t fix	Accepted risk, with a name and a reason
Duplicate	Points at the surviving ticket

Testers should not mark Fixed. Developers should not mark Verified. If one person does both jobs, still use two steps so the build number is recorded.

When you find the same fault a second way, add steps to the existing ticket or open a linked ticket. Duplicates without a link waste triage. Duplicates silently closed without a link lose a reproduction path.

Environment: write what you would need to rent the same machine

“Chrome” is not an environment. “Chrome 127 / Windows 11 / staging / build 2026.08.12 / feature flag new-auth on” is. For mobile, include OS version and whether you used a real device or a simulator. For API bugs, include method, path, and status code.

If the bug is layout, say viewport width. If it is data, say which fixture or account. The common bug categories (functional, boundary, UI, data, integration, regression, performance) are useful as labels. They are not a substitute for steps.

Intermittent bugs

If it does not fail every time, say so in the first line of Notes: “Failed 2 of 5 attempts, always after a cold start.” Include the attempts. An intermittent bug with no rate looks like a one-off and gets closed.

Capture environment more tightly: feature flags, time of day, first load vs repeat, which account. Intermittent plus vague environment is how defects linger across releases — the pattern in common software bugs.

Evidence without dumping secrets

Prefer a redacted screenshot and a short log over a full production dump. Do not paste access tokens, real customer emails, or health data into a tracker that is wider than the people who need it. Describe the data (“a patient with two open invoices”) instead of pasting the record.

After it is “fixed”

A bug is not done when a developer says it is fixed. Re-run the original steps on the stated build. If you have a case ID, run that case. Then mark Verified — or reopen with the new build number.

Closing without verification is how regressions return. That is what a regression pass is for.

Related templates

• Test case template — many bugs start as a failed case
• Requirements traceability matrix — which requirement the failure belongs to
• Test plan template — how defects are handled in this release

FAQs

What is a bug report template?

A standard set of fields so every defect includes environment, steps, expected vs actual, severity, and evidence.

Should testers suggest the fix?

Only if you have evidence. “The empty-password check is missing on the Safari path” is a clue. “Rewrite the auth service” is not a bug report.

What if I cannot reproduce it a second time?

Log it anyway: steps you took, rate, environment, and that it is unreproduced. Do not invent a cleaner story to make it sound solid.

Do you log bugs in our tracker or yours?

Yours. The template is the content standard, not a separate system. See QA consulting if you want that standard applied inside your workflow.

Can this be used for AI product failures?

Yes. Expected vs actual still applies: the answer, the tool call, or the citation. Include the prompt, model or prompt version, and whether retrieval ran. See AI testing services.