Use Case Testing
Test what users actually do, not just what the buttons do. Learn how to map goal-driven interactions — the happy path, the alternative routes, and the things that go horribly wrong.
1 The Hook — The "Nobody Does That" Bug
A developer once told a tester at a NZ bank: "You don't need to test that scenario — nobody would ever try to withdraw money while their account closure is pending."
The tester did it anyway. They found that if a user initiated a withdrawal between the time they clicked "Close Account" and the time the server processed it, they could double-dip their balance. The system worked fine "button by button," but failed during a specific user journey. Use Case Testing stops you from testing buttons and starts you testing Behaviors.
2 The Rule — The Three Flows
Identify the Basic Flow (Happy Path), then find every Alternate Path and Exception Flow.
- Basic Flow: The primary success path (e.g., User logs in, pays, logs out).
- Alternate Flow: A valid variation (e.g., User pays by Credit Card instead of PayPal).
- Exception Flow: Things that go wrong (e.g., Card declined, Timeout).
3 The Analogy — Choose Your Own Adventure
The "Choose Your Own Adventure" Book.
Think of Use Case testing like a gamebook. Page 1: "You enter the cave." (Basic Flow). Page 12: "You use a flashlight to enter." (Alternate Flow). Page 45: "You trip and fall." (Exception Flow). A good tester doesn't just read the happy ending; they explore every page to make sure there are no dead-ends or loops that trap the reader.
4 Watch Me Do It — KiwiSaver Withdrawal
Scenario: A user wants a KiwiSaver "Significant Financial Hardship" withdrawal. This is a complex NZ-specific journey.
| Flow Type | Description | Test Focus |
|---|---|---|
| Basic Flow | User submits evidence, app is verified, funds paid. | Payment logic, success notifications. |
| Alternate | User has no proof of ID; uses RealMe to verify. | Integration between system and RealMe. |
| Alternate | User requests partial withdrawal instead of full. | Calculations, tax withholding rules. |
| Exception | User's evidence documents are corrupt or missing. | Error messages, "Draft" preservation. |
| Exception | User is not a resident (Ineligible). | Rule engine, rejection letter generation. |
5 Decision Tool — Use Case vs. User Story
In modern Agile teams, you'll often see User Stories. Here's how they compare:
Use Cases (Traditional)
- Detailed steps (1, 2, 3).
- Focus on System Interaction.
- Best for: Complex insurance/finance.
User Stories (Agile)
- Goal-focused (As a..., I want...).
- Focus on User Value.
- Best for: Fast-moving web apps.
6 Common Mistakes
🚫 Only testing the "Happy Path"
I used to think: If it works when everything is perfect, I'm done.
Actually: Industry stats show that 70% of production bugs occur in the "Exception Flows." If you only test success, you aren't testing the system's resilience.
🚫 Testing every single field again
I used to think: I should do BVA and EP on every field during the Use Case.
Actually: Use Case testing is "Integration Level." Assume the fields work (you already tested them). Focus on the Flow and the Handoff between pages.
7 Now You Try — Driver Licence Renewal
Scenario: Renewing a licence on the NZTA portal. Classify these three scenarios:
Scenario A: User logs in, pays $49.10, renewed.
Basic Flow
Scenario B: User pays by Credit Card instead of Poli.
Alternate Flow
Scenario C: User's eyesight check fails at AA centre.
Exception Flow
Scenario D: Payment gateway times out mid-request.
Exception Flow
8 Self-Check
Q1. Why is Use Case testing considered "Black Box"?
Because we don't care about the code inside. We only care about the Inputs (User Actions) and Outputs (System Response) relative to a specific goal.
Q2. What is an "Actor" in Use Case terminology?
An Actor is anyone or anything that interacts with the system. It could be a Human User, or another system (like the Payment Gateway).
9 Interview Prep
"How do you prioritize test cases when given a complex user journey?"
Answer: "I start with the Basic Flow to confirm the feature delivers core value. Then, I prioritize Exception Flows based on risk — focusing on paths that could lead to data loss or security breaches. Finally, I cover Alternate Flows to ensure flexibility for different user preferences."
10 Next Step
You've mastered documented testing. Now, let's look at how to test when there are No Requirements. Next: Exploratory Testing.