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.
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.
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 NZTA | |
| 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 NZ Post 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. |