Playbook · 13 min read

The questions that turn a vague bug report into a one-shot fix.

A 66-question playbook for QA leads, support engineers, and anyone who files defects. Covers reproduction steps, environment, evidence, the severity-vs-priority distinction, regression analysis, and triage. Built on ISTQB practice and the classic fields from Bugzilla, Jira, and Linear.

By The Backlog.cloud team

TL;DR

A good bug report is one that gets the bug fixed.

Cem Kaner’s rule, still the sharpest definition QA has. The report is not a diary entry. It is a work packet for the engineer who will investigate, reproduce, and patch the defect, often at 11pm on a Friday. Use the question bank below to kill the back-and-forth. The cost of asking ten questions up front is an hour saved per bug, every time.

Jump to the 66 questionsRead the FAQ

Foundations

What a good bug report looks like

Every bug tracker worth using, from Bugzilla in 1998 to Linear in 2026, asks for the same fields. The names differ. The content does not.

Searchable summary

A one-line title that names the component, the action, and the broken outcome. "Checkout crashes on Visa cards in Firefox 122" beats "checkout is broken".

Exact version and build

Not "latest". A release tag, commit SHA, or build number. This is the single biggest time-saver in triage.

Environment and device

Where it happened, on what, with what network and locale. Half the flaky bugs become reproducible once the device is named.

Numbered steps to reproduce

Short, deterministic, followable by a new joiner. Include preconditions, test data, and feature flags.

Expected vs actual

Two short statements. Link the expected behaviour to an AC, requirement, or public promise where possible.

Evidence

Screen recording, Sentry trace ID, HAR file, console logs. Anything that lets the engineer skip their own repro.

Severity and priority

Independent fields. Severity is technical impact. Priority is business urgency. Both, always.

Impact and scope

Who is hit, how many, how badly, and for how long. Triage cannot schedule a bug it cannot size.

The question bank

66 questions, in 10 categories.

Work top to bottom for anything you will escalate. Cherry-pick for the obvious, low-risk stuff. If a field is blank, say so explicitly rather than leaving it empty, because “unknown” is also data.

01

Summary and identification

A bug report that cannot be found is a bug report that never happened. The first job of the report is to be searchable, unique, and recognisable in a triage queue of fifty tickets.

  1. Q01Is there a one-line title a tired engineer could triage without opening the ticket?
  2. Q02Does the title name the component, the action, and the broken outcome?
  3. Q03Has this been filed before? Which duplicates did you check?
  4. Q04Which component, module, or service does this sit in?
  5. Q05Who reported it, and are they available for follow-up questions?
  6. Q06Is there a ticket, user report, or incident channel this originated from?
02

Version and build context

Without a version, a bug is a ghost story. Capture exactly what the user was running, because "the latest" will mean something different in three days.

  1. Q01Which version of the product was the defect found in?
  2. Q02Which exact build number, commit SHA, or release tag?
  3. Q03When was the last known working version or commit?
  4. Q04Which feature flags, experiments, or A/B variants were enabled for this user?
  5. Q05Was this the first build where the bug appeared, or has it been there longer?
  6. Q06Is the build reproducible locally, or only on a specific deployed environment?

Question B from your intake sheet lives here.

03

Environment

A bug that only reproduces in one environment is not a flaky test, it is a data point. Capture where the defect lives and where it does not.

  1. Q01In which environment did the defect occur? Production, staging, QA, local?
  2. Q02Which region, cluster, tenant, or customer account is affected?
  3. Q03Does it reproduce in other environments? If not, what is different?
  4. Q04What was the server time, and was a scheduled job or cron running?
  5. Q05Which integration endpoints were live at the time (real vs sandbox)?
  6. Q06Is there a network or firewall layer specific to this environment?

Question C from your intake sheet lives here.

04

Platform, OS, and device

Half the bugs that seem random become obvious once you know the device. Do not make the engineer guess.

  1. Q01What platform or operating system was in use when the defect occurred?
  2. Q02What OS version, exactly? Not "latest Mac", but "macOS 14.4.1 (23E224)".
  3. Q03What device or machine was used when the defect was encountered?
  4. Q04What browser and browser version? Incognito or normal? Which extensions were active?
  5. Q05What screen size, resolution, and device pixel ratio?
  6. Q06What is the network condition? Wi-Fi, 4G, VPN, corporate proxy?
  7. Q07What is the locale, timezone, and language setting?

Questions D and E from your intake sheet live here.

05

Expected vs actual behaviour

This is where most bug reports fall apart. "It is broken" is not a bug report. Name what happened, what should have happened, and cite the rule that was violated.

  1. Q01What was the actual behaviour observed during the defect?
  2. Q02What is the expected behaviour of the product?
  3. Q03Which acceptance criterion, requirement, or user-visible promise does that come from?
  4. Q04Is the expected behaviour documented, or is it an assumption worth double-checking?
  5. Q05What exact error message, status code, or dialog appeared?
  6. Q06Did the UI show a specific state (loading, empty, error) that shouldn't be possible?

Questions F and G from your intake sheet live here.

06

Steps to reproduce

A minimal, deterministic reproduction is the most valuable field in a bug report. If the engineer can reproduce it in one sitting, they can fix it in one sitting.

  1. Q01What are the steps to reproduce the defect, written so a new joiner could follow them?
  2. Q02What preconditions are needed? Logged-in user, specific role, seeded data?
  3. Q03What test account, tenant, or record IDs should be used?
  4. Q04How often does it reproduce? Always, sometimes, once, or not reproducible?
  5. Q05Is there a timing component, such as double-clicks or slow networks?
  6. Q06What is the shortest sequence that still triggers the bug?
  7. Q07Can you attach a video or screen recording of the reproduction?

Question H from your intake sheet lives here.

07

Evidence and instrumentation

Attach the artifacts engineers reach for anyway. The more you attach, the less back-and-forth the triage needs.

  1. Q01What screenshot, video, or GIF captures the broken state?
  2. Q02Is there a Sentry, Datadog, or log trace ID that can be linked?
  3. Q03What client-side console errors or network requests were logged?
  4. Q04Is there a HAR file, network trace, or request payload to attach?
  5. Q05What database or API state existed before and after the action?
  6. Q06Is there a PostHog session replay, a Fullstory recording, or equivalent?
  7. Q07Does the browser devtools performance or memory profile show anything odd?
08

Impact and scope

Engineering schedules bugs based on blast radius. Tell triage how many users are affected and how badly, or the bug goes to the bottom of the queue.

  1. Q01How is this defect impacting other tasks or functionality?
  2. Q02Which user segments are hit? Free, paid, enterprise, a single tenant?
  3. Q03What percentage of users or traffic is affected, even roughly?
  4. Q04Is there a workaround? Is it discoverable, or do users need to be told?
  5. Q05Does it block a release, another ticket, or a customer commitment?
  6. Q06Is anyone losing money, data, or trust right now?
  7. Q07Is this hitting a VIP account, a launch partner, or a public demo?

Question I from your intake sheet lives here.

09

Severity and priority

Severity is how broken the thing is. Priority is how fast we fix it. They are not the same field, and conflating them is how a data-loss bug ends up behind a typo.

  1. Q01What is the severity? Blocker, critical, major, minor, or trivial (per ISTQB)?
  2. Q02What is the priority? P0 now, P1 this sprint, P2 this quarter, P3 backlog?
  3. Q03Does this involve data loss, data corruption, or a security exposure?
  4. Q04Is there a compliance, accessibility, or legal implication?
  5. Q05Does an SLA apply? Which customer, which clock?
  6. Q06If we ship without fixing, what is the worst plausible headline?
10

Regression, root cause, and triage

Triage is not just routing. A good report gives engineering a head start on the investigation.

  1. Q01Is this a regression? When did it last work?
  2. Q02Can git bisect, a deploy log, or a release note identify when it was introduced?
  3. Q03Which team or on-call rotation owns the affected component?
  4. Q04What is the suspected root cause, stated as a hypothesis, not a fact?
  5. Q05Are there related tickets, incidents, or customer escalations to link?
  6. Q06Does this need a hotfix branch, or can it wait for the normal release train?
  7. Q07Is there a test gap the fix should close, and where should that test live?
  8. Q08Is a post-incident review warranted, and who convenes it?

Distinction

Severity vs priority

These two fields argue with each other, and the argument is a feature, not a bug. Keep them separate. The ISTQB Foundation syllabus defines severity as the degree of impact that a defect has on the system. Priority is set by the business on how urgently it should be fixed.

Severity

Technical impact

  • Blocker. System unusable, data loss, security exposure.
  • Critical. Major feature broken, no workaround.
  • Major. Feature broken, workaround exists.
  • Minor. Cosmetic, small logic issue.
  • Trivial. Typo, pixel nudge.

Priority

Business urgency

  • P0. Fix now. Hotfix, pager, everyone drops their work.
  • P1. Fix this sprint. Known to users, hurting metrics.
  • P2. Fix this quarter. Backlogged with a date.
  • P3. Fix when we next touch this area.

A pricing-page typo during launch week is severity trivial, priority P0. That is the whole point of keeping them separate.

Copy and paste

A clean bug report template

Drop this into your Jira ticket description, your Linear issue body, or a markdown file attached to the report. Columns A through I mirror the intake sheet most QA teams already run. Columns J through O are the fields that typically get added after the first production incident.

FieldWhat to capture
A. Timestamp and reporterWhen it was filed, by whom, and how to reach them.
B. Product version or buildRelease tag, commit SHA, or build number.
C. EnvironmentProduction, staging, QA, local. Region and tenant.
D. Platform / OSmacOS 14.4.1, Windows 11, iOS 17.4, Android 14.
E. Device / browserHardware, browser, extensions, screen size, network.
F. Actual behaviourWhat happened, with the exact error message or state.
G. Expected behaviourWhat should have happened, with a pointer to the AC.
H. Steps to reproduceNumbered steps, preconditions, test data, feature flags.
I. Impact on other workWho is blocked, what else breaks, is there a workaround?
J. EvidenceScreenshot, video, HAR file, trace ID, console errors.
K. ReproducibilityAlways, sometimes, once, not reproducible.
L. SeverityBlocker, critical, major, minor, trivial.
M. PriorityP0, P1, P2, P3.
N. Regression infoIs it a regression? When did it last work?
O. Owner and linksSuspected owner team, related tickets, incident links.

When you have five minutes

The 10-question minimum set

If you only have time for ten questions, ask these. Skipping any of them buys a week of back-and-forth later.

  1. 01Searchable title: what component, what action, what went wrong?
  2. 02What version or build was the user on?
  3. 03Which environment, and does it reproduce elsewhere?
  4. 04What OS, browser, device, and network?
  5. 05What happened? Include the exact error or state.
  6. 06What should have happened, per spec or AC?
  7. 07Numbered steps to reproduce, with preconditions.
  8. 08How often does it reproduce? Always, sometimes, once?
  9. 09Who is affected, how many, and is there a workaround?
  10. 10Severity, priority, and is this a regression from a working version?

FAQ

Frequently asked questions

What is the difference between severity and priority?

Severity describes the technical impact of the defect, independent of schedule. A crash is higher severity than a misaligned button. Priority describes the business urgency of fixing it. A tiny typo on the pricing page during a launch can be high priority and low severity. ISTQB defines five severity levels (blocker, critical, major, minor, trivial) and most teams use a four-step priority scale (P0 to P3). Treat them as independent fields, because they often disagree.

What is a minimal reproducible example?

The shortest sequence of steps, on the smallest data set, that still triggers the bug. If removing a step makes the bug disappear, the step was load-bearing. A minimal repro is the single most valuable field in a bug report because it turns the defect from a mystery into a diagnosis.

What makes a good bug report, according to QA experts?

Cem Kaner's classic rule: a good bug report is one that gets the bug fixed. That means it is reproducible, specific, unambiguous, and written with the engineer's workflow in mind. A clear title, exact version and environment, numbered steps, expected and actual behaviour, attached evidence, and an honest severity rating. Anything less is a help request, not a report.

What should I attach to a bug report?

A short screen recording or annotated screenshot of the broken state, the exact error message, the relevant console or network logs, a Sentry or Datadog trace ID if one exists, and the user or tenant ID involved. For frontend bugs, a HAR file is worth ten paragraphs of description.

What is a regression bug?

A defect that appears in a feature that previously worked. Regressions are higher signal than new bugs because they imply a recent change broke something. Capture the last known working version or commit, so engineering can bisect the history. If automated regression tests exist, flag whether they missed this and why.

How detailed should steps to reproduce be?

Detailed enough that a new joiner with no context can reproduce the bug without asking a question. That usually means numbered steps, the exact test account, any required data or feature flags, and the precise input. If the bug depends on timing or concurrency, say so explicitly.

Do the fields differ between Jira, Bugzilla, and Linear?

The tool changes, the fields do not. Every major tracker expects the same core information: summary, version, environment, steps, expected, actual, severity, priority, attachments, and owner. Use whichever template your tool provides, but do not let a missing field let you skip the question. Fill in a custom field or add it to the description.

When is a bug not a bug?

When it is a misunderstood requirement, a training gap, an environment issue on the reporter's machine, or a deliberate design choice that was never documented. Every one of these deserves a ticket, but as a requirement clarification, an update to the help centre, or a decision log entry, not as a defect. Misclassifying them pollutes defect metrics.

Related reading

Playbook

The questions that turn messy ideas into production-ready user stories

78 questions for product managers, business analysts, and delivery leads. Built on INVEST, the 3Cs, and Example Mapping.

Read the playbook

Playbook

The questions that turn loose meeting notes into a Jira-ready task

Objective, scope, assumptions, dependencies, acceptance, and owner. The questions to ask in refinement before anything ships.

Read the playbook

Or skip the questions

Let Backlog.cloud write the bug report for you.

Backlog.cloud joins your triage call, listens to the discussion, and pushes a Jira-ready defect with steps, expected, actual, severity, and impact captured. Every question in this playbook, every time.

Start for freeSee pricing