Model Based Testing – Modeling
Model Based Testing or MBT is a technique in which models are used to generate test
cases. By doing this, a test engineer doesn’t have to think of individual test cases, but rather
think of a system as a whole. A tester will still have to make decisions on which test
techniques are the most applicable to apply, to gain the most coverage, and mitigate most
risks.
The term generate immediately implies automation, but this doesn’t have to be the case. You
can also apply the principles of MBT in a manual test setting, but of course the strength is
most visible when using automation tools. There are many tools, which we will dedicate its
own blogpost to.
Definition of a model
For MBT models are the center topic, so what exactly is a model? According to Wikipedia
A model is an informative representation of an object, person, or system. (source April 2025,
https://en.wikipedia.org/wiki/Model).
This is very generic and not informative, any representation of a system will do, so are
requirements a model? Is the code itself a model? In my opinion yes to both questions.
Another problem with modeling is that from different perspectives different models can
represent the same system.
To prevent any problem and misinterpretations it is important to keep an open
communication and open mind to other perspectives.
ISTQB definition
ISTQB also has a definition for a model, specifically in the context of MBT. This is not just
one model but is threefold:
1. System Model
2. Environment/Usage Model
3. Test Model
ISTQB CT-MBT version 2024 https://www.istqb.org/certifications/certified-tester-model-
based-tester-ct-mbt/
Typically, in software a design is made for the System Under Test (SUT), and for MBT I
would suggest that to be the model that is the basis for the system model. This can be any
model made, for example with UML, but also requirements are a form of a system model.
An environment/usage model is there to show how a system is expected to be used. In the
example of a model of a coffee machine, the button ‘Make coffee’ will be used more
frequently than the maintenance button. Another important note in this is, for example when
making a car rain/heat/other environmental variables do influence your SUT, so all of these
items will change how you need to test.
Finally, for testing choices can be made which test techniques should be used. For example,
if the system model is a state diagram, the choice could be made to use the n-switch
(https://www.tmap.net/wiki/state-transition-testing) test technique. But also, choices about
coverage or risk can be put in here.
Most tooling will only use 1 model, so then these 3 would need to be combined into one, but
during the creation of such a model it is still good to keep all 3 perspectives in mind.
How to choose?
It is important when choosing MBT to decide on what type of modelling the organization
prefers. I personally prefer state diagrams, but in case the system architecture is described
with activity diagrams, then it is better to keep consistency in an organization and also make
the test model in an activity diagram.
One other important pitfall which is good to avoid is, even though reusing the system model
from the software solution, it is not advisable to only us that model as input for the MBT tool.
It is acceptable when the tooling supports multiple models as well, but in case of most tools
where there is only 1 model, this model should be tailored for keeping the context of testing
in mind.
If this is not done, and just the model is that is used, is the exact same as it also was for
development purposes, the only thing that is getting tested is if the interpreter is working.
Especially in the context of Model Driven Engineering (when code is generated from the
model) this can become useless.
Finally there is a difference between graphical and textual models. Graphical models are like
state diagrams or sequence diagrams, while textual models can be user stories or
requirements. There are many variances in both.
An image can say more than a 1000 words, it is usually very good for discussions and
getting a plan, while specifications sometimes stay a bit blurry. Textual has the opposite, it is
hard to use during discussions, but in the end the details can be very explicit.
In a next blog post I will go into different tooling, but to clarify the difference between textual
and graphical: see below an example of an MBT tool for both choices.
Example Graphwalker:
Example Torxakis:
Conclusions
There are multiple options for models. When your organization decides to go for MBT, it is
good to make a consideration on what types of models will help you, and choose a tool
according to that.
If this is the first time your organization uses models it is good to consider what the goal is
for your modelling language. Is it to communicate with management on where risks are and
generate for that? Then go for a graphical tool which would be self-explanatory. Is the goal to
get the most test coverage as a software engineer? Then go for a textual tool, and add as
much details as possible.
