Model-Based Testing
Instead of writing test cases by hand, you build a model of the system's behaviour — a state machine, a decision table, or a flowchart — and generate test cases from it. The model finds paths your intuition would miss.
1 The Hook
A NZ insurance company has a claims workflow with 14 states (submitted, under review, approved, declined, appealed, and so on) and 23 transitions between them. A tester writes test cases manually and covers 9 states and 15 transitions — the obvious paths. A colleague builds a state machine model and generates 34 test cases. 7 of those cover transitions the manual tester missed entirely.
Two of those 7 find defects. A claim in "Appealed" state can be directly transitioned to "Closed" by an admin user, bypassing the "Re-reviewed" step required by FMA compliance rules. The manual tester's intuition never reached that path. The model did.
2 The Rule
Build a model of the system's behaviour before writing test cases. The model reveals paths, states, and transitions that intuitive test design routinely misses — especially in regulatory workflows where every transition matters.
3 The Analogy
Model-based testing is like using a map instead of wandering around a city.
You can wander and find some streets. With a map, you see all the streets — including the ones you'd never have stumbled on — and you can plan the most efficient route to cover them all. The manual tester wanders; the model-based tester uses a map. In a complex regulatory workflow, the streets you wander past are the ones that contain compliance defects.
4 Watch Me Do It
State transition model for an NZ KiwiSaver enrolment workflow.
States:
Transitions (events): enrol(), employerConfirms(), irdValidates(), suspend(), resume(), optOut()
Test cases derived from the model:
| Test case | Path / Transition | Expected result | Type |
|---|---|---|---|
| TC-01 | Not Enrolled → Application Submitted → Employer Confirmed → IRD Validated → Active | Account active with correct contribution rate | Happy path |
| TC-02 | Active → optOut() | Status changes to Opted Out; no further contributions | Valid transition |
| TC-03 | Application Submitted → optOut() (attempted) | System blocks opt-out; enrolment not yet active | Invalid transition |
| TC-04 | Active → suspend() → resume() | Contributions resume correctly after suspension | Round-trip |
| TC-05 | Opted Out → enrol() within 12 months | System applies KiwiSaver re-enrolment rules (employer must re-enrol) | Boundary + compliance |
| TC-06 | IRD Validated → suspend() (attempted) | System blocks — suspend only valid from Active state | Invalid transition |
5 When to Use It
- Complex state machines — claims workflows, application processes, subscription lifecycles
- When manual test case design feels like it's missing paths (it probably is)
- When regulatory compliance requires provable coverage of all decision paths — FMA, RBNZ, Health and Disability Commissioner
- When the spec is a diagram (UML, Visio, Miro) — the model is already there, derive from it
- When testing a new feature that replaces an existing workflow — use the old model as a baseline for regression
6 Common Mistakes
❌ I used to think: building a model is extra work on top of writing test cases.
Actually: building the model replaces the intuitive test design step with a systematic one. You spend the same time — but you end up with a complete list of paths instead of a partial one. The model is the test design; the test cases are derived from it.
❌ I used to think: state machines only apply to UI workflows.
Actually: any system with states and transitions benefits from model-based testing: APIs with status fields, database records with lifecycle stages, background jobs with queued/running/failed states, and IoT devices with power states. If it has states, it has a model.
❌ I used to think: the model needs to be perfect before I can derive test cases.
Actually: an imperfect model is better than no model. Start with the states you know, draw the transitions you can see, then derive test cases. You'll discover missing states and invalid transitions during the exercise — that discovery is the point. Update the model as you learn.
7 Now You Try
Build a state machine model for an NZ student loan application workflow. The loan can be in these states: Not Applied, Application In Progress, Submitted, Under Assessment, Approved, Declined, Appealed, Disbursed. Define the transitions between states, then derive 5 test cases — at least 2 must test invalid transitions that should be blocked.
8 Self-Check
Click each question to reveal the answer.
Q1: What is the key advantage of deriving test cases from a model versus writing them intuitively?
The model reveals all states and all transitions — including the ones testers never intuitively think to test. Invalid transitions (paths that should be blocked) and boundary transitions (paths that only apply under specific conditions) are only visible when you enumerate all possible state changes from the model. Intuitive design reliably misses 20–40% of transitions.
Q2: What is an "invalid transition" and why must it be tested?
An invalid transition is a state change that should be blocked by the system — for example, moving a loan application from "Declined" directly to "Disbursed" without going through "Appealed" and "Approved". These must be tested because developers often implement the happy path correctly but leave invalid transitions accidentally open. In regulatory systems, an open invalid transition is a compliance defect.
Q3: When is a decision table a better model than a state machine?
Use a decision table when the system makes a decision based on combinations of multiple input conditions (rather than sequential state changes). If the question is "which rule fires when?" — use a decision table. If the question is "what state does the system go to next?" — use a state machine. Many workflows need both.
9 ISTQB Mapping
ISTQB CTAL-TA v3.1.2, Section 3.5 — Model-based testing: state transition models, decision tables, and use case models as sources for test case derivation. Advanced testers are expected to build models from specifications and derive test cases with provable coverage.
Related technique: State Transition Testing (CTFL Foundation level covers basic state tables; this page covers model-derived test case generation at Advanced level).