Q13 of 38 · Test design
How do you derive test cases from a use case diagram?
Short answer
Short answer: For each use case, identify the actors, main success scenario, alternative flows, and exception flows. Each flow becomes one or more test cases. Edge data and boundary conditions come from EP/BVA on the inputs the use case mentions.
Detail
Use case diagrams describe interactions between actors and the system at a behaviour level. They're a reasonable starting point for test design, but the diagram alone isn't enough — you need the use case specification (text describing main flow + alternatives + exceptions) to derive concrete tests.
The process:
- Identify the actor. Each use case has one or more actors (user, system, external service). Tests are designed per actor's perspective.
- Identify flows: main success scenario (the typical successful interaction), alternative flows (variations that still succeed), exception flows (what happens when something fails).
- Convert each flow to test cases: main success — 1–2 tests; each alternative — 1+ test; each exception — 1+ test, including the recovery path if any.
- Layer in input-level test design: for inputs mentioned in the use case, apply EP/BVA. For combinations, decision tables or pairwise as appropriate.
- Add cross-cutting tests: authorisation (does the actor have permission?), audit trail (is the action logged?), data integrity (is the resulting state consistent?), concurrent / repeated execution (idempotency, race conditions).
Worked example: a "Place order" use case with actor registered customer. Main flow: customer adds items, reviews cart, confirms shipping, pays, sees confirmation. Alternative flows: customer applies coupon; customer chooses different shipping address. Exception flows: payment declined, item out of stock mid-flow, session expires during payment.
Test cases derived: TC1 main flow happy path; TC2 main flow with valid coupon; TC3 with secondary address; TC4 payment declined → recovery path; TC5 out-of-stock during payment → user is told, given options; TC6 session expired during payment → safe behaviour, no double-charge; TC7 two tabs both placing the order → idempotency check.
The senior signal: not just deriving the obvious flows but also stress-testing the cross-cutting concerns (idempotency, audit, authorisation) that use case diagrams typically don't show.