Bug Report Template
A defect report that developers actually act on. One template, a field-by-field guide, severity vs priority explained, and a worked NZ example.
1 The One-Sentence Rule
"Enough information for a developer who has never seen the bug to reproduce it alone."
That single rule explains every field in the template. If a field helps a stranger reproduce or understand the defect, it belongs. If it doesn't, it's noise. Every vague bug report that sits in a backlog untouched violates this rule somewhere — usually in the title, the steps, or missing environment detail.
Write for the developer who picks up your ticket at 8 am on a Monday without any context. They shouldn't need to ask a single follow-up question.
2 Template
Copy this block into your defect tracking tool. Fill every field — blank fields get the ticket sent back.
**Title:** [Verb] + [Noun] + [Observed behaviour]
e.g. "Submit on IRD filing returns 500 when amount has comma"
**Environment:** Browser/OS/device — e.g. Chrome 125 / Windows 11 / 1920×1080
**Build/Version:** App version or commit SHA — e.g. v2.14.3 / build #4821
**Severity:** Critical | High | Medium | Low
**Priority:** Critical | High | Medium | Low
**Component:** Module or area of the system — e.g. Tax Filing > Submit Form
**Steps to Reproduce:**
1.
2.
3.
**Expected Result:**
What the system should do according to the spec or common sense.
**Actual Result:**
What the system actually does. Quote error messages exactly.
**Evidence:**
Screenshot, screen recording, network log, or console output.
Attach file or paste URL.
**Workaround:**
Steps the user can take to complete their task in the meantime.
Write "None" if no workaround exists.
**Reporter:** Your name
**Date:** YYYY-MM-DD
3 Field Guide — Good vs Bad
The same defect can be a crisp, actionable ticket or a time-wasting mystery depending on how each field is filled. Here is what separates the two.
| Field | ✓ Good | ✗ Bad |
|---|---|---|
| Title | ✓ Submit on IRD filing returns 500 when amount has comma | ✗ Submit broken |
| Environment | ✓ Firefox 126 / macOS 14.5 / 1440×900 | ✗ My laptop |
| Build/Version | ✓ v3.2.1 / build #5902 (UAT deployed 2026-06-25) | ✗ Latest |
| Steps to Reproduce | ✓ Numbered steps, each a single action, exact values given | ✗ "Go to filing page and try to submit" |
| Expected Result | ✓ Form submits and user sees confirmation screen with reference number | ✗ It should work |
| Actual Result | ✓ HTTP 500 page displayed; console shows NumberFormatException: For input string "1,500" |
✗ Error page |
| Evidence | ✓ Attached screenshot + HAR file showing 500 response | ✗ (blank) |
| Workaround | ✓ Enter amount without comma (e.g. 1500 instead of 1,500) | ✗ None (when one exists) |
4 Severity vs Priority
Severity is how bad the defect is technically — the impact on the system. Priority is how urgently it needs to be fixed — the business and scheduling decision. They are set by different people and can point in opposite directions.
| Severity | Priority | What it means | NZ example |
|---|---|---|---|
| Critical | Critical | System is broken and must be fixed right now. Everything stops. | Inland Revenue e-filing portal goes down on 7 April (tax deadline). Data loss on KiwiSaver withdrawal. |
| Critical | Low | Technically severe, but not urgent right now. Often because the affected feature isn't live yet, or the release is months away. | Payment gateway crashes on a feature still in development — severe, but no users affected yet. |
| Low | Critical | Minor bug technically, but politically or commercially it must ship fixed. CEO is demoing tomorrow. | Logo misaligned on login screen the morning before a client launch. Brand compliance breached on a government portal landing page. |
| Low | Low | Cosmetic or minor. Fix it when the team has capacity. Goes on the improvement backlog. | Tooltip text has an extra space. Footer link opens in same tab instead of new tab. |
Severity definitions
| Level | Badge | Definition |
|---|---|---|
| Critical | Critical | System crash, data loss, security breach, or complete blocking of a core user flow. No workaround exists. |
| High | High | Major feature broken or incorrect. Significant user impact. A workaround may exist but is not acceptable long-term. |
| Medium | Medium | Feature partially works. User can still complete their task via a workaround. Inconvenient but not blocking. |
| Low | Low | Cosmetic, minor, or negligible impact. Spelling error, alignment issue, minor UI inconsistency. |
5 Worked Example
A real-world style defect found during testing of MyMSD (Work and Income New Zealand's self-service portal).
| Field | Value |
|---|---|
| Title | Date picker on MyMSD appointment form accepts 29 Feb on non-leap years |
| Environment | Chrome 125 / Windows 11 / 1920×1080 |
| Build/Version | MyMSD UAT build #3204 (deployed 2026-06-20) |
| Severity | High — invalid date silently submitted; downstream records corrupted |
| Priority | High — release to production is next week |
| Component | Appointments > Book Appointment > Date Picker |
| Steps to Reproduce |
1. Log in to MyMSD UAT at uat.msd.govt.nz with test account testuser012. Navigate to Appointments > Book a new appointment 3. In the date field, manually type 29/02/2025 (2025 is not a leap year)4. Click Confirm appointment |
| Expected Result | Form should reject the date with a validation message: "29 February does not exist in 2025. Please select a valid date." |
| Actual Result | Form accepts the date without error and displays a confirmation screen. The appointment record in the database shows 2025-03-01 (the browser silently rolled over to 1 March). The user believes their appointment is on 29 Feb; the system has booked 1 Mar. |
| Evidence | Screenshot attached showing confirmation screen with "29 February 2025". DB record screenshot showing appointment_date = 2025-03-01. |
| Workaround | Use the calendar picker widget instead of manual keyboard entry — the calendar correctly greyed out Feb 29 in non-leap years. Manual text entry bypasses this validation. |
| Reporter | Test Team / QA Analyst |
| Date | 2026-06-27 |
6 Tool Mapping — Jira vs Azure DevOps
The template fields are universal. Here is how they map into the two most common defect tracking tools used in NZ teams.
| Template Field | Jira (Bug issue type) | Azure DevOps (Bug work item) |
|---|---|---|
| Title | Summary | Title |
| Environment | Environment field (custom) or label | System Info (under System) |
| Build/Version | Affects Version/s | Found In Build |
| Severity | Severity (custom field, usually) | Severity |
| Priority | Priority | Priority |
| Component | Component/s | Area Path |
| Steps to Reproduce | Steps to Reproduce (custom) or Description | Repro Steps |
| Expected Result | Part of Description or custom field | System Info > Expected |
| Actual Result | Part of Description or custom field | System Info > Actual |
| Evidence | Attachments | Attachments |
| Workaround | Part of Description | Part of Description |
| Reporter | Reporter (auto-populated) | Created By (auto-populated) |
| Date | Created date (auto-populated) | Created Date (auto-populated) |
7 Copy-Paste Block — Markdown
Plain Markdown version, ready for GitHub Issues, Confluence, Notion, or any tool that renders Markdown.
## Bug Report **Title:** [Verb] + [Screen/Component] + [Observed behaviour when trigger condition] | Field | Value | |-------|-------| | **Environment** | Browser / OS / Resolution | | **Build/Version** | v0.0.0 / build #0000 | | **Severity** | Critical / High / Medium / Low | | **Priority** | Critical / High / Medium / Low | | **Component** | Module > Sub-module | ### Steps to Reproduce 1. 2. 3. ### Expected Result What the system should do. ### Actual Result What the system actually does. Quote error messages exactly. ### Evidence <!-- Attach screenshot, HAR file, console log, or screen recording --> ### Workaround Steps to complete the task in the meantime, or write **None**. --- **Reporter:** Your name · **Date:** YYYY-MM-DD