Use Case Testing
Derive test cases from use case flows. Test what real users actually do — the happy path, alternate routes, and the things that go wrong.
1 The Hook
A team building an online booking tool for a NZ vet clinic tests the obvious thing: a customer picks a pet, picks a time, confirms the appointment. It works. Demo looks great. Ship it.
Then real customers arrive. One tries to book when the clinic is fully booked — the system lets them, double-booking a slot. Another has their internet drop mid-booking and comes back to find the appointment half-created. A third tries to book for two pets in one visit, which the form silently mangles. None of these were tested, because the team only tested the one path where everything goes right.
The defects were never in the happy path. They were in the alternate routes (two pets, a different time) and the exception routes (clinic full, connection lost) — the paths real users actually hit. Testing only the success path is testing the demo, not the product. A use case is not one line; it is a tree of flows, and the bugs live on the branches nobody walked.
Here's what surprises most testers: the exception flows you get cut out of scope are almost always the ones that cost real money to fix in production. I've seen this play out on NZ government portals, banking apps, and e-commerce platforms — time pressure hits, the team agrees to defer "error handling testing," and six weeks later there's an incident where a user's payment was debited but the order never created because nobody tested the network-drop-mid-transaction flow. The counter-intuitive recommendation: don't fight for all your exception flows at once. Triage by consequence — what happens to a customer's money, data, or account if this exception fires unhandled? That single question gets you the two or three exception flows that matter, and those you defend hard.
2 The Rule
Every use case has three kinds of flow — the basic (happy) path, the valid alternate paths, and the exception paths where things go wrong — and you must derive test cases from all three, because real defects cluster on the alternate and exception branches the happy path never touches.
3 The Analogy
Planning a tramp on a Great Walk.
A sensible tramper on the Routeburn does not just plan the main track in good weather. They plan the main route (the basic flow), the alternate routes if a side track is the better option that day (alternate flows), and what to do if the river is up, the weather turns, or someone rolls an ankle (exception flows). The trampers who only plan the sunny-day main-track version are the ones the rescue helicopter goes looking for.
Use case testing is planning all the routes, not just the postcard one. The basic flow is the marked track on a fine day; the alternate flows are the valid detours; the exception flows are the river-in-flood, gear-failed contingencies. A use case test set that only covers the happy path is a tramp plan with no contingency — fine until something goes wrong, which it always does.
What it is
Use case testing treats the system from the user’s perspective. A use case describes a goal-driven interaction: who is doing it, what they want, and the sequence of steps to get there. Test cases are derived directly from these flows.
This technique is particularly valuable for integration and system testing — it tests how components interact to deliver user value, not just whether individual functions work.
The three flows
- Basic flow (happy path) — the most common, successful path through the use case. Test this first.
- Alternate flows — valid variations. A user pays with a different payment method; they log in via SSO instead of email/password.
- Exception flows — things that go wrong. Invalid data, timeout, payment declined, system unavailable. These flows matter as much as the happy path.
Worked example: checkout flow
| Flow type | Scenario | Test focus |
|---|---|---|
| Basic flow | User adds item, enters card details, completes purchase | Order confirmed, stock decremented, email sent |
| Alternate | User pays with saved card | Pre-filled payment, one-click confirm |
| Alternate | User applies discount code | Total recalculated, code validated |
| Exception | Card declined | Error message shown, order NOT created, no charge |
| Exception | Item goes out of stock during checkout | User informed, offered alternatives |
| Exception | Session times out mid-checkout | Cart preserved, user returned to checkout on login |
User stories vs use cases
In Agile teams, use cases are often replaced by user stories. The technique is the same — derive tests from the story’s acceptance criteria, happy path, and edge cases. ISTQB calls this user story testing, and it’s covered in the Agile Tester extension (CTFL-AT).
Good practice: for every user story, write at least one test for the basic flow, one for the most important alternate flow, and one for the most dangerous exception flow. Three tests minimum, derived directly from the story.
ISTQB mapping
| Ref | Topic | Level |
|---|---|---|
| 4.2.5 | Use Case Testing | CTFL Foundation |
| CTFL-AT | User Story Testing (Agile extension) | Foundation Agile |
Practice this technique: Try Junior Practice 10 — Multi-step form flow, Junior Practice 03 — GST & cart calculation.
4 Industry Reality
- Use cases rarely arrive complete. In practice, the "use case" handed to you is half a user story with one acceptance criterion and no flows documented at all. Senior testers write the missing flows themselves — collaborating with a BA or product owner to fill in the blanks — rather than waiting for a document that will never come.
- Exception flows get cut from scope. Under time pressure, teams routinely descope "error handling" testing. What senior testers do: triage exception flows by risk (what happens to a customer's money/data/account if this exception isn't handled?) and push back on the high-risk ones specifically, not generically.
- Legacy codebases have undocumented alternate flows. The system does something the original spec never mentioned — a hidden shortcut some users discovered years ago, an integration that half-works. You find these through exploratory testing and by asking support staff what they see every day.
- User stories aren't use cases. Most NZ agile teams write stories ("As a customer, I want to pay online") with no flows at all. A tester who can take that story and systematically derive the basic, alternate, and exception flows is adding genuine value the dev team usually hasn't done.
- The happy path is already tested by the developer. Developers run the basic flow to verify their work. The value a tester adds is the branches — so if you're spending most of your time verifying the happy path, you're partly duplicating effort and leaving the high-risk territory uncovered.
5 When to Use It — and When Not To
✓ Use it when
- You are testing end-to-end flows that cross system or module boundaries — payment, notification, stock — where the integration is the risk.
- You have a feature involving a multi-step user journey (checkout, booking, registration, loan application) where the sequence of steps matters.
- Requirements exist as use cases or user stories with acceptance criteria you can trace back to flows.
- You are doing system or integration testing and need to confirm the system delivers user value end to end, not just that individual units pass.
- There are known failure modes from production (support tickets, incident logs) that map to specific exception flows — use case testing gives you a structured way to cover them.
✗ Skip it when
- You are testing a single function or calculation in isolation — that is unit testing territory, where boundary value analysis or equivalence partitioning is more precise.
- There are no user-facing flows at all — a background batch job or data migration has no "user goal" to structure a use case around.
- The requirement is purely a data validation rule (e.g. a field must be between 1 and 100) — decision tables or boundary value analysis will give tighter coverage with less overhead.
- You have no requirements or specifications to work from and are operating in a pure discovery mode — exploratory testing is more efficient until you have enough information to define flows.
- Time is extremely tight and you have already covered the basic flow in a smoke test — use your remaining time on the highest-risk exception flows only, not re-deriving the full use case structure.
Context guide
How the right level of use case testing effort changes based on project context.
| Context | Priority | Why |
|---|---|---|
| Benefits NZ or FamiliesNZ citizen-facing portal (benefit application, child support, case management) | Essential | Multi-step flows with session timeouts, document uploads, and eligibility rules. Exception flows directly impact vulnerable New Zealanders — partial data loss or silent rejection is a welfare risk, not just a UX issue. |
| Harbour Bank or Harbour Bank NZ online banking feature (payments, transfers, account opening) | Essential | Money-in-flight transactions and reversibility rules mean exception flows (network drop mid-transfer, duplicate submit) carry direct financial risk. Every exception flow must have a defined, testable expected state. |
| TransitNZ digital licensing or vehicle registration renewal (RealMe-gated) | High | Identity verification (RealMe) is a shared dependency; an exception on that step kills every use case that starts with login. Cover RealMe failure as an exception flow in every journey it touches. |
| Spark or Pacific Air e-commerce checkout (booking, payment, confirmation email) | High | Payment gateway integrations create natural exception paths (decline, timeout, duplicate charge). Alternate flows (saved payment method, promo code, group booking) are frequent sources of production defects on high-volume commercial sites. |
| HealthNZ patient-facing appointment booking or results portal (Privacy Act 2020 obligations) | High | Patients viewing or managing health data have Privacy Act 2020 protections. Exception flows where data from a different patient is surfaced due to a session or identity error are high-severity and must be tested explicitly. |
| Internal Revenue NZ or CoverNZ back-office tool (analyst workflow, not citizen-facing) | Medium | Use case testing still applies to multi-step analyst workflows, but exception flow coverage can be lighter — trained staff can recover from errors that would strand a member of the public. Focus on data-integrity exceptions over UX ones. |
Trade-offs
What you gain and what you give up when you choose use case testing.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Tests end-to-end user value — each test scenario confirms the system delivers what a real user came to do, not just that a function returns a value. | Requires a defined user goal and flow — it cannot be applied to a function, API endpoint, or batch job that has no actor and no sequence of steps. | Testing a calculation rule or data validation in isolation — use boundary value analysis or equivalence partitioning for sharper input-focused coverage. |
| Naturally surfaces integration risk — a use case crosses module and service boundaries (identity, payment, notification), exercising the seams that unit tests never reach. | Test case count grows quickly — a single use case with three alternate and four exception flows generates eight or more tests; without triage by risk, scope can balloon. | Exploring unknown behaviour with no defined flows yet — use exploratory testing to charter the territory first, then codify findings as use case tests. |
| Directly traceable to requirements — each test maps back to a specific use case or user story, making coverage visible in reviews and audits (important for NZISM-aligned or ISO 27001 projects). | Does not give systematic input coverage — use case testing can miss boundary conditions within a flow; it needs to be paired with equivalence partitioning or boundary value analysis for complete coverage. | Testing a system with complex business rule combinations (e.g. KiwiSaver eligibility logic with many independent conditions) — use decision tables to cover rule combinations that use cases would miss. |
| Works in agile — user stories map directly to use cases; the technique requires no heavy documentation, just a named goal and the discipline to think through all three flow types. | Exception flows are routinely cut under pressure — without deliberate risk-based prioritisation, teams descope the flows that matter most, leaving dangerous unhandled states in production. | Testing security or access control logic — use security-focused techniques (misuse cases, privilege escalation scenarios) rather than standard use cases, which optimise for the legitimate user path. |
Enterprise reality
How Use Case Testing changes at 200–300-developer scale in NZ enterprise — manual walkthroughs give way to governed, tooled, cross-squad processes with real compliance consequences.
- Automation governance replaces ad-hoc coverage: At organisations like TechServNZ or CloudBooks, use case suites are maintained in a test management platform (Xray or Zephyr Scale inside Jira) and linked directly to epics. Individual testers no longer author use cases in isolation — a test architect owns the canonical suite and automation engineers convert high-frequency paths to Playwright or Cypress regression packs on every sprint boundary.
- Privacy Act 2020 and HISF mandate traceability: HealthNZ and Revenue NZ must demonstrate that every use case touching personal information has been tested and signed off before release. The Privacy Act 2020's principle of security safeguards (Principle 5) and the NZ Information Security Manual (NZISM) require documented evidence — use case IDs are mapped to controls and attached to change advisory board (CAB) approvals. Missing traceability means the CAB will block the release.
- Tooling at volume: Confluence wiki pages and spreadsheets collapse beyond 30 squads. Enterprise teams use Xray for Jira (test case versioning + requirement coverage matrices), TestRail for cross-project reporting, or Azure Test Plans when the stack is Microsoft. Use case IDs become the shared language between product, dev, QA, and risk — without a tool enforcing them, coverage reporting is fiction.
- Cross-squad coordination or the consequences are severe: At Harbour Bank, a payment flow can touch ten squads (accounts, payments, fraud, notifications, mobile, web, identity, core banking, compliance, and customer ops). A use case that isn't shared across those squads means each team tests its own slice and nobody tests the seam. In 2019 several NZ banks experienced significant outages tied to integration failures that unit tests missed entirely. At enterprise scale, the QA lead must own a cross-squad use case matrix and run integration test cycles — not leave it to each squad's definition of done.
◆ What I would do
Professional judgment — when to reach for use case testing, when to skip it, and what to watch for.
The bottom line: A use case is not a test — it’s a map. Write the map first (basic, alternate, exception), then decide which routes deserve a test based on consequence, not on which routes are easiest to walk. The flows that are hardest to test are usually the ones that break in production.
6 Best Practices
- ✓ Start with one clear goal statement per use case. "Customer completes online checkout" — not a list of features. If you can't state the user's goal in one sentence, you haven't defined the use case yet.
- ✓ Walk the basic flow end to end before writing alternate or exception tests. You need to understand the success path deeply before you can identify meaningful deviations from it.
- ✓ Name alternate and exception flows explicitly in your test documentation. Don't hide them as sub-steps of the basic flow. Label them: "Alternate: pays with saved card", "Exception: card declined". This makes gaps obvious in a review.
- ✓ Map each exception flow to its expected system behaviour, not just "an error occurs". "Error message shown" is not enough. What exact message? What state is the system in? Was any data persisted or partially committed?
- ✓ Prioritise exception flows by consequence, not frequency. The most dangerous exception is the one that corrupts data, charges a customer twice, or silently fails — not necessarily the one that happens most often.
- ✓ Ask what happens to in-flight transactions when an exception occurs. Session timeouts, network drops, and browser refreshes mid-flow are where the most serious data integrity bugs hide.
- ✓ Trace each test case back to a specific flow. If you can't say "this test covers the exception flow where X", it may not be a proper use case test — it may be a unit test or boundary test in disguise.
- ✓ Collaborate with support or customer success teams to find real exception flows. They know which exception paths real NZ customers actually hit — use that knowledge to prioritise your exception flow coverage.
- ✓ Cover at least three tests per use case as a floor: one basic, one alternate, one exception. In a resource-constrained sprint this is your minimum viable coverage — anything less and you've left an entire class of behaviour untested.
- ✓ Re-run your use case test set after any change to a shared flow step. If the login step changes, every use case that starts with login needs a regression check — use cases naturally surface cross-cutting regression risk.
7 Common Misconceptions
❌ Myth: Use case testing is just writing test cases from requirements — it's the same as any requirements-based testing.
Reality: Use case testing has a specific structure: a named user goal, a defined basic flow, and explicit alternate and exception flows branching from it. Generic requirements-based testing might cover individual requirements without ever representing a coherent user journey. The distinguishing feature of use case testing is that it stays anchored to what a real user is trying to do and traces every deviation from that goal systematically — not just checking that a list of requirements can be ticked off in isolation.
❌ Myth: If the happy path passes, the feature works.
Reality: The happy path is the one scenario developers explicitly designed and tested themselves. It is the least informative test a QA can run. The alternate flows (valid but different paths) and exception flows (things going wrong) are where real defects cluster in production. A feature that passes only the happy path has untested behaviour in every branch — which is the majority of the code that handles real-world conditions.
❌ Myth: In agile teams that use user stories, use case testing doesn't apply.
Reality: ISTQB explicitly covers user story testing (CTFL-AT) as the agile counterpart to use case testing — and the technique is identical. A user story defines a user goal, and you derive the basic flow from the acceptance criteria, alternate flows from valid variations in how the goal is achieved, and exception flows from what happens when the goal can't be completed normally. Agile doesn't eliminate the need for use case thinking; it just changes the format of the source document.
8 Now You Try
Three graded exercises — spot, fix, then build. Write your answer, run it for AI feedback, then compare to the model answer.
For a MetService weather-alert sign-up use case, classify each scenario below as basic flow, alternate flow, or exception flow, and give a one-line reason for each.
Show model answer
a) Email + region + confirm → subscription created — BASIC FLOW. The primary success path; test this first. b) Sign up via RealMe instead of email — ALTERNATE FLOW. A valid variation in how the user achieves the same goal; it still succeeds. c) Email already subscribed → "already signed up" — EXCEPTION FLOW. A condition that prevents the normal completion; must be handled gracefully (no duplicate, clear message). d) Notification service down → error shown — EXCEPTION FLOW. An external dependency failure; verify the user is told and no partial subscription is left behind. e) "All regions" instead of one — ALTERNATE FLOW. A valid input variation that still completes successfully, just with different data. The rule of thumb: basic = the main success path; alternate = a different but valid way to succeed; exception = something goes wrong and the goal cannot be met normally.
A tester wrote the test set below for a "transfer money between accounts" use case in a NZ banking app. It only covers happy paths and misses entire flow types. Rewrite it so it covers the basic flow plus at least one alternate and at least two exception flows.
TC1 — Transfer $50 between two of your own accounts — succeeds
TC2 — Transfer $100 between two of your own accounts — succeeds
TC3 — Transfer $200 between two of your own accounts — succeeds
Rewrite with full flow coverage:
Show model answer
Test set with full flow coverage: Basic flow: - Transfer a valid amount between two of your own accounts with sufficient funds — succeeds, both balances update, confirmation shown. Alternate flow: - Transfer to a saved payee (someone else's account) instead of your own — succeeds via a slightly different confirmation step. Exception flow 1: - Transfer more than the available balance — rejected, clear "insufficient funds" message, no money moved. Exception flow 2: - Connection drops after pressing confirm — verify the transfer is either fully completed or not done at all (no money debited without being credited), and the user sees an accurate status on return. What was wrong with the original set: - All three tests are the same flow with a different number — that is one flow tested three times, not three flows. It is closer to (weak) equivalence/boundary testing on the amount than use case testing. - It covers zero alternate flows (e.g. paying a third party, scheduling a future transfer). - It covers zero exception flows (insufficient funds, daily limit exceeded, dropped connection, invalid account number) — and exception flows are where the dangerous money-handling bugs live.
A NZ public library lets members reserve a book online and collect it from a chosen branch. Derive a use case test set: write one basic flow, two alternate flows, and three exception flows, with the expected result for each.
Show model answer
Use case: reserve a book online and collect from a chosen branch. Basic flow: - Member logs in, searches a title that is in stock, reserves it, picks their local branch — reservation confirmed, hold placed, member notified when ready. Alternate flows: - The chosen title is on loan, so the member joins the hold queue instead of getting an immediate reservation — confirmed with an estimated wait position. - The member collects from a different branch than their usual one (inter-branch transfer) — reservation succeeds, with a note that transfer may add a day or two. Exception flows: - The member has unpaid fines above the borrowing threshold — reservation blocked, clear message explaining why and how to pay. - The member already has the maximum number of items reserved — reservation refused with the limit explained. - The reserved book is reported lost/withdrawn before collection — member notified, reservation cancelled, alternative copies or titles suggested. A senior would test that an expired reservation that was never collected is released back to the shelf (a time-based exception flow), and that the "notify when ready" step actually fires.
Why teams fail here
- Treating a single end-to-end happy path test as “use case testing done” — one flow is a starting point, not a test set.
- Letting exception flows be descoped under time pressure without triaging by consequence — the dangerous ones (data corruption, double-charge, silent failure) get cut along with the trivial ones.
- Writing use case tests with no named actors, goals, or expected system states — “the user does a thing and it works” is a smoke test, not a use case test.
- Not re-running use case tests after changes to shared steps (login, payment, notification) — use cases are cross-cutting and a change to a shared step breaks multiple flows at once.
Key takeaway
A use case test set that only covers the happy path is a map with only one route drawn on it — the one where nothing goes wrong — and production users will find every unmarked road.
How this has changed
The field moved. Here is how Use Case Testing evolved from its origins to current practice.
Ivar Jacobson introduces use cases at Ericsson and publishes the methodology in 1987 (formalised in 1992). Use cases capture actor-system interactions to define functional requirements. They immediately suggest a test structure: test the main success scenario, then each alternative flow.
UML standardises use case diagrams. Rational Rose and other CASE tools make use case modelling mainstream in the late 1990s. Test teams derive test cases from use case documents as a standard practice in waterfall delivery.
Agile Manifesto challenges the use-case documentation model. User stories ("As a user, I want...") replace use cases in most agile teams. Use case testing survives in regulated domains and enterprise software where use cases serve as contractual specifications.
Business process modelling (BPMN) extends use case thinking to complex workflows. Use case testing is applied to BPMN process diagrams — particularly in ERP implementations where business processes are documented as formal use cases for UAT.
BDD scenarios (Given/When/Then) are effectively lightweight use cases with testable acceptance criteria. AI tools can generate test scenarios from user stories and use cases automatically. For complex NZ government and ERP systems, formal use case testing remains the primary UAT approach.
Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about Use Case Testing — and what strong answers look like.
How do you derive test cases from a use case document?
Strong answer: From each use case I extract: (1) the main success scenario — one test case that follows the happy path from start to finish; (2) each alternative flow — a test case for each branch point where the flow diverges; (3) exception flows — test cases for each error condition documented; and (4) pre and post condition verification — tests that confirm the system is in the correct state before and after. For a "Process benefit payment" use case, the main scenario tests a successful payment; alternative flows test delayed payments and partial payments; exception flows test insufficient funds, invalid account number, and system unavailability; post conditions verify the payment record is created and the recipient is notified.
Junior/Mid
A 200-page use case specification has been handed to you three days before UAT begins. How do you prioritise?
Strong answer: I risk-rank the use cases: which use cases cover the most frequently used functionality? Which cover irreversible operations (payment processing, account closure)? Which have the most complex alternative flows? I focus my first day on must-test use cases (critical path, irreversible operations) and allocate the remaining time across high-risk use cases in order of priority. I document which use cases were not tested and why — the decision to test incompletely under time pressure should be explicit and visible to the product owner. I also flag that three days before UAT is too late to receive a 200-page specification — that is a process issue to address before the next release.
Mid/Senior
Q1: Why is testing only the happy path of a use case effectively "testing the demo, not the product"?
Because real defects cluster on the alternate and exception branches — the paths real users actually hit when they do something valid-but-different or when something goes wrong. The happy path is the path everyone designed for; the branches nobody walked are where the bugs are.
Q2: What is the difference between an alternate flow and an exception flow?
An alternate flow is a valid, different way the user still achieves the goal (paying with a different method, choosing a different option) — it succeeds. An exception flow is where something goes wrong and the goal cannot be met normally (declined payment, timeout, blocked by a rule) — it must be handled gracefully rather than left to fail silently.
Q3: Why is use case testing especially valuable for integration and system testing?
Because it tests how components interact to deliver user value end to end, not just whether individual functions work in isolation. A use case crosses module boundaries (payment, stock, notification), so testing the flow exercises the integrations a unit test would never touch.
Q4: In agile teams, what replaces the formal use case, and is the technique any different?
User stories replace use cases, and ISTQB calls deriving tests from them user story testing (covered in CTFL-AT). The technique is the same: derive tests from the story's acceptance criteria, its happy path, its valid variations, and its edge/exception cases.
Q5: What is the minimum sensible test coverage for a single user story?
At least one test for the basic flow, one for the most important alternate flow, and one for the most dangerous exception flow — three tests minimum, all derived directly from the story. Anything less leaves a whole class of behaviour untested.
Q6: Your team is testing a new Benefits NZ benefit application portal. A colleague says "we've verified the basic flow end-to-end, so we're done with use case testing for this sprint." What would you push back on, and which specific flows would you prioritise next?
The basic flow is the one path the developer already verified — a tester's real value lies in the branches. For a Benefits NZ benefit portal the highest-risk exception flows are: an applicant submitting when already receiving that benefit (duplicate application handling), a session timeout mid-application (is partial data saved or lost, and does the applicant know?), and an uploaded supporting document failing the file-size or format check (is the error actionable?). The most important alternate flow is a joint application by a couple, which exercises different eligibility logic. Skipping these leaves the scenarios that cause real harm to real New Zealanders untested.
Q7: What is the key difference between use case testing and decision table testing, and how would you decide which to apply when testing a KiwiSaver early-withdrawal eligibility check?
Use case testing is structured around a user's goal and traces all the paths — basic, alternate, and exception — through the system. Decision table testing is structured around combinations of conditions and rules, with no concern for sequence or user journey. For a KiwiSaver early-withdrawal eligibility check the conditions (financial hardship, serious illness, first home, permanent emigration) and their rule combinations suit a decision table, because eligibility is determined by a set of independent inputs, not a multi-step user journey. Use case testing would be the right tool for testing the end-to-end withdrawal application flow — from identity verification through document upload, eligibility decision, and payment — where the sequence of steps and the exception paths (document rejected, bank account invalid) are the risk.
Q8: A developer says "I don't need use case tests for this batch job that nightly reconciles CoverNZ claim payments — it has no user-facing screens." What is the problem with applying use case testing here, and what technique would be more appropriate?
Use case testing requires a user goal — a specific actor trying to achieve something through a sequence of interactions. A nightly batch reconciliation job has no user, no goal-driven interaction, and no alternate or exception flows in the use-case sense. Applying use case testing forces an artificial structure where none belongs. More appropriate techniques are: decision tables or equivalence partitioning for the payment-matching rules, and checklist-based or boundary value analysis for the data validation. If an operator can trigger or monitor the batch, you might use a thin use case for that operator journey, but the batch logic itself is not a candidate.
Q9: In an interview, you are asked how you would derive test cases for an TransitNZ warrant of fitness (WOF) booking feature. A panel member then says "just test that a booking can be created — that covers it." What is wrong with this, and how do you explain the full use case structure your test set would cover?
Testing only that "a booking can be created" is testing a single basic flow and leaving the alternate and exception branches entirely uncovered — the same trap as testing only the happy path. A complete use case test set for WOF booking would include: the basic flow (vehicle owner logs in via RealMe, selects a testing station, picks a time, confirms — booking created and confirmation sent); alternate flows (books for a vehicle registered to a business rather than an individual, or rebooks after cancelling a prior appointment); and exception flows (the selected time slot fills up between viewing and confirming, the vehicle's registration is expired and the system should block or warn, and a payment failure mid-booking). The panel member's scope leaves data integrity bugs, business-rule enforcement, and real NZ driver scenarios entirely untested.
Try It — Classify the flows
A NZ government services portal lets citizens renew their driver licence online. Six test scenarios are listed below. Classify each as Basic flow, Alternate flow, or Exception flow.
| Scenario | Your classification |
|---|---|
| User logs in with RealMe, passes vision check, pays $49.10, licence renewed successfully | |
| User logs in with RealMe, but their licence has already expired more than 1 year ago — portal blocks renewal and directs them to TransitNZ | |
| User pays using credit card instead of internet banking | |
| Payment gateway times out — user session preserved, error displayed, no charge made | |
| User has an address outside Auckland, Wellington, and Christchurch — selects PostNZ rural delivery option | |
| RealMe identity verification fails — user cannot proceed, shown support contact |
Answers
| Scenario | Flow type | Why |
|---|---|---|
| RealMe login → vision check → pay → renewed | Basic flow | The primary success path. Test this first. |
| Licence expired >1 year — blocked | Exception flow | A system rule prevents completion. Dangerous if not handled — user is told nothing actionable. |
| Pays by credit card instead of internet banking | Alternate flow | A valid variation in payment method. Still succeeds, just differently. |
| Payment gateway timeout | Exception flow | External dependency failure. Must verify no double-charge and session recovery. |
| Rural NZ delivery option | Alternate flow | Valid path, different delivery address logic. Common NZ edge case. |
| RealMe verification fails | Exception flow | Identity provider error. Must not silently fail — user needs clear guidance. |
Senior engineer insight
The thing that changed how I think about use case testing: the use case is not the test — it’s the map. Most testers write one test per use case and call it done. Senior testers read the use case, identify every decision point where the flow can branch, and build a test for each branch. That reframe turns three test cases into twelve, and the twelve actually find bugs. Every time I’ve seen a use case test set that’s just “happy path passes” repeated with different data, the high-severity defects have been hiding on an alternate or exception branch nobody wrote a test for.
Most common mistake: treating the basic flow as sufficient coverage because it represents what the system is supposed to do — without realising it’s also the path least likely to reveal anything the developer hasn’t already verified themselves.
From the field
On a NZ government digital services project, the team had user stories with acceptance criteria, sprint reviews showing the happy path working, and sign-off from product. What they didn’t have: tests for any exception flow. When the service went live, the first call to the support desk was a citizen who’d hit a session timeout mid-application — their partial form data was lost with no recovery path and no explanation. The second was a user whose uploaded identity document was silently rejected by the file validation service, but the portal gave no feedback. Both exception flows were “out of scope for MVP.” The lesson that generalises: in any multi-step citizen-facing flow, the exception flows — timeout, validation failure, third-party service error — are the scenarios that cause real distress and real support cost. Deferring them is not a technical risk; it’s a user experience debt that always comes due.