Use Case Testing
Derive test cases from real user goals. Test the happy path, the valid detours, and the things that go wrong — because users do all three.
1 The Hook — Why This Matters
An NZ government agency launched a new service that required users to log in via RealMe. The login screen passed every test: valid username and password worked, error messages displayed correctly, and session timeouts behaved as expected.
On launch day, over 2,000 users couldn't complete their applications. Why? The testers had only tested the main flow: navigate to site, enter RealMe credentials, authenticate, access dashboard. Nobody had tested what happened when a user selected "Remember Me" — a simple alternate flow. The checkbox stored credentials in an incompatible format, corrupting the local browser storage for anyone who used it. The site crashed on the next visit.
The fix took 36 hours and required an emergency patch during business hours. One missed alternate flow. One major outage. Use case testing would have caught it because it forces you to test every path a user might take — not just the obvious one.
2 The Rule — The One-Sentence Version
Derive test cases from use cases. Test the user's goal end-to-end.
A use case isn't a screen or a button — it's a user's goal. The main flow gets them there smoothly. Alternate flows get them there via a different route. Exception flows stop them, and the system must handle that gracefully. If you only test the main flow, you haven't tested the use case.
3 The Analogy — Think Of It Like...
An airport security checkpoint.
The main flow is straightforward: passenger walks through, bag goes through X-ray, passenger collects bag, walks to gate. You would test this first.
But what about the alternate flows? A passenger has a pacemaker and can't go through the metal detector — they need a manual pat-down. A passenger has a laptop — it must come out of the bag. A family with a stroller — they use a wider gate.
Then the exception flows: the metal detector alarms, the X-ray spots a suspicious item, the passenger's boarding pass is for yesterday's flight. Each of these needs a defined, tested response. If you only tested the main flow, the checkpoint would collapse on day one.
4 Watch Me Do It — Step by Step
Here is a real NZ example using RealMe login. Follow these steps every time you have a use case or user story to test.
Scenario: A citizen wants to access an NZ government service using RealMe authentication. The use case states the actor, goal, pre-conditions, and post-conditions.
- Identify the use cases and actors The actor is the NZ citizen. The use case is "Authenticate via RealMe to access government service." Identify who triggers the use case and what value they receive.
- Define pre-conditions and post-conditions Pre-condition: citizen has a valid RealMe account. Post-condition: citizen is authenticated and on the service dashboard. Every test must start with pre-conditions true and end by verifying post-conditions.
-
Map the three flows
- Main Flow (happy path): navigate to service → click RealMe login → enter credentials → authenticate → land on dashboard
- Alternate Flows (valid variants): select "Remember Me", click "Forgot Password", use "Verify with mobile app instead of password"
- Exception Flows (errors): invalid credentials, account locked, expired password, RealMe service down
- Derive at least one test case per flow Every flow needs a test. Don't combine them. An alternate flow test must start from the trigger and end at the post-condition, just like the main flow.
- Execute end-to-end Use case tests are not unit tests. They start at the trigger and end at the post-condition, cutting across UI, business logic, database, and external APIs. Execute the full workflow every time.
| Flow type | Test case | Expected result |
|---|---|---|
| Main flow | Navigate to service, click RealMe, enter valid credentials, authenticate | Dashboard loads, user name displayed, session active |
| Alternate | Main flow + select "Remember Me" before authenticating | Dashboard loads, browser stores token, next login is faster |
| Alternate | Click "Forgot Password" on RealMe screen, complete reset, return to service | Password reset email sent, user can set new password and return to login |
| Exception | Enter invalid credentials three times | Account temporarily locked, clear message with unlock instructions, service not accessed |
| Exception | Enter credentials for expired password account | Redirected to password expiry flow, forced to update before dashboard access |
| Exception | RealMe service returns 503 during authentication | Graceful error message, no crash, user can retry, application data intact |
5 The Decision Tool — When to Use It
✅ Use use case testing when...
- You have documented use cases, user stories, or BRDs
- You are testing system-level or integration-level behaviour
- The feature has clear user goals and multiple paths
- You need to verify end-to-end flows, not isolated functions
- You are preparing acceptance tests with stakeholders
- You need to validate pre-conditions and post-conditions
❌ Don't rely on it alone when...
- You need exhaustive input validation (pair with EP/BVA)
- There are no use cases or user stories available
- The system has complex business rule interactions (add decision tables)
- You need to test non-functional requirements (performance, security)
- The spec is incomplete or ambiguous (add exploratory testing)
Before you apply use case testing, ask:
- Do you have documented use cases or user stories?
- Does your app have complex workflows or multiple user paths?
- Have you identified all main, alternate, and exception flows?
6 Common Mistakes — Don't Do This
🚫 Testing only the main flow
I used to think: If the happy path works, the feature is ready to ship.
Actually: The happy path is what developers test first. It almost always works. The bugs hide in alternate and exception flows — the paths users actually hit when real life gets messy. Make it a rule: no feature is "tested" until at least one alternate and one exception flow have passed.
🚫 Assuming the use case document is perfect
I used to think: The use case document is the source of truth, so I just follow it.
Actually: Use case documents are written by humans who make assumptions. They often skip exception flows entirely because the author didn't imagine them. If you only test what's documented, you test the author's imagination, not the system. Treat the document as a starting point, not a checklist.
🚫 Writing use case tests as isolated unit tests
I used to think: Use case tests are the same as unit tests — I can just test each step in isolation.
Actually: Use case testing is an end-to-end technique. Testing login in isolation, then testing dashboard in isolation, misses the bugs that appear when the two interact — like a session cookie that works for login but breaks during form submission. Execute the full workflow from trigger to post-condition.
When use case testing fails
Missing alternate flows (what if the user cancels? changes their mind? hits Back?) or exception flows (payment fails, timeout, network error). Also, use case documents that aren't validated against real user behaviour miss the paths that matter most in production.
7 Now You Try — E-commerce Checkout
Scenario: A registered customer wants to buy a pair of shoes on an NZ online store.
- Actor: Registered customer
- Pre-condition: Customer is logged in, cart has at least one item
- Post-condition: Order placed, confirmation displayed, email sent
- Main flow: Review cart → Enter shipping address → Select standard shipping → Enter payment details → Confirm order → See confirmation
Your task: Write one alternate flow test case and two exception flow test cases with their expected results.
Model answer — e-commerce checkout flows:
| Flow type | Test case | Expected result |
|---|---|---|
| Alternate | Customer applies a valid discount code during checkout | Total recalculated, discount applied, order proceeds at reduced price, confirmation shows discount |
| Alternate | Customer selects "pick up in store" instead of shipping | Shipping address step skipped, store location selected, confirmation shows pickup location |
| Exception | Customer's credit card is declined | Order NOT created, no charge applied, clear error message shown, cart preserved, customer can retry |
| Exception | Item goes out of stock while customer is on the payment page | Customer informed before charge, offered waitlist or similar items, order NOT placed |
| Exception | Session times out during checkout | User redirected to login, cart contents preserved, returned to checkout step after authentication |
Key insight: Exception flows must protect data (no charge), preserve state (cart kept), and guide the user (clear next step). Getting 3–4 of these is excellent for a junior tester.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Q1. What are the three flow types in use case testing?
Main Flow (happy path): the standard scenario where the user achieves their goal smoothly. Alternate Flows: valid variations where the user still achieves the goal but via a different route. Exception Flows: error situations that prevent the goal from being achieved — the system must handle them safely and gracefully.
Q2. What is the difference between an alternate flow and an exception flow?
Alternate flows are valid variations where the user still achieves their goal — they just take a different path (e.g., applying a discount code, choosing in-store pickup). Exception flows are error situations that prevent the goal from being achieved — the system must handle them safely (e.g., payment declined, item out of stock, session timeout).
Q3. Why is use case testing considered an end-to-end technique rather than a unit testing technique?
Because it tests the complete interaction from trigger to post-condition, cutting across multiple components (UI, business logic, database, external APIs). Unit tests verify isolated functions; use case tests verify that those functions work together to deliver user value. A session cookie might pass a login unit test but break during checkout — only an end-to-end use case test catches that.
9 Interview Prep — Know These Cold
These are questions Kiwi employers actually ask junior testers. Have an answer ready.
Q1. What is use case testing and when would you use it?
Use case testing is a black-box technique that derives test cases from use cases or user stories. It tests the user's goal end-to-end through main flows, alternate flows, and exception flows. Use it when you have documented requirements with clear user goals and need to verify system-level or integration-level behaviour.
Q2. What are the three flow types in use case testing?
Main Flow (happy path) — the standard scenario. Alternate Flows — valid variations that still achieve the goal. Exception Flows — error situations that prevent the goal and require safe handling.
Q3. How many test cases should you derive from a use case?
At minimum, one per flow type: one main flow, at least one alternate flow, and at least one exception flow. In practice, a single use case often yields 5–8 test cases because there are multiple alternate and exception paths. The rule is: if the flow is different, it needs its own test case.
10 Link to Reference
Want the full theory, ISTQB syllabus mapping, and advanced worksheets for complex use cases?
→ Use Case Testing — Full Library Reference
Includes the formal ISTQB definition, deep dives on pre/post-conditions, and combined technique worksheets for real-world BRDs.
11 Next Step
You now know how to derive test cases from use cases and test end-to-end user goals. The next skill is finding bugs when there is no specification at all — using intuition and experience.