Model Driven or Model-Based, what’s the difference?
I guess it’s fair to say that during the last five years “model-based testing” has become some sort of a recognizable buzz-word in the QA world. But at the same time, so many different notions and ideas have been attached to the phrase that any particular meaning needs to be explained separately. This was actually one of the main problems that the discussion about practical deployment of model-based testing at the M-TOOS workshop (Portland 2006) identified.
For example, some companies mean by “model-based testing” the modeling of testing architectures—this is related often to the UML 2 testing profile (U2TP) that is meant exactly for that. Other people think that it is “model-based testing” when your requirements are described in some sort of a graphical model, and then you derive tests manually and execute them by whatever means afterwards. And the idea that you create “user scenarios” as finite state machines and walk randomly around them is also known as “model-based testing”.
This is why we have always held to the phrase model driven testing. By this phrase we underline our view that model driven testing is about the complete automation of test design that is based on an executable-level system model. This is really test design that is driven by models, maybe in the same way as most cars are driven by people (yet at least): the system model is the elevated, sole source for automatically generated testing logic.
The drawback of this “model driven testing” term is that it is not as good a buzz-word! So we now and then characterize our approach more generally as “model-based testing” just to be able to log into the thought processes of our context groups. It’s basically like calling a sports car a transportation device. Not dishonest or true by any means, but a bit vague. (Of course, these kind of issues surface within any emerging, young concept spaces.)