Bug Report Template (QA)
A QA bug report — title, severity/priority, environment, numbered steps to reproduce, expected vs. actual result, and attachments — structured so a developer can reproduce and fix the issue fast.
Live preview
BUG REPORT [BUG-1042] Checkout: "Apply promo" button does nothing on mobile Safari Severity: High Priority: P2 Status: Open Reported by: QA — Sample Tester Date: May 23, 2026 Frequency: Always ENVIRONMENT iOS 18.4, Mobile Safari iPhone 14 App build 2026.5.2 (staging) User: logged-in, cart with 2 items STEPS TO REPRODUCE 1. Add any 2 items to the cart and go to Checkout 2. Enter a valid promo code (e.g., SAVE10) in the promo field 3. Tap "Apply promo" 4. Observe: nothing happens (no spinner, no error, no discount) EXPECTED RESULT The promo code is validated and the discount is applied to the order total, or a clear error message is shown if invalid. ACTUAL RESULT Tapping "Apply promo" does nothing — no network request is fired (confirmed in devtools), no UI feedback. Works correctly on desktop Chrome. ATTACHMENTS / LOGS Screen recording: [link] Console: no errors logged Network tab: no request to /api/promo on tap A good bug report lets a developer reproduce the issue without asking you any questions. If they can't reproduce it, attach a screen recording and exact build.
About this template
A bug report has exactly one job: let someone who is not you reproduce and fix the problem without a back-and-forth. The reports that get fixed fast all share the same backbone — a **specific title**, the **environment**, **numbered steps to reproduce**, and the contrast between **expected and actual** results. That expected-vs-actual pairing is the heart of the report: "it's broken" is not actionable, but "I expected the discount to apply; instead nothing happened and no network request fired" tells a developer where to look. Write the title as one precise sentence that names the area, the action, and the symptom ("Checkout: Apply-promo button does nothing on mobile Safari") rather than a vague "promo broken." Capture the **environment** precisely — OS, browser/device, and especially the exact build or version — because most "cannot reproduce" responses come from a mismatch there. Make the steps so literal that anyone can follow them, and include **frequency** (always vs. intermittent), since intermittent bugs need different handling. Distinguish **severity** (how bad the impact is) from **priority** (how soon the team will fix it) — they are not the same: a cosmetic typo on the homepage can be low severity but high priority, while a crash in a rarely used admin screen can be high severity but lower priority. Finally, attach evidence: a screen recording, console errors, and the network tab beat paragraphs of description. Keep one bug per report; bundling several issues into one ticket is the fastest way to get a report half-fixed and closed.
When to use it
- Filing a software defect for a dev team to reproduce and fix.
- Standardizing QA reports so every bug has the same required fields.
- Capturing a clear repro before details are forgotten.
- Triaging with separate severity and priority.
What to include
- A specific one-sentence title and a bug ID.
- Severity, priority, status, reporter, date, and frequency.
- Exact environment: OS, browser/device, and build/version.
- Numbered steps to reproduce.
- Expected vs. actual result, plus attachments/logs.