Model-based testing is an approach in which processes are mapped graphically in a test model, so that business experts and testers can work out the requirements together and generate test cases from them automatically. The model replaces prose with a visual language, exposes gaps in requirements right away and serves as the basis for impact analysis when something changes.
Key Takeaways
- Model-based testing gives business experts, testers and developers a shared visual language that moves discussions away from technical detail and toward the questions that matter.
- About half a year of work at Lufthansa CityLine produced around 700 test cases, organized in 60 models and generated at the push of a button.
- The model exposes gaps in requirements immediately: a single kick-off workshop delivered improved requirements and the matching test cases at the same time.
- Changes during operations, such as new collective bargaining agreements, can be handled as a targeted impact analysis in the model instead of reviewing hundreds of test cases one by one.
- Overly complex models lead to an explosion of test cases. Small, understandable models with a narrow scope work better than trying to capture everything in one.
Testing Collaboration: Model-Based Testing Brings Stakeholders to the Table
In large software projects, good testing collaboration runs into a basic problem: the knowledge you need for good tests is spread across three groups. Business experts know the processes. Testers know how to build good test cases. Developers build the software from the information they get. Bringing these three together is the real work, and a model gives them common ground. That is what model-based testing does.
A model works like a language. It is a way of expressing something that everyone involved can agree on. Because it is visual, it stays simple and easy to follow. Marvin Jakob puts the core effect like this: you can point at a spot and say, we need to talk about this again. That kind of visibility is exactly what plain prose lacks.
At Lufthansa CityLine, the team used the approach for a crew management system that was being built for a newly founded airline. With a system built by an outside vendor, the challenge is always the same: does the vendor deliver exactly what was ordered? To accept the system, you need domain knowledge and good communication between the business side and the testers.
How a Test Model Grows from Distributed Knowledge
A test model comes out of interviews, not out of ready-made diagrams. Models like this aren’t lying around in a project. They are built up question by question.
You start with a single requirement and ask how you would test it. What’s the first step? What’s the second? Those steps go into the model as activities. From there, the model almost leads you to the next question on its own: What happens next? Does anything else happen here? Do we need a branch at this point?
The process is hands-on and flexible. You can move activities around, fill gaps, add steps someone forgot. At some point the model heads toward an end point it can’t reach yet, and that is where it becomes clear which activity is still missing. At the end of a workshop you have a tangible result, which is not a given in software development.
Start at a High Level of Abstraction
The most important practical rule in model-based testing: start at a very high level and get all the way from start to finish before you discuss details.
If you get lost in sub-diagrams and low-level branches right at the beginning, you lose the big picture. It works better the other way round. Build a high-level model, talk it through, and only once everyone understands it, go one level deeper and add more test information. Step by step, until you can generate complete test cases at the push of a button.
This has a real benefit for the discussion. Conversations move away from technical details and nitpicking toward the questions that matter. As long as you stay at a high level, you stay in problem-solving mode instead of getting lost in things that seem impossible.
Deciding what to test and what not to test moves to a later point. First you capture the business logic in the model, then you decide on coverage: edge coverage, full path coverage, test data variants, equivalence partitions. You can make that decision calmly without the model suffering for it.
Good Tests Need Good Requirements
You can only write good tests if the requirements are good. Requirements and tests belong together, because together they describe the feature.
The model makes gaps in the requirements obvious, and you can discuss very concretely where they need work. At CityLine, the team left the kick-off workshop with improved requirements and the matching tests, both in one step.
The workshop followed a clear sequence. In the morning, the group refined the user stories they had brought along to understand them, making the first improvements. Then someone who had never used the tool before sat down and built the first test model. At around three in the afternoon, everyone went home with refined stories and the test cases generated from them.
Keep Test Models Simple or They Won’t Hold Up
A good model is simple and easy to understand. It is not an attempt to capture the whole world in sub-diagrams. Models of arbitrary complexity rarely work.
A practical test for clarity: bring in someone who hasn’t seen the model before and ask them to explain what it says. If they can, the model is expressed simply enough in its own language. Aviation processes are complex, and it still worked for many cases.
A clear test scope matters just as much. There is no single model that covers all business processes. Put everything into one model and you get a test case explosion, and in the worst case the computer grinds to a halt during generation. Focusing on one scope protects you from that.
From Model to Test Case at the Push of a Button
Once the model is in place, a click on the generate button produces the test cases. The tool takes over the tedious work of turning tests into something executable, so that part is automated.
At CityLine, this produced around 700 test cases spread across about 60 models. The models could be transferred into the Jira instance the team already used, where people could view them, add comments and review them. The team used the existing infrastructure instead of building new tooling.
In Jira, the model also shows its status in color: what has been tested, what works, what doesn’t. That gives the team a basis for talking to stakeholders and builds trust, because the work stays transparent and can be explained at any time.
“I can communicate really well with my stakeholders about it, build trust and work completely transparently. That’s what matters to me in testing.”
(Oliver Schuhmacher)
Using the Test Model for Impact Analysis When Requirements Change
The model makes impact analysis easier when requirements change. Instead of paging through Jira lists, you look at the model and see the affected test cases behind it.
In aviation, new collective bargaining agreements and rules come in regularly and have to be taken into account. With 700 test cases, checking each one for validity by hand is painful. If the models are stored in a clear structure, you quickly see which areas are affected and where the change has to go in.
From the updated model, you can overwrite the test cases directly or create a new version. That keeps them current. It still takes work, but the effort goes into the questions that matter: What has changed, and what’s the best way to test it?
The Model Should Live On After the Project
A test model belongs in the analysis phase, on equal footing with the requirements. It comes at the beginning, when the team is working out what it wants to build and where it wants to go.
To get the full benefit, the model should outlive the project. At CityLine, the plan is to hand the models over to the line organization during the transition phase as a form of documentation. If you throw the model away when the project ends, you only get half the benefit.
That requires a team of testers, business experts and developers who work together the whole way through to operations. In large projects, it’s almost impossible to have all requirements on the table from day one. The model is the basis on which this team keeps exchanging and documenting information.
Just Get Started and Try It
The most important advice for getting started is to try it. Every new tool comes with a learning curve, and you will make mistakes at the beginning.
Even so, the approach saves time in the end. Because a lot of effort goes into analysis, and that is where the right things get discussed, you are mostly done afterwards. There is little you can get wrong, even if you feel your way forward bit by bit.
If you’re unsure, you don’t have to start alone. The testing community is a good place to find help, coaching or a second pair of eyes on your model. At its core, the value lies where scattered knowledge comes together, requirements get sharper and the tests that matter for business value come straight out of the model.
Frequently Asked Questions
When Is Model-Based Testing Actually Worth It?
This approach pays off when the necessary testing expertise is distributed among three parties: domain experts know the processes, testers know how to create good test cases, and developers build the software. It’s particularly helpful for externally contracted systems because the acceptance criterion is whether the vendor has delivered exactly what was ordered. The model provides the common foundation for this.
Do you need ready-made process diagrams before you can start with a test model?
No. Such models aren’t just lying around in projects; they emerge through a process of asking and answering questions. The starting point is a single requirement and the question of how to perform testing on it: first step, second step, and each of these becomes an activity in the model. From there, the next questions lead the way: What happens next? Do we need a branch here?
What is the most common mistake when building test models?
Building models that are too complex. Anyone who tries to map the entire world with subdiagrams or cram all business processes into a single model will end up with a test case explosion; in the worst case, the computer will freeze during generation. A narrow test scope and small, understandable models work better. Here’s a practical test: A third party should be able to explain what’s in the model.
Does test coverage have to be defined before modeling begins?
No, this decision is intentionally postponed. First, the business logic goes into the model; only then do we discuss coverage: edge coverage, full-path coverage, test data variants, equivalence partitions. This can be decided at a leisurely pace without compromising the model. It also makes sense to work through the model at a high level from start to finish before negotiating the details.
Does model-based testing help even when the requirements are still incomplete?
Yes, that’s one of the main benefits. The model immediately highlights gaps because you can point to a specific spot and say, “We need to discuss this again.” At Lufthansa CityLine, the team left a kick-off workshop with improved requirements and the corresponding test cases: user story refinement in the morning, finished results in the afternoon.
How many test cases can realistically be generated using this approach?
At Lufthansa CityLine, about half a year of work resulted in roughly 700 test cases, spread across about 60 models. They were generated from the models at the push of a button. The tool handles the tedious work of preparing tests so that they are executable. The effort is shifted to analysis and modeling.
How do you keep hundreds of test cases up to date when requirements change?
Through an impact analysis of the model rather than through page-long ticket lists. If the models are stored in a structured manner, you can quickly identify which areas are affected by a change and where it needs to be implemented. In the aviation sector, for example, new collective bargaining agreements are regularly added. From the updated model, test cases can be directly overwritten or versioned and incremented.
At what point in the project should a test model be introduced, and what happens to it at the end of the project?
The test model belongs in the analysis phase, on par with the requirements, that is, at the very beginning, when the team is clarifying what it wants to build. Anyone who discards it at the end of the project is only reaping half the benefit. At CityLine, the models are intended to be transferred to the line organization during the transition phase as a form of documentation, where they will continue to be used.
