On this page9 sections
ReferenceBeginner6-8 min reference

Bug Report Format

The difference between a bug that gets fixed this sprint and one that languishes in the backlog is often the report itself. A great bug report has zero ambiguity, gives the developer a one-shot reproduction, and shows the impact in business terms. This sheet covers every field, the writing patterns that work, and templates for the three most common types: UI, API, and performance.

Required fields

Eight fields cover 95% of what a developer needs:

FieldPurposeExample
SummaryOne-line title scannable in a listCheckout — 500 error when promo code contains a hyphen
SeverityHow broken is the system (QA decides)Major
PriorityHow urgent is the fix (Product decides)P1
EnvironmentWhere it reproducesStaging, build 1.42.0, Chrome 132, macOS 14.7
PreconditionsState required before steps runLogged in as qa.user@example.com; cart has 1 item
Steps to ReproduceNumbered, deterministic actionsSee template below
Expected ResultWhat should happenOrder is created; receipt page loads
Actual ResultWhat does happenToast "Something went wrong"; POST /orders → 500
EvidenceScreenshot, screen recording, HAR, log linkAttached

If any of those is missing, expect a "Need More Info" boomerang.

Severity vs priority

Severity answers how broken is it? — owned by QA, based on technical impact. Priority answers how soon do we fix it? — owned by Product, based on business impact.

These are independent. A typo on the homepage during a launch can be Trivial / P0.

SeverityDefinitionReal-world example
CriticalSystem unusable; data loss; security exposureUsers can't log in. Payments are double-charging. PII is exposed in logs.
MajorCore feature broken with no workaroundCheckout fails for all promo codes. Sign-up emails not sent.
MinorFeature broken with a viable workaroundSearch filter resets on pagination. Dashboard chart shows wrong colour.
TrivialCosmetic or non-functional polishTypo on settings page. Button shadow misaligned by 1px.
PriorityDefinitionWhen to use
P0 / BlockerFix immediately; can block a releaseCritical bugs in production; trivial bugs in flagship marketing pages during launch
P1 / HighMust fix this sprintMajor bugs in primary flows
P2 / MediumFix in upcoming sprintMinor bugs, important enough not to defer indefinitely
P3 / LowBacklog; fix when convenientTrivial bugs in low-traffic areas

Writing effective summaries

The summary appears in lists, on dashboards, and in standups. Use the pattern:

[Page or Feature] — [What's wrong] — [When or under what condition]

Strong summaries:

Checkout — 500 error on POST /orders when promo code contains a hyphen
Mobile nav — Hamburger menu not clickable when scrolled past 200px
Login — "Forgot password" link 404s on production (works in staging)

Weak summaries to avoid:

Bug in checkout                   ← too vague
Doesn't work                      ← what doesn't work?
Help                              ← please no
Promo code issue                   ← which issue, on what code?

Steps to reproduce

The steps are the most important field. They must be:

  • Numbered — every action gets its own line.
  • Specific — "Click the Submit button" beats "Submit the form". "Enter WIDGET-42 in the SKU field" beats "add an item".
  • Self-contained — include test data, environment, and starting state. The developer should not have to ask any questions.
  • Reproducible at 100% — if it's intermittent, say so explicitly: "Reproduces ~3 in 10 attempts."

A solid example:

Preconditions:
  - Logged in as qa.user@example.com on staging (build 1.42.0)
  - Cart contains exactly 1 item: SKU "WIDGET-42", quantity 1, price $19.99

Steps:
  1. Open https://app-staging.example.com/checkout
  2. In "Promo code" field, enter: SUMMER-2025
  3. Click "Apply"
  4. Wait for promo to be accepted (success toast appears)
  5. Click "Place order"

Expected:
  - Order is created and receipt page (/order/:id) loads within 3 seconds.
  - Network: POST /api/orders → 201 Created.

Actual:
  - Red toast: "Something went wrong. Please try again."
  - Network: POST /api/orders → 500 Internal Server Error.
  - Server log: "ValidationError: invalid promo code format" (link to log entry below).
  - Order not created (verified in admin panel — no new row).

That report is one read away from a developer being able to reproduce it locally.

UI bug template

Summary: [Page] — [Visual or interaction issue] — [Condition]

Environment:
  - Build: [version or git SHA]
  - Browser: [Chrome 132 / Safari 17 / Firefox 122]
  - OS: [macOS 14.7 / Windows 11 / iOS 17]
  - Viewport: [1440×900 / 375×667]

Preconditions:
  - [User state: logged in/out, role, account type]
  - [App state: feature flag X enabled, cart with N items, etc.]

Steps to Reproduce:
  1. [Specific action]
  2. [Specific action]
  3. [Specific action]

Expected Result:
  [Pixel-precise or behaviour-precise description]

Actual Result:
  [What you observe]

Evidence:
  - Screenshot: [URL or attachment]
  - Screen recording: [URL or attachment]
  - DOM snapshot or computed style: [if relevant]

API bug template

Summary: [Endpoint] — [Status code or response issue] — [Condition]

Environment:
  - Service: [name + build/version]
  - Region: [us-east-1 / eu-west-2 / etc.]
  - Auth: [token type + scope, or "anonymous"]

Request:
  Method: POST
  URL: https://api.example.com/v1/orders
  Headers:
    Authorization: Bearer eyJhbG…
    Content-Type: application/json
    X-Request-Id: 7f1a-…

  Body:
    {
      "sku": "WIDGET-42",
      "promo": "SUMMER-2025"
    }

Expected Response:
  Status: 201 Created
  Body:
    {
      "id": "ord_…",
      "total": 14.99
    }

Actual Response:
  Status: 500 Internal Server Error
  Body:
    {
      "error": "ValidationError",
      "message": "invalid promo code format"
    }

Evidence:
  - Server log: [link to log line / Datadog query]
  - HAR file: [attachment]
  - Reproduction count: 5 of 5 attempts

Performance bug template

Summary: [Page or endpoint] — [Metric exceeded] — [Condition]

Environment:
  - Build: [version]
  - Network: [throttling profile or "no throttling"]
  - Device: [hardware specs if relevant]
  - Concurrent users: [load if applicable]

Preconditions:
  - [Cache state: cold/warm]
  - [Account size: e.g., user has 5,000 saved items]

Steps to Reproduce:
  1. [Specific action]
  2. [Specific action]

Expected:
  - [Metric]: [target] (e.g., LCP under 2.5s, p95 latency under 200ms)

Actual:
  - [Metric]: [observed value]
  - Trend: [is it consistent, getting worse, only at peak hours?]

Evidence:
  - Lighthouse report: [URL or attachment]
  - WebPageTest run: [URL]
  - APM trace: [link to Datadog/New Relic trace]
  - Reproduction count: [N of M attempts]

Real-world example: bad vs good

Bad bug report:

Summary: Login broken
Severity: Major
Steps: I can't log in. Fix it.

The developer has eight follow-up questions before they can even start.

Good bug report (same bug, written well):

Summary: Login — "Sign in" button does nothing on first click after fresh page load

Severity: Major
Priority: P1
Environment:
  - Build: 1.42.0 (staging)
  - Browser: Chrome 132 on macOS 14.7
  - Reproduces on Firefox 122 and Safari 17 — all consistent

Preconditions:
  - Hard reload of /login (Cmd+Shift+R)
  - Account: qa.user@example.com / Secret!23

Steps to Reproduce:
  1. Hard-reload https://app-staging.example.com/login
  2. Enter qa.user@example.com in Email
  3. Enter Secret!23 in Password
  4. Click "Sign in" once

Expected:
  - User is redirected to /dashboard within 2 seconds.

Actual:
  - First click on "Sign in" does nothing.
  - Second click works — user is redirected normally.
  - Reproduces 10 of 10 attempts on a fresh page load.
  - Console shows: "Cannot read property 'token' of undefined" on first click only.

Evidence:
  - Screen recording: [link]
  - Console log: [attachment]
  - Network HAR: [attachment] — first click never fires POST /auth/login

The good version is one paste away from a passing fix in the dev's local env.

Tool field mapping

The same eight fields map across the major trackers:

ConceptJiraAzure DevOpsGitHub Issues
SummarySummaryTitleTitle
SeverityCustom field "Severity"Severity (built-in)Label severity:critical/major/minor/trivial
PriorityPriorityPriorityLabel priority:p0/p1/p2/p3
EnvironmentEnvironmentBuild/Found in buildLabel env:staging, env:prod
StepsDescription (use ordered list)Repro StepsBody (ordered list)
ExpectedDescription sectionSystem Info or DescriptionBody section
ActualDescription sectionSystem Info or DescriptionBody section
EvidenceAttachmentsAttachmentsDrag/drop or paste image URL

Two practical tips regardless of tracker:

  • Add a dedicated regression label or field. Filing a bug for something that used to work is critical context — it changes triage urgency and helps engineering bisect.
  • Link the bug to the failing test. If a test caught it, link the run. If no test caught it, file a follow-up to add one. A bug without a regression test is a bug waiting to come back.