Model Based Testing

Model Based Testing (MBT) is a term frequently used these days. It sounds well and just from the words seems like a good thing to do. But is it really worth the hype?

The strict definition of Model Based Testing is when you base your testing on one or more models. This still sounds good, but not so much if you consider the following:

A model is a simplification of reality. So if your tests are solely based on one or more models, you’re bound to leave some paths untested.

If code is also generated from the same model, you’re testing the generation process in stead of the product or model. Even if the code was not generated automatically, but the developer also based his code on the model, it is not likely that many faults are found.

Models must be created or provided.

Models can contain faults as well.

But lately the term is also used for tests described by models. The model still describes the system, because every test case does, but the primary purpose of the model is to describe the test case. Describe what path is followed, what actions are to be taken, and what is to be expected. Although I don’t call this Model Based Testing, Test Case Modeling is perhaps a better term, I do see a great benefit of it.

In earlier, pre-Agile times long descriptions used to be made for every test case followed by another description of the next test case that was only different by a few (essential) words. Later, Excel was used to describe test cases by key- and action-words. Test Case Modeling can be the next step in the evolution of describing test cases and to visualize them with the best possible model-type.

Post navigation

2 thoughts on “Model Based Testing”

Hi Arjan,
I agree with the points you give in the post. I would recommend that people learning about MBT consider creating models specifically for tests, in stead of trying to derive tests from the system model only.
When one creates a model specifically for a test, it is quite easy to make it a little bit more elaborate and to apply techniques to derive multiple test cases from that model. Deriving the test cases is very fast when automated, and this makes it feasible to have many test cases (or test situations) and improved test coverage without high maintenance costs. This makes a test model more powerful than individually scripted tests.

Hi Arjan, I do see your points and came to the same conclusions when looking at MBT in real-life. However, instead of dismissing MBT as a whole, I would rather suggest combining it with test case modelling as you call it. Actually, we are currently experimenting that concept and it seems quite promising, although we have not addressed the automated test generation part of it.