Requirements & Clarifying Questions
Your first week on the Tūāpapa KiwiSaver portal. The user stories have landed, the deadline is set, and the product owner is busy. The cheapest defect to fix is the one you stop before it is built — and you stop it by asking the right question.
1 The Hook
It is Monday morning. You have just started as the QA on the Tūāpapa KiwiSaver member portal rebuild. Tūāpapa is a fictional NZ KiwiSaver provider with about 180,000 members, and the board has paid for a new portal where members log in with RealMe, check their balance, change their contribution rate, and switch funds.
Aroha, the product owner, drops a set of user stories into the team board and says “these are signed off, let’s go.” One of them reads: “As a member, I want to change my contribution rate so that I can save more.” The developers nod. The sprint starts.
Three weeks later the build arrives and you find that members can set their contribution rate to anything — 2%, 7%, 11%, even 100%. But KiwiSaver contribution rates are set in law: an employee can only choose 3%, 4%, 6%, 8% or 10%. The developers built exactly what the story said. The story never said which rates were allowed. Now the rule has to be retrofitted, the IRD-facing logic reworked, and the test cases rewritten. Weeks of work, because nobody asked one question in week one.
That question — “which contribution rates are valid?” — costs nothing on Monday morning and a fortune three weeks later. This week you learn to find those questions before the code is written. Reviewing requirements is the highest-value testing you will ever do, because it is testing the idea before it becomes a defect.
2 The Rule
A requirement you cannot test is a defect waiting to be built. Your first job as a tester is not to run tests — it is to read every requirement and ask: could two reasonable people build different things from this? Every ambiguity you surface as a clarifying question on day one is a defect you prevented for free.
3 The Analogy
A builder pricing a house off a sketch on a napkin.
A good builder does not start pouring the foundation the moment a client hands over a rough sketch. They ask: how many bedrooms, where does the plumbing run, what is the council consent for, is that wall load-bearing? They ask before the concrete is wet, because moving a wall on paper is a pencil line and moving it after the slab is poured is a demolition job.
A requirement is the sketch. The build is the slab. Your clarifying questions are the conversation that happens while the design is still on paper and still cheap to change. A tester who waits for the build to ask “what should this actually do?” is the builder pouring concrete around a wall in the wrong place.
4 This Week’s Brief
Here is the slice of the Tūāpapa backlog you have been asked to review this week. Read it the way you would on a real team — not for spelling, but for what a developer might build differently from what Aroha actually means.
As a member, I want to log in with RealMe so that I can see my account securely.
Acceptance: Member can log in. Account page shows after login.
TUA-102 — View my balance
As a member, I want to see my KiwiSaver balance so that I know how much I have saved.
Acceptance: Balance is displayed on the account page.
TUA-103 — Change my contribution rate
As a member, I want to change my contribution rate so that I can save more.
Acceptance: Member can change their rate. Change is saved.
TUA-104 — Update my contact details
As a member, I want to update my email and phone so that Tūāpapa can reach me.
Acceptance: Member can edit their details. Details are updated.
Every one of these stories is shippable-looking and quietly under-specified. The skill this week is seeing the gaps. The rest of the lesson gives you the tools to name them precisely.
5 The Five Kinds of Ambiguity
Ambiguity is not random. It shows up in the same few shapes, over and over. Learn the shapes and you stop missing them.
1. Missing boundaries
The story says “change my contribution rate” but never says which rates are allowed, what the minimum and maximum are, or what happens at the edges. Any time a requirement involves a number, a date, or a length, ask for the boundaries. KiwiSaver rates are 3, 4, 6, 8 or 10% — the story should say so.
2. Undefined error behaviour
“Member can log in” tells you the happy path. It says nothing about a failed RealMe login, a locked account, a member whose record cannot be found, or the fund administration system being down. A requirement that only describes success is half a requirement.
3. Vague verbs and nouns
“Details are updated” — updated where, and when? Immediately, or overnight? In the portal only, or also pushed to the fund administration system and to IRD? “Balance is displayed” — as at when? Real-time, or last night’s close? Words like updated, displayed, saved and secure hide whole decisions.
4. Missing non-functional rules
None of these stories mention accessibility, performance, or privacy — but a member-facing NZ financial portal must meet the NZ Government Web Accessibility Standard, must not be slow on a phone, and handles personal information under the Privacy Act 2020. If a rule is implied by the context but absent from the story, raise it.
5. Unstated dependencies
TUA-102 depends on the fund administration system returning a balance. TUA-103 may need IRD to be notified of a rate change. TUA-101 depends on RealMe. The story treats these as invisible, but each is a system you do not control and must test the failure of.
6 Writing a Good Clarifying Question
A clarifying question is not “this is unclear.” That puts the work back on the busy product owner. A good question names the ambiguity, offers the likely options, and states why it matters — so Aroha can answer it in one line.
Strong: “TUA-103 — which contribution rates may a member select? KiwiSaver employee rates are 3%, 4%, 6%, 8% and 10%. Should the portal restrict the dropdown to those values and reject anything else, or allow free entry? This changes the validation and the IRD notification, so I need it before writing test cases.”
The strong version does three things: it points at a specific story, it proposes the answer the developer would otherwise have to guess, and it explains the consequence so the question gets prioritised. A question shaped like this is answered in a sentence; a vague one starts a meeting.
7 Turning Answers Into Testable Acceptance Criteria
The point of asking is to end up with acceptance criteria you can actually test. “Change is saved” is not testable — saved where, with what value, visible how? A testable criterion states the input, the expected result, and the observable evidence.
• The rate selector offers only 3%, 4%, 6%, 8% and 10%; no other value can be chosen or typed.
• On selecting a new valid rate and confirming, the portal shows a success message naming the new rate and the date it takes effect.
• The new rate is sent to the fund administration system; if that call fails, the member sees a clear error and the old rate is kept.
• A change to the rate is recorded in the audit log with member ID, old rate, new rate and timestamp.
• The whole flow is operable by keyboard and announced by a screen reader.
Notice the shape: each line has an input or trigger, an expected outcome, and something observable to check. That is a criterion a tester in Week 2 can turn straight into test cases — which is exactly what you will do.
8 Common Mistakes
🚫 Assuming “signed off” means “complete and unambiguous”
Why it happens: A signed-off story feels final, and questioning it feels like second-guessing the product owner.
The fix: Sign-off means the business wants the feature, not that the detail is testable. Review every signed-off story for ambiguity anyway — that is your job, and the product owner will thank you when it saves a rebuild.
🚫 Only checking the happy path
Why it happens: The story is written as a success scenario, so the failure cases feel out of scope.
The fix: For every “member can do X”, ask what happens when X fails — bad login, system down, record not found, invalid input. Half of real defects live in the error behaviour the story never mentioned.
🚫 Asking vague questions that create more work
Why it happens: It is faster to write “this is unclear” than to do the thinking and propose options.
The fix: Name the specific story, offer the likely answers, and state the consequence. A precise question is answered in a sentence; a vague one wastes a meeting and gets deprioritised.
🚫 Ignoring the non-functional rules nobody wrote down
Why it happens: Accessibility, performance and privacy are rarely in the user story, so they feel like someone else’s problem.
The fix: A member-facing NZ financial portal carries accessibility, performance and Privacy Act 2020 obligations whether or not the story says so. Raise them in Week 1 — retrofitting accessibility after build is brutal.
9 Now You Try
Three graded exercises on this week’s Tūāpapa brief. Write your answer, run it for feedback from your test lead, then compare to the model answer.
Read story TUA-101 (Log in with RealMe) again. Identify 3 ambiguities or gaps a developer could build wrongly, and name which kind of ambiguity each is (missing boundaries, undefined error behaviour, vague verbs/nouns, missing non-functional rules, unstated dependencies).
As a member, I want to log in with RealMe so that I can see my account securely.
Acceptance: Member can log in. Account page shows after login.
List 3 ambiguities and the kind of each:
Show model answer
There are several real gaps in TUA-101; any three well-explained earn full marks.
1. Undefined error behaviour — the story only covers a successful login. What happens on a failed RealMe authentication, a member whose Tūāpapa record cannot be matched to their RealMe identity, or a locked account? None are specified, so a developer might leave the member on a blank page.
2. Unstated dependency — login depends on RealMe being available. The story does not say what happens when RealMe is down or times out. That is an external system you do not control and must test the failure of.
3. Vague noun ("securely") — "see my account securely" implies session timeout, no balance leaking to a shared device, HTTPS, and not exposing personal data. None are defined, so "secure" means whatever the developer assumes.
Bonus: Missing non-functional rules — no mention of accessibility (NZ Government Web Accessibility Standard) or session/performance behaviour, both mandatory for a member-facing NZ financial portal.
The trap: "Member can log in / Account page shows" looks complete but only describes the happy path. The defects live in everything it left out.
A junior tester raised the clarifying question below about TUA-104 (Update contact details). It is too vague to be useful. Rewrite it as a strong clarifying question that names the story, proposes the likely options, and states why it matters.
“The update details story needs more detail. What does ‘updated’ mean? Please clarify.”
Rewrite as a strong clarifying question:
Show model answer
Story: TUA-104 — Update my contact details Question: When a member updates their email or phone, where and when does the change propagate, and is the new email verified before it becomes the contact of record? Likely options: (a) saved in the portal only, immediately; (b) saved in the portal AND pushed to the fund administration system overnight; (c) saved everywhere immediately. And: is a new email confirmed via a verification link before Tūāpapa sends statements to it, or trusted on entry? Why it matters / what it blocks: This determines whether a member who mistypes their email stops receiving KiwiSaver statements, and whether Tūāpapa is sending personal information to an unverified address under the Privacy Act 2020. It changes the validation, the integration test, and the negative test cases — I cannot design tests for TUA-104 without it. What makes this strong: it names the story, proposes concrete options the product owner can pick from, and ties the answer to a real consequence (members losing statements; a privacy risk) so it gets prioritised. The original did none of these.
Produce the clarifying-questions artefact you would send Aroha for story TUA-103 (Change contribution rate). Write at least 5 questions, each naming the gap, proposing options, and stating why it matters. Cover boundaries, error behaviour, dependencies, audit/privacy, and accessibility.
Show model answer
TUA-103 — Change my contribution rate — clarifying questions for Aroha: Q1 (boundaries): Which rates may a member select? KiwiSaver employee rates are 3%, 4%, 6%, 8% and 10%. Should the selector restrict to exactly those, or allow other values? — Why: this drives the validation and every boundary test case. Q2 (error behaviour): If the new rate cannot be saved to the fund administration system, what should the member see, and is the old rate kept? — Why: without this the member could believe a failed change succeeded and under-contribute. Q3 (dependency): Does a rate change need to be notified to IRD or the member's employer, and is that real-time or batch? — Why: it adds an integration to test and a failure mode if that call fails. Q4 (audit/privacy): Is every rate change recorded in an audit log (who, old rate, new rate, timestamp)? — Why: a regulated KiwiSaver provider needs an auditable trail of changes to a member's savings, and the FMA may ask to see it. Q5 (accessibility/non-functional): Must the rate-change flow meet the NZ Government Web Accessibility Standard and work by keyboard and screen reader? How quickly must the confirmation appear on a mid-range phone? — Why: these are mandatory for a member-facing NZ financial portal and are far cheaper to build in now than to retrofit. Strong lists are specific, propose options, and tie each question to a consequence. Weak lists repeat "please clarify the rate" five times — that is the difference being marked.
10 Self-Check
Click each question to reveal the answer.
Q1: Why is reviewing requirements the highest-value testing you can do?
Because the cheapest defect to fix is the one never built. An ambiguity caught as a clarifying question on day one costs a sentence to resolve; the same ambiguity discovered after the build costs a rework of code, tests and integrations. You are testing the idea before it becomes a defect.
Q2: Name three of the five kinds of ambiguity to look for in a requirement.
Any three of: missing boundaries (no min/max/allowed values), undefined error behaviour (only the happy path is described), vague verbs/nouns (“saved”, “updated”, “secure”), missing non-functional rules (accessibility, performance, privacy), and unstated dependencies (external systems the story treats as invisible).
Q3: What three things make a clarifying question strong rather than weak?
It names the specific story or requirement, it proposes the likely options so the product owner can answer in a sentence, and it states the consequence (what breaks or is blocked) so the question gets prioritised. “This is unclear” does none of these.
Q4: A story says “the member can log in.” What category of behaviour is almost certainly missing, and why does it matter?
The error behaviour — failed login, locked account, record not found, the identity provider being down. Stories are written as success scenarios, but most real defects live in the failure paths the requirement never described. Half a requirement is the half you have to ask for.
Q5: What makes an acceptance criterion testable?
It states a clear input or trigger, a specific expected result, and something observable to check — not “change is saved” but “the new rate appears in the confirmation message and is recorded in the audit log with member ID, old rate, new rate and timestamp.” If you cannot point at how you would verify it, it is not yet testable.
11 Interview Prep
Real questions asked in NZ QA interviews. Read the model answers, then practise your own version.
“You’re handed a user story that’s already signed off. What do you do first?”
I read it for testability before anything else. Sign-off means the business wants the feature, not that the detail is unambiguous, so I check every requirement against one test: could two reasonable developers build different things from this? I look for missing boundaries, undefined error behaviour, vague words like “saved” or “secure”, missing accessibility and privacy rules, and dependencies on systems we don’t control. Anything that fails that test becomes a clarifying question I raise immediately, because a gap caught on paper is free and the same gap caught after build is a rework.
“Give me an example of an ambiguous requirement and the question you’d ask.”
“As a member I want to change my contribution rate” never says which rates are valid. KiwiSaver employee rates are fixed in law — 3, 4, 6, 8 or 10% — so I’d ask: should the selector restrict to exactly those values and reject anything else, and does a change need to be notified to IRD or the fund administrator? I’d explain that the answer drives the validation, the integration, and every boundary test case, so I need it before I design tests. Naming the options and the consequence gets me a one-line answer instead of a meeting.
“How do you make sure non-functional requirements aren’t forgotten?”
I treat them as implied by the context even when no story mentions them. A member-facing NZ financial portal carries accessibility obligations under the NZ Government Web Accessibility Standard, privacy obligations under the Privacy Act 2020, and performance expectations on a phone — so in requirements review I raise each one as a question for the relevant story. Accessibility especially is far cheaper to design in during Week 1 than to retrofit after the build, so I want it on the table before any code is written.