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:
| Field | Purpose | Example |
|---|---|---|
| Summary | One-line title scannable in a list | Checkout — 500 error when promo code contains a hyphen |
| Severity | How broken is the system (QA decides) | Major |
| Priority | How urgent is the fix (Product decides) | P1 |
| Environment | Where it reproduces | Staging, build 1.42.0, Chrome 132, macOS 14.7 |
| Preconditions | State required before steps run | Logged in as qa.user@example.com; cart has 1 item |
| Steps to Reproduce | Numbered, deterministic actions | See template below |
| Expected Result | What should happen | Order is created; receipt page loads |
| Actual Result | What does happen | Toast "Something went wrong"; POST /orders → 500 |
| Evidence | Screenshot, screen recording, HAR, log link | Attached |
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.
| Severity | Definition | Real-world example |
|---|---|---|
| Critical | System unusable; data loss; security exposure | Users can't log in. Payments are double-charging. PII is exposed in logs. |
| Major | Core feature broken with no workaround | Checkout fails for all promo codes. Sign-up emails not sent. |
| Minor | Feature broken with a viable workaround | Search filter resets on pagination. Dashboard chart shows wrong colour. |
| Trivial | Cosmetic or non-functional polish | Typo on settings page. Button shadow misaligned by 1px. |
| Priority | Definition | When to use |
|---|---|---|
| P0 / Blocker | Fix immediately; can block a release | Critical bugs in production; trivial bugs in flagship marketing pages during launch |
| P1 / High | Must fix this sprint | Major bugs in primary flows |
| P2 / Medium | Fix in upcoming sprint | Minor bugs, important enough not to defer indefinitely |
| P3 / Low | Backlog; fix when convenient | Trivial 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-42in 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:
| Concept | Jira | Azure DevOps | GitHub Issues |
|---|---|---|---|
| Summary | Summary | Title | Title |
| Severity | Custom field "Severity" | Severity (built-in) | Label severity:critical/major/minor/trivial |
| Priority | Priority | Priority | Label priority:p0/p1/p2/p3 |
| Environment | Environment | Build/Found in build | Label env:staging, env:prod |
| Steps | Description (use ordered list) | Repro Steps | Body (ordered list) |
| Expected | Description section | System Info or Description | Body section |
| Actual | Description section | System Info or Description | Body section |
| Evidence | Attachments | Attachments | Drag/drop or paste image URL |
Two practical tips regardless of tracker:
- Add a dedicated
regressionlabel 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.