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.
Every team I have worked with builds the model, tests the happy path, and calls it done. The defects are almost never there. They live in the invalid transitions — the paths the model says must be blocked. In a KiwiSaver fund-switch project I reviewed, every valid transition passed. Then we tested "initiate switch while a previous switch is pending settlement" and the API accepted it silently. No error. No rejection. A compliance incident waiting to happen. The golden rule: for every valid transition you test, you must also test at least one transition out of each state that should be rejected. If your test suite has no cases where the expected result is "system blocks this", your model coverage is incomplete regardless of what your coverage metric says.
Senior engineer insight
The most revealing moment in model-based testing isn't when you find a defect on an invalid transition — it's when you show the developer the model and they say "we never implemented that state." Building the model before the sprint starts turns ambiguous requirements into explicit decisions. That shift in timing is what MBT is really about.
Most common mistake: teams build the model, test every valid transition with care, then skip the invalid ones because they feel like edge cases. In NZ financial services, invalid transitions are where compliance breaches live — not edge cases, primary risks.
From the field
A Wellington-based government agency was migrating a legacy case management system handling complex multi-party approval workflows — the kind where a single case could move through seven different teams before resolution. The testers inherited a 40-page Word document as the "spec" and were told the new system had to match the old behaviour exactly. We spent three days building a state machine in draw.io from those 40 pages. On day two we found three states in the document that contradicted each other, and one transition that was physically impossible given the guard conditions. The BA had written it that way four years earlier and no one had noticed — because manual test design had never forced anyone to enumerate every path. The model found a design defect before a single line of new code was tested. That's the lesson: for complex NZ government workflow systems, building the model is not a testing activity — it's a requirements validation activity with testing as a side effect.
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 → Revenue NZ 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 | Revenue NZ 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 Industry Reality
- The spec is never a clean state machine. Real NZ projects hand you a mix of Confluence docs, Jira tickets, and a Miro board that disagrees with itself. Your first job is to build the model from these fragments — and the act of building it surfaces contradictions that no one else has noticed.
- Stakeholders resist the upfront investment. Developers and PMs see model-building as "extra work before real testing". Senior testers know it's the opposite — it cuts the total time by removing the re-run cycle when missed paths are discovered late. Frame it as risk reduction, not overhead.
- Legacy systems have undocumented states. In older NZ government platforms (Revenue NZ legacy, DHB patient management systems), states exist in production that aren't in any spec. You discover them by reading database enums, talking to the oldest developer on the team, and running exploratory sessions against production data exports.
- Tooling is usually just a whiteboard. Enterprise MBT tools (Conformiq, GraphWalker) are rare in NZ. In practice, senior testers draw the model in Miro or draw.io, export it as a matrix, and derive test cases manually or with a simple script. Don't wait for tooling — a model in Miro is enough.
- Regulatory auditors want evidence of coverage. FMA, RBNZ, and Privacy Commissioner audits increasingly ask "how do you know your tests cover all paths?" A state transition matrix with traceability from model to test cases is a direct answer. Teams without a model have no good answer.
8 When to Use It — and When Not To
✓ Use it when
- The feature has 5+ distinct states and multiple transition events (claims, loans, enrolments, subscriptions)
- Regulatory compliance requires you to demonstrate provable path coverage — FMA, RBNZ, NZ Privacy Act data lifecycle
- The specification is already a diagram (UML, swimlane, Miro flowchart) — the model is already half-built
- The team has had production defects caused by invalid state transitions reaching an incorrect state
- You are testing a replacement system and need to verify the new system honours all the old system's transition rules
✗ Skip it when
- The feature is essentially stateless — a simple calculation, a read-only report, a search filter with no side effects
- The system is well-understood and has been stable for years — the coverage already exists in a mature regression suite
- You're under severe time pressure and the workflow has only 2–3 states — equivalence partitioning or a checklist is faster
- The requirements are too vague to model — spending time building a model from guesses creates false confidence; clarify first
- The feature is throwaway or experimental (A/B test, prototype) — the investment doesn't justify it
Context guide
How the right level of model-based testing effort changes based on project context.
| Context | Priority | Why |
|---|---|---|
| CoverNZ injury claims portal — multi-state workflow with FMA-adjacent compliance obligations | Essential | Each claim state change has regulatory significance; invalid transitions can constitute a compliance breach. Model-based testing provides the state transition traceability auditors require. |
| Revenue NZ KiwiSaver fund-switch API — backend state machine handling settlement periods | Essential | Fund-switch concurrency defects (initiating a switch while one is pending) are invisible to happy-path tests. A state machine model makes every invalid transition explicit and forces the team to test API-level blocking, not just UI-level error messages. |
| Spark broadband provisioning workflow — 6 states, 3 integrations with Chorus and Tuatahi | High use | Integration points between internal states and external partner states create hidden invalid transitions. Modelling the combined workflow surfaces integration seams that are impossible to see when testing each system in isolation. |
| Pacific Air check-in flow — seat selection, baggage, upgrade states on a mature stable platform | Medium | A mature regression suite already covers most transitions. Use MBT selectively for new or changed transitions introduced each release, rather than rebuilding a full model every sprint. Coverage already exists; focus effort on what changed. |
| Harbour Bank mobile banking — read-only balance summary screen, no state changes initiated | Low | A display-only feature with no transitions to model. Equivalence partitioning on the data ranges is sufficient. Applying MBT here adds overhead with no coverage benefit — save the technique for features that actually have state. |
| TransitNZ RUC (Road User Charges) licence purchase — stateless calculation followed by a payment step | Low | The calculation logic is stateless; a decision table covers the business rules (vehicle class × distance × rate). The payment step is a single transition. Use decision table testing for the calculation; reserve MBT for a full licence lifecycle if one exists. |
Trade-offs
What you gain and what you give up when you choose model-based testing.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Forces all states and transitions to be explicitly named before tests are written — surfaces missing requirements and design contradictions early, before development begins. | Upfront modelling investment (half a day to a full day) can feel like overhead on short sprints or under-resourced teams. Stakeholders may push back unless the return on investment is made concrete. | The feature has fewer than 3 states and the transitions are obvious — a simple checklist or exploratory charter is faster and sufficient. |
| Produces traceable coverage evidence — each test case maps to a specific transition ID, directly satisfying regulatory audit requirements from FMA, RBNZ, and the Privacy Commissioner. | The model must be kept in sync with the implementation. A stale model is worse than no model — it generates test cases for behaviour that no longer exists and creates false confidence in coverage metrics. | The system changes rapidly every sprint and there is no dedicated owner to maintain the model. Risk-based testing with a prioritised regression list may be more sustainable. |
| Systematically finds invalid transition defects — the category of defect most likely to be a compliance or data integrity issue in NZ financial services and government systems. | Requires the tester to have enough domain knowledge to model the correct states. If the model is wrong, the derived test cases are wrong — and a confidently wrong model is dangerous. | The domain is too ambiguous to model reliably. Clarify requirements with stakeholders first; building a model on guesswork creates untestable artefacts and false confidence. |
| Enables test case generation via tooling (GraphWalker, draw.io scripts) — the model becomes executable and can drive automated regression at scale without manual test case authoring. | Automated test generation from models is a specialist skill. Most NZ teams use models manually — a spreadsheet matrix and hand-derived test cases — rather than wiring up automated generation tools. | The feature is a calculation or data transformation with no state machine. A decision table with equivalence partitioned inputs will cover all the business logic without the modelling overhead. |
Enterprise reality
How Model-Based Testing changes at 200–300-developer scale in NZ enterprise — when informal state diagrams give way to governed artefacts, regulated coverage obligations, and tool consolidation across 10+ squads.
- At small-team scale, state machines live in Miro and test cases are hand-derived each sprint. At enterprise scale — Pacific Bank, Revenue NZ, HealthNZ — models are version-controlled alongside code, owned by a test architect, and generated from tooling (GraphWalker or commercial equivalents). The difference is not sophistication; it is governance. A model that diverges from the implementation at a 20-person startup is a nuisance. At a 200-developer bank it is a compliance gap.
- NZ's Privacy Act 2020, NZISM (NZ Information Security Manual), PCI DSS for card-handling systems, and HISF (Health Information Security Framework) all impose audit obligations that map directly onto state transition coverage. Revenue NZ's tax processing systems and HealthNZ's patient data platforms are regularly required to demonstrate, with evidence, that every permissible transition has been tested and every blocked transition has been verified as blocked. At this scale, MBT artefacts — transition matrices with test case traceability — are not optional extras; they are the audit deliverable.
- Tooling decisions at enterprise volume move beyond draw.io and spreadsheets. CloudBooks and ListRight, running continuous delivery with 50+ engineers per platform, use GraphWalker for model-driven navigation testing on critical flows, supplemented by BDD frameworks (Cucumber, SpecFlow) where business stakeholders need readable coverage reports. The choice is not about capability — it is about artefact ownership: who updates the model when a state changes, and how is that change propagated to 40 dependent test suites automatically rather than manually?
- At 10+ squad scale, model-based testing requires a cross-squad ownership model. A single state machine for a claims or enrolment workflow touches six squads at CoverNZ or Benefits NZ: the squad that handles submission, the squad that handles assessment, the one that handles appeals, and so on. Without a designated test architect role responsible for the canonical model, each squad independently maintains a partial view and coverage gaps accumulate at the integration boundaries — which is precisely where compliance defects live.
◆ What I would do
Professional judgement — when to reach for model-based testing, when to skip it, and what to watch for.
The bottom line: Model-based testing earns its upfront cost when the system has multiple states, non-obvious invalid transitions, or regulatory audit obligations — the model pays for itself by finding the defects that intuitive test design leaves behind. On stateless or simple features, it is overhead; reach for equivalence partitioning or a decision table instead.
9 Best Practices
- ✓ Start with states, not transitions. List every state the system can be in before you draw a single arrow. Transitions are easy to add once you have the full state inventory — and the state inventory reveals gaps.
- ✓ Explicitly enumerate invalid transitions as a separate column. For each state, list what transitions are blocked, not just what is allowed. Invalid transitions are where security and compliance defects hide.
- ✓ Name your transitions as events, not actions. Use
submit(),approve(),cancel()rather than "click Submit button" — the model stays system-level and maps cleanly to API calls and business rules. - ✓ Cover at least: every state, every valid transition, and every invalid transition. That is the minimum coverage criterion for a state machine. If you have time, add round-trip paths (state A → B → A) and longest paths.
- ✓ Pair the state machine with a decision table for guard conditions. If a transition only fires when multiple conditions are true (e.g., "Approved AND payment method verified AND under credit limit"), model those conditions separately in a decision table.
- ✓ Version-control your model alongside the code. A model that diverges from the implementation is worse than no model — it generates test cases for behaviour that no longer exists. Keep the model in the repo, update it with every sprint.
- ✓ Use the model in sprint planning, not just testing. Walk developers through the state machine before they write a line of code. Developers who see the model write state-aware validation logic from the start; those who don't add it later (if at all).
- ✓ Trace every test case back to a specific transition. A test case without a model reference is untraceable. Use a simple ID like
MBT-TC-04 covers S3→S5 via approve()— auditors, regression planners, and your future self will thank you. - ✓ Run a "model review" with a developer before executing tests. Show the developer the model and ask: "Is this how you implemented it?" Discrepancies found here cost minutes; discrepancies found in production cost days.
- ✓ Re-derive test cases when the model changes, not when a bug is found. When a state is added or a transition is changed, update the model first, then re-derive affected test cases. Don't patch individual test cases in isolation — the model is the source of truth.
10 Common Misconceptions
❌ Myth: Model-based testing is only for systems with a formal UML state diagram in the spec.
Reality: You build the model yourself from whatever spec exists — user stories, acceptance criteria, Confluence docs, or a conversation with the product owner. The model is your artefact, not a pre-existing deliverable. If the spec has no model, building one is even more valuable because it forces ambiguity to the surface before a single line of code is written.
❌ Myth: You need specialised MBT tooling (Conformiq, GraphWalker, Selenium-based test generators) to do model-based testing properly.
Reality: A state matrix in a spreadsheet and test cases in a standard test management tool is entirely sufficient. Automated test generation is the advanced tier — the core value of MBT is the modelling discipline, not the toolchain. NZ teams routinely get the full benefit from a Miro diagram and a well-maintained test case matrix.
❌ Myth: Once you have 100% state coverage, you have sufficient test coverage for a state machine.
Reality: Visiting every state is not enough. A state machine with N states and M transitions requires transition coverage (every arrow tested at least once), and for high-risk systems, invalid transition coverage (every blocked path verified to be blocked). A test suite that reaches all states via the happy path alone will miss defects on rarely-used transitions — which is exactly where production incidents in NZ insurance and banking systems are found.
11 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.
Why teams fail here
- Testing only valid transitions — the happy path passes, the team ships, and an invalid transition allowing a data integrity bypass sits undetected until a production incident surfaces it months later.
- Treating the model as a one-time artefact — the state machine is built at sprint start and never updated when the implementation diverges, so tests are verifying behaviour the system no longer has.
- Confusing state coverage with transition coverage — reaching all eight states via two happy-path tests does not mean all twenty transitions have been exercised; regulators and auditors expect transition-level traceability, not state-level counts.
- Building the model from the implementation rather than the specification — if you reverse-engineer the state machine from the code, you confirm what was built, not what was required; spec-first modelling is the only way to catch missing requirements before they become missing features.
Key takeaway
A model that forces you to name every state and every blocked transition will find more defects in an afternoon than a week of intuitive test case writing — because it makes the invisible paths visible before you even open a test tool.
How this has changed
The field moved. Here is how Model-Based Testing evolved from its origins to current practice.
Finite state machines and formal specification languages provide the mathematical foundation for model-based test generation. Academic researchers generate test cases automatically from specifications. The technique is powerful but requires formal modelling skills rare outside academia.
Commercial MBT tools emerge (Conformiq, Smartesting, TTCN-3 for telecoms). Applied in telecommunications — a standards-heavy domain where formal protocol specifications make automated test generation viable. Telecoms engineers, not testers, drive adoption.
UML state machine diagrams become mainstream in software design. Testers begin deriving tests from state models manually. The bridge between design models and test cases is obvious but tooling to automate the derivation is still specialist.
Open-source MBT tools (GraphWalker, Modbat) lower the barrier to entry. Agile adoption creates tension: MBT requires upfront modelling, which conflicts with evolutionary design. MBT finds a home in protocol testing, embedded systems, and complex UI flows.
AI tools can generate test cases from natural language requirements — an informal version of MBT that does not require formal modelling skills. GraphWalker and similar tools are used for navigation-heavy web applications. The core insight of MBT — derive tests from a model of system behaviour, not from the implementation — underpins property-based and generative AI test techniques.
12 Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about Model-Based Testing — and what strong answers look like.
Describe how you would use a state machine model to test a NZ government benefit application workflow.
Strong answer: I would model the application states: Not Started, In Progress, Submitted, Under Review, Additional Information Requested, Approved, Declined, and Appealed. Each state transition is a test path: Submit moves In Progress to Submitted, Request Information moves Under Review to Additional Information Requested. From the model I derive: all valid state transitions (happy path plus every alternative), all invalid transitions (submitting an already-submitted application), and state invariants (an Approved application cannot be moved directly to Not Started). I then run GraphWalker or similar to generate a test sequence that covers all transitions with minimum test cases. The model also reveals missing requirements: what happens if an appeal is withdrawn?
Mid/Senior
What is the difference between model-based testing and property-based testing?
Strong answer: Model-based testing generates test cases from a formal model of system behaviour — a state machine, UML diagram, or decision table. The model describes the specification. Property-based testing specifies properties that should hold for all inputs and uses a framework (Hypothesis, Pact) to generate inputs that probe those properties. MBT is top-down (model → tests), property-based is bottom-up (properties → generated inputs). MBT ensures you test the specified behaviour; property-based testing finds unexpected failures by exploring the input space exhaustively. They complement each other: use MBT to verify specified behaviour, property-based to find unspecified failure modes.
Senior/Lead
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.
Q4: Your team is testing the CoverNZ injury claim workflow on a new portal. There are six claim states and eleven transitions. The sprint is two weeks and the BA has provided a Confluence page with a swimlane diagram. How would you apply model-based testing here, and what would you produce?
A: Start by converting the swimlane diagram directly into a state transition table — each swimlane lane change is a transition candidate. Enumerate all six states and confirm transitions with the BA in a 30-minute review before writing any test cases. Produce: (1) a state transition matrix in a spreadsheet listing every valid and invalid transition, (2) a test case per row tagged to a transition ID, and (3) coverage evidence tracing each test case back to a specific model node. This artefact also satisfies any CoverNZ audit requirement to demonstrate systematic path coverage. Two weeks is sufficient — the model building takes half a day; the test design follows directly from it.
Q5: The Revenue NZ myIR portal has a tax return submission feature that calculates a refund or liability based on income type, deductions, and student loan status. There are no meaningful states — the user fills in fields and gets a result. Should you use model-based testing here, and if not, what would you use instead?
A: No — this is essentially stateless from a workflow perspective. Model-based testing targets systems where the system's current state determines what actions are valid next. A tax calculation with no persistent state machine is better covered by equivalence partitioning (income brackets, deduction categories) and a decision table (combinations of income type × deduction × student loan flag → expected outcome). MBT adds overhead without adding coverage benefit when there are no meaningful state transitions to enumerate. Choosing the right technique for the context is what distinguishes a senior tester from a junior one.
Q6: What is the key difference between model-based testing and state transition testing?
A: State transition testing (CTFL Foundation level) applies a specific black-box technique to a system that already has a defined state table — you derive test cases by applying coverage criteria (all states, all transitions, all invalid transitions) to that table. Model-based testing is broader: it is the discipline of building a model of system behaviour from scratch — which may be a state machine, a decision table, a use-case model, or a flowchart — and then generating test cases from it. State transition testing is one output technique within MBT. The distinction matters in ISTQB CTAL-TA exams: CTFL covers state transition tables; CTAL-TA Section 3.5 covers model construction and multi-model test derivation.
Q7: A developer on a KiwiSaver fund-switching feature says: "We don't need to model the states — the happy path tests cover everything because the unhappy paths just show an error message." What is wrong with this reasoning and how do you respond?
A: The reasoning conflates "shows an error" with "correctly blocks the transition." In a KiwiSaver fund-switch workflow, an invalid transition (e.g., initiating a switch while a previous switch is still pending settlement) might display an error message in the UI but still write a partial record to the database, or vice versa — block the UI while allowing a direct API call through. Happy-path tests only verify that valid transitions work; they provide zero evidence that invalid transitions are actually blocked. The developer is also assuming the error handling is correct, which is precisely what needs to be tested. Respond by showing one specific example of an invalid transition in the current model that the happy-path suite does not cover, and offer to trace it to a regulatory risk (e.g., FMA guidance on fund-switch settlement periods) to make the business case concrete.
13 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).