Model-based testing is an approach in which test cases are derived systematically from a formal model of how the system behaves, a practice known as model-based test case design. In practice, the main problem is the gap between the abstract model and concrete test execution. A two-phase approach bridges that gap: first, high-level test cases are generated from the model, then concrete test data and automation scripts are added interactively.
Key Takeaways
- Model-based testing often fails in practice because of the gap between abstract test design and concrete test implementation: concrete test data and GUI actions make the model needlessly complex.
- A two-phase approach solves this. First, high-level test cases are generated from the model and kept executable by hand. Only after that are concrete data and automation scripts added.
- According to Capgemini’s World Quality Report, test automation has so far missed the business goals set for it: no smooth CI/CD pipelines, no efficiency gains and no measurably better software quality.
- Trained testers rarely apply systematic test design techniques such as equivalence partitioning or boundary value analysis in practice. When they write test cases, gut feeling wins.
What Model-Based Testing Is and Where It Gets Stuck
Model-based testing derives test cases from a model instead of writing each one by hand. With model-based test case design, the tester decides what needs to be covered, models it and generates the test cases from that model. The idea is old and appealing. In practice, it rarely goes smoothly.
Matthias Hamburg has introduced the approach in several projects as a test manager. His verdict is sober: “It never went all that smoothly.” That matches what the industry reports. The World Quality Report by Capgemini and Sogeti finds that test automation as a whole has not delivered the business goals people expected from it.
Three expectations went unmet: smooth CI/CD operations with automation, the hoped-for efficiency gains and measurably better software quality. The survey asked managers and executives, the people who look at business goals. Those were exactly the goals that were missed.
Why Most Model-Based Testing Approaches Fail in Practice
Two hurdles stand in the way of model-based testing. The first is about people, the second about the tool workflow.
The first hurdle: the people who build the models usually have no training in modeling. Formal models require training that testers rarely get. So the only practical models are the ones that make sense without a long learning curve and stay close to how testers think.
The second hurdle is the workflow itself. Model-based testing currently offers no continuous path from modeling to the executed test. That gap is where the problems start.
Where the Gap in the Test Process Lies
The ISTQB model of test activities lays out the steps clearly: test analysis, test design, test implementation, test execution. Test design defines what needs to be covered, the test conditions. Test cases can then be generated from the model. Execution has long been automatable with tools like Selenium or Playwright.
Test implementation sits in between, and that’s the sticking point. This is where concrete test data is chosen, where you decide which buttons get clicked and which concrete results get checked. It’s the step from abstract to concrete.
The usual answer from MBT tools is to put the concrete data straight into the model. But that makes the model very complex. A model is supposed to abstract and give you a logical view. Pulling concrete data into it breaks that view. This overloading is one of the reasons model-based testing never caught on.
How Model-Based Test Case Design Works in Two Phases
A newer approach separates abstraction and concretization into two phases. First, high-level test cases are generated from the model. They have to be executable by hand, because in manual testing the person running the test fills in the gaps anyway.
Phase one can be done early, before the software is finished. That’s the shift left advantage: modeling early protects the quality of the test basis and the specification. Then you pause, with no need to fear a paradigm shift.
Phase two starts as soon as the real application is running. The tool executes the high-level test cases and stops at the open points to ask: what does “enter text” mean here, concretely? It shows the dialog, you type the appropriate text and let the tool record the action.
This isn’t plain capture and replay. Older capture tools produced scripts that often stopped working later, with all the maintenance problems that come with that. Here, the tool first generates the GUI-level action from the business level. That action is readable and can be edited in the low-level test case. The executable script for the automation platform is generated from it, Playwright in the case that was tried out.
Why This Approach Stays Maintainable
Maintainability is the real payoff. If an action changes because the implementation changed, every place that uses the action gets updated. Formally, the redundancy doesn’t go away, but the tool keeps it consistent.
A common real-world problem shows the benefit especially well. Some UI frameworks assign new IDs to GUI elements with every small change. Add a button somewhere, and everything after it gets renamed. That breaks classic automation.
The tool deals with this pragmatically. It stops where it can’t find a selector and asks. You fix the selector in the list, and the test runs again. Only what has actually changed needs updating.
Action State Testing: A State Model in the Tester’s Language
The tool that was tried out comes with its own model, tied to a black-box technique called Action State Testing. In substance, it’s close to state transition testing, but it’s phrased much closer to how testers actually work.
The model is currently text-based, not graphical. You write down test steps the way you’re used to anyway: an action, an expected result to check and a resulting state. The resulting state of one step is the precondition for the next.
An example from a glossary application makes this concrete. Initial state: the search page is displayed. Action: enter a search term. Check: there is at least one hit, and the search term appears in the hits. Resulting state: the results list is displayed. Selecting an entry shows its details, and a back button returns you to the results list.
The sequence of steps can be shown as a flowchart. The result is scenario-based and uses the states at the same time: a test-relevant state model that can be covered systematically.
One Technique Alone Isn’t Enough
Model-based testing doesn’t replace the classic test design techniques. It combines them. In the glossary app, equivalence partitioning was used alongside the state-based approach. The tests searched not only for text from a term’s name but also for abbreviations and synonyms, because the search has to work for all three.
This points to a common weakness in practice. Many testers learn equivalence partitioning, boundary value analysis, state transition tables and decision tables once, but in their day-to-day work they go by gut feeling. A structured approach combined with modeling brings these techniques back into daily work.
A negative example from industry shows how far things can go without that discipline. A large company with quarterly releases had all its business experts come into the office on release weekend and test ad hoc. Asked when the bugs they found would be fixed, the answer was: “We hope there won’t be any.” A clear sign that trained testers weren’t doing their job and didn’t know any test techniques.
Open Issues with the Approach
No tool is ever finished, and this approach is new on the market. Two wishes remain.
- Data-driven testing: Test data such as the search term should be stored separately and reused in other test cases, instead of sitting in a step as a loose text reference.
- More test design techniques: Beyond state-based testing, equivalence partitioning and boundary value analysis built right into the tool would help reach the desired test coverage cleanly.
Despite these gaps, the application could be tested thoroughly. The glossary app isn’t business-critical and nobody loses a cent if it fails. It’s still a question of attitude: a testing expert doesn’t hand over an application that hasn’t been tested well.
Getting Started: What to Look for in Model-Based Testing Tools
People often shy away from model-based testing because it isn’t clear what they can actually do with it. The pragmatic way in is to try it out, not to start with theory.
Download a trial version of a good tool; there are several. Try working with it and see what suits you and what you find easy to handle.
“If I have to study for days before I can even generate the first small test case, keep your hands off it.”
(Matthias Hamburg)
Accessibility is the yardstick. One plus of the tool that was tried out is no-code generation. As a business tester, you define directly in the GUI what gets checked and what gets entered, without writing an automation script. In earlier large projects, that took a separate subproject of automation engineers who implemented what the business testers had designed.
Frequently Asked Questions
Does test automation meet the business goals that companies associate with it?
No. The World Quality Report by Capgemini and Sogeti finds that test automation has so far failed to meet the set business goals. Three expectations remain unmet: seamless CI/CD operations with automation, the hoped-for increase in efficiency, and a measurably higher software quality. The survey included managers and senior executives, in other words, people who focus specifically on these business goals.
What qualifications must testers have to work with models?
Those who create models in the testing team usually have no formal training in modeling. Formal models require training that testers rarely undergo. Therefore, the only practical models are those that remain understandable without a long learning curve and align closely with the tester’s way of thinking. One example is Action State Testing: action, expected result, subsequent state, all noted in text form just like familiar test steps.
Why do models often become too complex in model-based testing?
Because many tools automatically include the specific test data in the model. A model is meant to abstract and provide a logical view. If you include specific data and GUI actions, this view breaks down and the model becomes unnecessarily complex. This overloading is considered one of the reasons why model-based testing has not yet gained widespread acceptance.
Is the two-phase approach just a new form of capture-and-replay?
No. Earlier capture tools generated scripts that often no longer ran afterward, leading to corresponding maintainability issues. With the two-phase approach, an action at the GUI level is first generated from the business logic level. This action is readable and can be edited later for a low-level test case. Only then is the executable script generated for the automation platform, in this case Playwright.
What happens if a UI framework assigns new IDs to GUI elements with every change?
Traditional automation fails in this scenario: If a button is added somewhere, everything associated with it is renamed. A tool can handle this pragmatically by stopping at the point where it cannot find a selector and querying the user. The selector is adjusted in the list, after which the test continues. Only what has actually changed is updated.
Does model-based testing replace traditional test design methods?
No, it combines them. In the glossary application under test, equivalence partitioning was used alongside the state-based approach because the search for term names, abbreviations, and synonyms must function correctly. Many testers learn about equivalence partitions, boundary value analysis, state tables, and decision tables at some point, but tend to apply them based on gut feeling in their day-to-day work. A structured approach brings them back to a more methodical approach.
How can you tell if an MBT tool is suitable for beginners?
By its accessibility. Matthias Hamburg puts it this way: If you have to spend days learning before you can generate your first small test case, you should steer clear of it. It makes sense to download a trial version and try out what fits your own workflow. A plus is no-code generation, where subject-matter experts define what’s being tested directly in the GUI.
