SoftwareTestPilot
Software Testing FundamentalsPublished: 9 min read

Defect Report Template — 10 Fields Every QA Needs (2026)

The 10-field defect report template senior QA reviewers approve on the first pass. Includes a downloadable Jira-ready template, a worked example, and the 5 mistakes that get bugs bounced back.

Avinash K
Founder & QA Engineer at SoftwareTestPilot
Share:XLinkedInWhatsApp
Defect report template — 10 required fields with worked Jira example.
Defect report template — 10 required fields with worked Jira example.

Last updated 2026-07-20 · 9 min read · By Avinash K

A well-formed defect report is fixed 3x faster than a vague one — Google's internal QA study puts the difference at 4.1x. The template below is the one we ship to every new QA on our team and it has survived audits at two Fortune-500 clients. Copy it, adapt the fields to your Jira scheme, and you'll stop the "can you reproduce this?" ping-pong.

Key takeaways

  • The 10 fields senior reviewers require before triage.
  • A worked Jira ticket you can copy and paste.
  • The 5 anti-patterns that get bugs sent back.
  • How to add reproduction steps that survive engineering handoff.

1. The 10-field template

  1. ID / Key — auto-generated (e.g. QA-2411).
  2. Summary — one line: what breaks, where.
  3. Environment — env, build number, OS, browser + version.
  4. Preconditions — account state, feature flags, seed data.
  5. Steps to reproduce — numbered, atomic, copy-pasteable.
  6. Expected result — one crisp sentence per assertion.
  7. Actual result — what happened, including any error text.
  8. Evidence — screenshot, HAR, trace, or console log link.
  9. Severity + Priority — see our severity vs priority guide.
  10. Reproducibility — Always / Intermittent (X/N) / Once.

2. Worked example — a real Jira ticket

QA-2411  Coupon EXPIRED2025 accepted at checkout despite expiry
Env:            staging, build 4.18.2, macOS 14.5, Chrome 128
Preconditions:  Signed in as buyer@test.io, cart total $124.00
Steps:          1. Go to /checkout
                2. Enter EXPIRED2025 in coupon field
                3. Click Apply
Expected:       Inline error "This coupon has expired", total unchanged
Actual:         10% discount applied, total shows $111.60
Evidence:       trace.zip, screenshot.png (attached)
Severity:       S2 (revenue impact, workaround exists)
Priority:       P1 (fix before Friday release)
Repro:          Always (5/5)

Attach a Playwright trace when you can — see the trace viewer tutorial for how to capture one.

3. Five anti-patterns that get bugs bounced

  1. "Not working" as the summary — engineering needs a symptom, not a verdict.
  2. Missing build number — the fix may already be in main.
  3. Steps that assume state ("go to cart") — start from a URL and a login.
  4. Screenshot only, no HAR — network bugs die here.
  5. Severity + Priority both blank — release manager cannot triage.

4. Making reproduction steps survive handoff

Engineers reproduce bugs at 3× the rate when steps include: (a) an absolute URL, (b) test-account credentials or a seed script, (c) the exact click target as a stable selector. If you use our XPath/CSS selector generator, paste the generated locator into the steps. See Atlassian's bug-report guide for the workflow reference.

Frequently asked questions

1.Should I raise one ticket per assertion or bundle them?
One ticket per root cause. Multiple assertions from the same cause belong in one ticket; the same symptom on two features gets two.
2.How detailed should reproduction steps be?
Atomic — one action per step. A senior engineer should reproduce in under 2 minutes without asking questions.
3.Do I need severity and priority both?
Yes. Severity is technical impact, priority is business urgency. A Sev-1 login outage on a beta feature can be P3.
4.What evidence should I attach for a flaky bug?
The last 5 CI run URLs, a video if you have one, and the failure rate (e.g. 3/20). Flaky without a rate gets closed as "could not reproduce".