Defect Reporting
Two of your TUA-103 tests failed last week. A failed test is not a defect yet — it becomes one when you write it up so a developer can fix it without asking you a single question. This week you turn that 5% failure into a defect that does the job.
1 The Hook
You have two clear fails from Week 3: the Tūāpapa portal accepted a 5% contribution rate it should have rejected, and the rate selector cannot be reached by keyboard. You open the defect tracker and, in a hurry before standup, type: “Contribution rate broken, doesn’t work properly, dev needs to look at it.” You hit save and move on.
That defect sits in the backlog for a week. When a developer finally picks it up, they have no idea what “broken” means — which rate, on which build, with what data, doing what. They message you, you are in a workshop, half a day passes. By the time it is sorted, the defect has cost three people’s time and the fix that should have shipped this sprint slips to the next. Meanwhile a regulator-relevant bug — a member able to set a contribution rate that is illegal under KiwiSaver rules — is still live in the build.
A defect report is a handover. Its entire job is to move a problem from your head into a developer’s, completely, on the first read. A vague defect is not a small sin — it is a bug that stays unfixed, dressed up as work that was done. This week you learn to write defects that get fixed: reproducible, correctly rated, evidenced, and free of blame.
2 The Rule
A defect a developer cannot reproduce from the report alone is not fixed — it is bounced. Write every defect so someone who never saw the failure can trigger it on purpose: the build and data, exact steps, expected versus actual, evidence, and a severity that reflects impact. Describe the behaviour, never the person.
3 The Analogy
Calling a plumber to a leak.
“The water’s doing something weird, come fix it” gets you a plumber who arrives, wanders the house, and bills you for the hunt. “There’s a steady drip from the joint under the kitchen sink, it started after we ran the dishwasher, it fills a cup in about an hour, here’s a photo” gets you a plumber who arrives with the right part and fixes it in one visit.
A defect report is the call to the plumber. The more precisely you say where it leaks, when it started, and how bad it is — with a photo — the faster and cheaper the fix. “Contribution rate broken” is “the water’s doing something weird.” You are sending the developer into the house to hunt.
4 The Anatomy of a Defect Report
A defect report has a standard set of fields. Each one answers a question the developer would otherwise have to ask you.
- Title (summary): one line that names the component, the action, and the wrong behaviour — “Contributions: invalid rate 5% is accepted and saved.” Searchable and specific.
- Build / environment: 1.0.0-rc1, SIT. Without it, the developer cannot match the failure to the code.
- Preconditions / data: member Test01, current rate 3%. The starting state the steps assume.
- Steps to reproduce: numbered, exact, complete — the heart of the report.
- Expected result: what the requirement says should happen (5% rejected, allowed rates shown).
- Actual result: what actually happened (5% accepted, saved, no error).
- Severity and priority: how bad the impact is, and how urgently it should be fixed.
- Evidence: screenshot, audit-log row, console error — the artefact from your Week 3 record.
- Traceability: the requirement (TUA-103) and the failed test case (TC-103-07) it came from.
You already produced most of this in Week 3. A good result record is most of a good defect — the discipline carries straight over.
5 Severity vs Priority
These two are constantly confused, and getting them right is what makes triage work. Severity is how badly the defect affects the system if it occurs. Priority is how soon it should be fixed relative to everything else. They are set by different people for different reasons and they do not always move together.
High severity, lower priority: a crash on a feature nobody can reach yet because it is behind a flag. Severe if hit, but not urgent today.
Low severity, high priority: a typo in the Tūāpapa logo on the login page. Harmless to function, but embarrassing and visible, so fixed fast.
Low severity, low priority: minor wording on a rarely seen help tooltip.
As the tester you propose severity, because you saw the impact. Priority is usually agreed in triage with the product owner, because it weighs the defect against the whole backlog. Stating your severity with a one-line justification — “high: lets a member hold a contribution rate that is invalid under KiwiSaver rules” — gives triage what it needs to set priority well.
6 Reproducible Steps
The steps are where defects live or die. Good steps are numbered, start from a known state, name exact data, and stop at the point of failure with a clear statement of expected versus actual.
1. Log in to the portal (SIT, build 1.0.0-rc1) as member Test01.
2. Confirm the current contribution rate shows 3%.
3. Open the Contributions page.
4. In the rate field, enter 5% and confirm.
Expected: 5% is rejected; a message lists the allowed rates (3, 4, 6, 8, 10%);
the rate stays at 3%; no call is sent to the fund administration system.
Actual: 5% is accepted and saved; a normal confirmation is shown; the audit log
records 3% → 5% (row 88421).
A developer can follow this with their eyes closed and hit the bug on the first try. Compare it to “the rate thing is broken” — same defect, but one gets fixed this sprint and one starts a conversation.
7 Writing Without Blame
A defect is about behaviour, not people. “The developer forgot to validate the rate” is a guess, it is accusatory, and it is often wrong — the cause might be a missed requirement, a config issue, or a dependency. Write what the system did, not who you think failed.
Blameless: “The portal accepts 5%, which TUA-103 lists as invalid. Expected the rate to be rejected with the allowed rates shown; actual is that it saves. Likely the allowed-set validation is not applied — happy to pair on reproducing it.”
The blameless version is more useful, not just nicer. It keeps the conversation on the system, it offers help, and it protects the working relationship you need for the next six defects. Blame makes developers defensive, and defensive developers argue with your defects instead of fixing them.
8 Common Mistakes
🚫 A vague title and no steps
Why it happens: You just saw the bug, so it feels obvious and writing it out feels slow.
The fix: The developer did not see it and is reading days later. A specific title and numbered, data-exact steps are the difference between a fix this sprint and a week of back-and-forth. The few minutes you save writing it cost the team hours.
🚫 Confusing severity with priority
Why it happens: Both feel like “how important is this”, so they get collapsed into one number.
The fix: Severity is impact if it happens; priority is how soon to fix relative to everything else. A high-severity bug behind a feature flag may be low priority; a tiny logo typo may be high priority. Propose severity with a reason, and let triage set priority.
🚫 Reporting a symptom you can’t reproduce
Why it happens: You saw something odd once and want it on record before you forget.
The fix: Try to reproduce it first and capture the exact conditions. If it is genuinely intermittent, say so explicitly and give everything you do know — build, data, frequency, any logs. An honest “intermittent, seen 2 of 10 attempts” is useful; a one-off with no detail is noise.
🚫 Blaming the developer in the report
Why it happens: Frustration leaks into the write-up, especially under deadline pressure.
The fix: Describe what the system did, not who you think failed. Blame is often wrong about the cause, it makes developers defensive, and it damages the relationship you need for every future defect. State the behaviour and offer to help reproduce it.
9 Now You Try
Three graded exercises on writing defects for the Tūāpapa portal. Write your answer, run it for feedback from your test lead, then compare to the model answer.
A teammate logged the defect below for the 5%-rate failure. Identify 3 problems that would stop a developer fixing it on the first read, and say what each one needs.
Title: Contribution rate broken.
Description: The dev didn’t validate the rate properly so it’s letting bad values through. Critical, fix ASAP. It’s obviously wrong.
List 3 problems and what each needs:
Show model answer
This defect bounces on first read. Any three well-explained earn full marks. 1. Vague title and no steps to reproduce — "Contribution rate broken" names no component action or wrong behaviour, and there are no numbered steps, build, environment or data. Needs: a specific title (e.g. "Contributions: invalid rate 5% is accepted and saved") and reproducible steps from a known state (member Test01, rate 3%, build 1.0.0-rc1, SIT, enter 5%). 2. No expected vs actual and no evidence — it never states what should happen (5% rejected, allowed rates shown) versus what did (5% accepted and saved), and gives no screenshot or audit-log row. Needs: expected/actual side by side plus the artefact. 3. Blame and a misjudged rating — "the dev didn't validate properly" blames a person and guesses the cause, and "Critical, fix ASAP, obviously wrong" conflates severity with priority and adds no justification. Needs: a blameless description of behaviour, a proposed severity with a reason (high — a member can hold a KiwiSaver-invalid rate), and priority left to triage. The point: this is a real, regulator-relevant bug being hidden behind a write-up that no one can act on.
Rewrite that defect as a complete, blameless report for the 5%-rate failure, with fields: Title, Build/Environment, Preconditions, Steps to reproduce, Expected, Actual, Severity (with justification), Evidence, Traceability.
“Contribution rate broken. The dev didn’t validate the rate. Critical, fix ASAP.”
Rewrite as a complete defect report:
Show model answer
Title: Contributions: invalid rate 5% is accepted and saved (should be rejected) Build/Environment: 1.0.0-rc1, SIT Preconditions: Member Test01 logged in via RealMe; current contribution rate 3% Steps to reproduce: 1. Log in as Test01; confirm current rate shows 3%. 2. Open the Contributions page. 3. Enter 5% in the rate field and confirm. Expected: 5% is rejected; a message lists the allowed rates (3, 4, 6, 8, 10%); the rate stays 3%; no call is sent to the fund administration system. Actual: 5% is accepted and saved; a normal success confirmation is shown. Severity: High — a member can set a contribution rate that is invalid under KiwiSaver rules, which misstates their savings and is a compliance concern the FMA would care about. (Priority to be set in triage.) Evidence: Screenshot confirm-5pct.png; audit-log row 88421 (3% -> 5%). Traceability: Requirement TUA-103; failed test case TC-103-07. What makes this strong: a specific searchable title, build/data so it can be reproduced, expected-vs-actual, a justified severity without naming a person, real evidence, and traceability back to the requirement and test. Nothing blames anyone and nothing is left to a follow-up question.
Now write the full defect for the second Week 3 failure: the rate selector cannot be reached by keyboard (Tab skips it), so the flow is unusable for keyboard and screen-reader users. Use all the report fields, propose a severity with justification, and reference the relevant NZ accessibility obligation.
Show model answer
Title: Contributions: rate selector is not reachable by keyboard (Tab skips it) Build/Environment: 1.0.0-rc1, SIT Preconditions: Member Test01 logged in; on the Contributions page; navigating by keyboard only Steps to reproduce: 1. Open the Contributions page. 2. Press Tab repeatedly from the top of the page and observe the focus order. Expected: Focus reaches the rate selector; the member can open and choose a rate using the keyboard; a screen reader announces the selector, the confirmation and any error (NZ Government Web Accessibility Standard / WCAG keyboard operability). Actual: Focus order skips the rate selector entirely — it jumps from the page heading straight to the Save button. The selector cannot be focused or operated by keyboard, so a screen-reader user cannot change their rate at all. Severity: High — the core function of the page is completely inaccessible to keyboard and screen-reader users, which fails the NZ Government Web Accessibility Standard and excludes members with disabilities from managing their KiwiSaver. (Priority to be set in triage.) Evidence: Screen recording kbd-tab-order.mp4 showing focus skipping the selector. Traceability: Requirement TUA-103 (accessibility criterion); failed test case TC-103-11. A strong report gives reproducible keyboard steps, states the expected behaviour against the NZ accessibility standard, justifies a high severity on exclusion grounds, attaches the recording, and traces to the requirement and test — all without blaming anyone.
10 Self-Check
Click each question to reveal the answer.
Q1: What is the one job of a defect report?
To hand the problem completely from your head to a developer’s on the first read — so they can reproduce and fix it without asking you anything. A defect they cannot reproduce from the report alone is bounced, not fixed.
Q2: Explain severity versus priority with an example.
Severity is how bad the impact is if the defect occurs; priority is how soon to fix it relative to everything else. A crash behind an unreleased feature flag is high severity but low priority; a logo typo on the login page is low severity but high priority. The tester proposes severity from observed impact; triage sets priority against the backlog.
Q3: What is the most common reason a defect bounces back as “cannot reproduce”?
An unstated precondition — the report assumes a starting state, a setting, or a particular member that was never written down, plus often a missing build number. Reading your steps as if you have never seen the feature catches these before you submit.
Q4: Why write defects without blame, beyond just being polite?
Because blame is usually wrong about the cause, it makes developers defensive so they argue with your defect instead of fixing it, and it damages the relationship you need for every future defect. Describing behaviour rather than people keeps the conversation on the system and gets the bug fixed faster.
Q5: Why is the 5%-rate defect rated high severity?
Because it lets a member set a contribution rate that is invalid under KiwiSaver rules, which misstates their savings and is a compliance concern the FMA would care about. Severity reflects that real impact — this is not a cosmetic bug, it is a member holding an illegal rate on a regulated financial product.
11 Interview Prep
Real questions asked in NZ QA interviews. Read the model answers, then practise your own version.
“What makes a good defect report?”
It moves the problem completely from my head to the developer’s on the first read. So: a specific title naming the component and the wrong behaviour, the build and environment, the preconditions and data, numbered steps from a known state, expected versus actual, a proposed severity with a one-line justification, evidence like a screenshot or audit-log row, and traceability to the requirement and the failed test. The test I apply is whether a developer who never saw the failure could reproduce it on purpose from the report alone. If they’d have to message me, it isn’t finished.
“How do you decide the severity of a bug?”
Severity is about impact if the defect occurs, so I think about who is affected and how badly. For the Tūāpapa portal, a member being able to set a KiwiSaver-invalid contribution rate is high severity because it misstates their savings and is a compliance concern for the FMA — not because it looks dramatic. I propose the severity with a short justification of the impact, and I keep it separate from priority, which the product owner and I agree in triage by weighing the bug against the rest of the backlog. A logo typo can be low severity but high priority; the two are not the same axis.
“A developer pushes back on one of your bugs. How do you handle it?”
I keep it about the behaviour, not the person — which is why I write defects blamelessly in the first place. I’d check we’re on the same build and data, walk through my reproducible steps and the evidence, and offer to pair on reproducing it. Often the disagreement is a build or environment difference, or a requirement that was read two ways, and pairing surfaces that quickly. If it turns out my report was thin, I fix the report. The goal is a fixed bug and a working relationship, not winning the argument.