Blog
Model-Based Testing: Types, Example and Limits
Abhilash
Published on
Table of contents
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
For three decades, model-based testing has been the most academically validated approach to software testing that the enterprise industry has not adopted at scale. The reasons matter, because they explain where verification is heading next, and why the very idea of a model has become more important, not less, in the age of AI-generated code.
Model-based testing is not really a technique, it is a thesis about how software should be verified, and that thesis is now being tested by an industry shipping code faster than any model can keep up with.
This guide gives a practitioner-grade view: the definition, the mechanics, the model types, the history, the honest limits, and the way the discipline is evolving as AI rewrites the velocity of software itself.
What is Model-Based Testing?
Model-based testing (MBT) is a way of testing where test cases are generated from a model of the system, instead of being written by hand. The model describes how the system should behave, and a tool works through the model to create the tests.
Two things set it apart from normal scripted automation:
The model is the source of truth. What should happen is described in the model, not spread across hundreds of scripts.
Tests are generated, not written. How much you cover depends on the model and the rules you give the generator, not on how many tests someone has time to write.
Models come in different forms. You might use a state machine for a transaction flow, a UML activity diagram for a business process, a decision table for rules-heavy logic, or BPMN for workflows that cross several systems. The right one depends on what you’re testing and how much detail you need.
Model-Based Testing Example
Here’s a simple example. Say you’re testing the checkout on an online shop. Instead of writing a separate script for every scenario, you build a small model of the flow.
A generation tool then works through the model and creates test cases like these:
Generated Test | Path | What it Checks |
|---|---|---|
1 | Basket → Delivery → Payment → Confirmation | A valid order completes |
2 | Basket → Delivery → Payment → Payment (declined) | A declined card shows an error and stays on payment |
3 | Basket (empty) → Delivery | An empty basket can’t move to delivery |
4 | Basket → Delivery → Basket → Delivery → Payment | Going back and forward still works |
5 | Basket → Delivery (invalid address) | An invalid address stops checkout |
Nobody wrote those five tests by hand. The team described the checkout once, and the tool worked out the paths, including combinations like test 4 that people often forget to write.
How Model-Based Testing Works, Step by Step
Textbooks usually describe three stages, but in practice there are six. Each one can go well or badly on its own.
Decide What the Model Covers
This is the hardest step. You have to decide what the model includes and what it leaves out. Make it too simple and the tests miss real bugs. Make it too detailed and the model turns into another codebase to maintain.
Good models are usually layered. A high-level model of the business process sits on top of more detailed state machines for individual screens or services. That way you can generate tests at different levels without rebuilding the model each time.
Choose How Much to Cover
A model can produce an endless number of paths, so you need rules for which ones to test:
Coverage Rule | What it Means |
|---|---|
State coverage | Every state is visited at least once |
Transition coverage | Every move between states happens at least once |
Path coverage | Moves are strung together into full journeys |
Decision coverage | Every condition is tested as both true and false |
Risk-based coverage | Paths are chosen by business importance or how often they’ve failed before |
Risk-based coverage is where model-based testing really pays off. Running every possible path is technically doable but pointless in practice. Choosing the paths that matter most is where your team’s judgement comes in.
Generate the Tests
The tool works through the model using your coverage rules and produces abstract test cases. These describe inputs, moves and expected results in terms of the model, not yet in terms of the real application.
Turn Them into Real Tests
Next, each abstract step has to be linked to something that actually runs. For example, a model step called “submit application” might become a Selenium command, an API call or a database write. This is where a lot of older programmes struggled, because every application, and every change to it, needed its own custom adapter code.
Run the Tests
The tests run against the real system, and the results are compared with what the model expected. If they don’t match, either the system has a bug or the model does. A good team can tell which quickly.
Keep the Model Up to Date
This is the step most teams skip. Requirements change and the application moves on, so a model that’s never updated slowly becomes a problem. Teams that do this well treat the model like code, with versions, owners and reviews.
Types of Models Used in Model-Based Testing
Model Type | What It’s Good For | Example |
|---|---|---|
Finite state machine (FSM) | Flows with clear states and moves between them | A login flow, an order status |
Extended finite state machine (EFSM) | State flows that also track data and conditions | A checkout that depends on basket value and customer type |
UML activity and state diagrams | Business processes and system behaviour | A loan application process |
Decision tables | Logic with lots of rules and combinations | Insurance pricing or eligibility rules |
BPMN | Workflows that cross several systems and teams | Order to cash across sales, finance and warehouse |
Formal specifications (like Z or TLA+) | Safety-critical systems that need mathematical proof | Railway signalling, flight control |
Grammar-based models | Systematically creating valid and invalid inputs | Testing parsers, file formats and protocols |
Markov chain usage models | Testing based on how often users really do things | Weighting tests towards the most common user paths |
In enterprise testing, EFSMs, UML, decision tables and BPMN are the most common. Formal specifications are mostly used in safety-critical engineering. Grammar-based and Markov models tend to show up in specialist areas.
Benefits of Model-Based Testing
Benefit | Why It Helps |
|---|---|
Better, measurable coverage | Tests cover the system systematically, including paths people wouldn’t think to write, and you can measure exactly what’s covered |
Traceability | Every test links back to part of the model, so when the model changes, you know which tests change. That speeds up audits and impact analysis |
Less test writing once the model exists | It takes effort up front, but adding tests later is just a matter of extending the model |
Easier maintenance | When requirements change, you update the model and regenerate the tests, instead of fixing each test |
A shared view | Developers, testers and business analysts can all read a well-built model, so it doubles as a way to communicate |
These benefits are why model-based testing has never gone away. They’re also why so many modern AI testing tools borrow its ideas, even if they don’t call themselves model-based.
The Limits of Model-Based Testing
Teams that have used model-based testing in large organisations tend to hit the same four problems.
Models Need Maintaining Too
A model is software, so it has bugs, gets out of date and builds up technical debt. A model of a complex enterprise workflow can have thousands of states and tens of thousands of transitions.
Keeping it accurate as the application changes is a big job in itself. Some teams have found their model needed almost as much upkeep as the tests it was meant to replace.
It Needs Specialist Skills
Model-based testing needs people who understand modelling, whether that’s UML, BPMN, formal methods, coverage theory or how the generation tools work. Those skills are rare in most QA teams.
If your programme depends on two or three experts, you’re in trouble when they leave.
Models Struggle with Real User Interfaces
Models are great for logic and states. But many enterprise applications actually fail in the user interface. Dynamic screens, third-party widgets, accessibility, browser differences and content that changes based on conditions don’t fit neatly into a state diagram.
So a generated test can pass against the model and still miss something a real user would hit.
The Code Drifts Away from the Model
This is the biggest problem. A model is a specification, and generated tests check that the system matches it. But with AI writing code, systems don’t always match any one specification. AI assistants make their own local choices, refactor without telling anyone and introduce variations the model never planned for.
That gap between what the model says and what the code really does is called specification drift. It means the question has to change. Instead of asking “does the code match the model?”, teams increasingly need to ask “does the customer journey still work?”
Model-Based Testing vs Scripted Testing vs AI-Native Testing
Scripted Testing | Model-Based Testing | AI-Native Testing | |
|---|---|---|---|
Source of truth | The test scripts | A formal model | Requirements and customer journeys |
How tests are created | Written by hand | Generated from the model | Drafted by AI from requirements and journeys, then approved by people |
Skills needed | Coding | Modelling | Knowledge of the business and the application |
What happens when the app changes | Scripts break and need fixing | The model and adapters need updating | Fixes are suggested and reviewed |
Coverage | Depends on how much people write | Systematic, based on the model | Based on requirements and risk |
Best fit | Small, stable applications | Stable, rules-heavy or safety-critical systems | Fast-changing enterprise web applications |
This doesn’t mean model-based testing is finished. Its ideas are alive and well. They’re just being used in different ways.
How AI-Written Code Changes Model-Based Testing
Most engineering teams now use AI assistants every day. Pull requests are bigger and come more often, and refactors that used to happen at human speed now happen at agent speed.
That creates a chain reaction for testing. More code means more tests. More tests mean more maintenance. More refactors mean more broken tests.
And more AI-driven variation means the code drifts further from any single specification. It’s not a gradual rise. It’s a jump that breaks programmes already at full stretch.
A model-based programme built for stable applications and quarterly releases can’t keep up with a team shipping several times a day with AI-assisted refactors. The idea behind it still holds. What breaks is the assumption that the system changes slowly enough for the model to keep up.
From Checking the Specification to Checking Behaviour
The shift happening now is from checking the specification to checking behaviour. It sounds like a small change, but it matters a lot.
Checking the specification asks whether the code matches the model. Checking behaviour asks whether the customer journey still works: does a claim still get filed, does a purchase still complete, is a patient still admitted, is a policy still issued? The customer’s result becomes the source of truth, and tests keep checking that it holds as the code changes underneath.
Behaviour testing keeps the best parts of model-based testing:
Tests should be generated, not all written by hand
Coverage should be measurable
The test design should be readable by the whole team
What it drops is the idea that one specification can stay fixed long enough to be the single source of truth. In a team using AI to write code, the “model” is really the set of customer journeys, kept up to date from requirements, tickets, usage and changes in the application.
Also read: our guide to autonomous testing with agentic AI looks at how AI agents now take on parts of test design that models used to handle.
When to Use Model-Based Testing, and When Not to
Good Fit for Model-Based Testing | Poor Fit for Model-Based Testing |
|---|---|
Safety-critical embedded systems, where the specification is the regulatory document | Modern enterprise web applications that change often |
Protocol and parser testing, where grammar-based models create valid and invalid inputs systematically | SaaS products with frequent UI changes |
Regulated logic with stable rules, where decision tables fit cleanly | Systems under active AI-assisted development |
New systems with mature specifications | Simple applications, where a few direct tests are enough |
Mainframe and back-office systems that rarely change |
The good fits have something in common. The specification is stable, the system doesn’t change often, and the effort of building the model pays for itself over years.
The poor fits are the opposite. The screens and code change faster than the model can be updated, so maintenance swamps the benefit.
In those cases, testing behaviour through customer journeys makes more sense.
How Virtuoso QA Builds on the Model-Based Idea
Virtuoso QA takes the best ideas from model-based testing, like describing behaviour once, generating tests and measuring coverage, and applies them to customer journeys that change quickly.
The Journey is the Model
You describe a customer journey in plain English, like “add two items to the basket, check out as a guest and pay by card”. That description is what gets tested and extended, so there’s no separate modelling language to learn.
Requirements Turned into Tests
Touchstone reads your specs, user stories and process documents and drafts requirements from them, each citing where it came from. Approved requirements become journey tests, so the “model” is built from documents you already have, not from a separate specification someone has to maintain.
No Adapter Code to Rewrite
Older model-based tools needed custom adapters to turn model steps into real actions, and those broke whenever the app changed. In Virtuoso QA, plain English steps run directly against the application. When a screen changes, it suggests a fix for your team to approve, rather than rewriting adapters by hand.
Telling Bugs Apart From Test Problems
When a journey fails, you see the failing step, screenshots and logs, so it’s quicker to tell whether the application broke or the test needs updating.
Reusable Journey Pieces
Common steps and checks are built once and reused across journeys, browsers and operating systems, much like reusing parts of a model.
If you want to see how AI drafts tests from your requirements while your team approves each one, take a look at Virtuoso QA’s agentic test generation.
Related Reads
Model-Based Testing FAQs
What is model-based testing?
What are the types of models used in model-based testing?
What are the main benefits of model-based testing?
What are the disadvantages of model-based testing?
When should you use model-based testing?
How is AI changing model-based testing?
Written by
Abhilash
Industry Analyst, Test Automation
Abhilash tracks how AI is reshaping software testing, from pairwise coverage to regulatory accountability, and writes research-led pieces that cut through vendor noise with numbers.
