Templates · Defect Management

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
Pro tip: Write "Expected Result" before "Actual Result." This forces you to think about what the system should do — which is often the part testers skip.

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)
Title formula: [Action verb] + [Screen/component] + [observed behaviour] + [trigger condition]. Never start a title with "Bug" — that's what the ticket type is for.

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.
Who sets what: Testers propose Severity based on technical impact. Product owners or the test lead set Priority based on business need. Never let a developer close a Critical/High defect by unilaterally marking it Low — escalate to the product owner.

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).

Worked Example — MyMSD Date Picker
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 testuser01
2. 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
Note the data discrepancy: Pointing out the gap between what the user sees (29 Feb confirmation) and what the database stored (1 Mar) is what turns this from a minor UX note into a High-severity data integrity issue. Always check both layers.

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)
Jira tip: If your project does not have a dedicated Severity field, add it as a custom field — do not abuse Priority to carry both values. Mixing them makes metrics useless and triage harder.

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