Model based testing
This is just a quick introduction to model based testing. It is an approach that uses modelling for testing purposes (no, really!).
It is a topic I have been interested in for a while and that I was trying to get some insight to on two conferences. And the good thing is, I have been working with that approach lately and I think it has some advantages.
The basic idea is to describe a system as a model from a testing perspective, thus visualizing it in order to design your test cases or scenarios. It doesn’t really matter if you want manual test cases or automated ones. I have even used it to define test charters for session based testing. Let’s face it, whenever you are getting your hands on a new software to test it, you think about how to test it. Drawing models helps tremendously to share that knowledge with others and to spot design mistakes (presumably in the specification and not the model) or features you might have overlooked.
So why are models used?
There are two main approaches:
- Using models to support testing a.k.a. model based testing
- Using models do drive testing a.k.a. model driven testing
The first approach is what I already hinted at above: using models to support your exiting test approach. What I really like is that you can do this pretty early in development, in fact you could already be drawing the models while refining user stories. Every user story that gets into the sprint backlog has a model attached then, which is helpful for testers and developers alike and entangles the test process.
The second approach is a bit more time consuming and in fact I have heard quite some people say that this is the reason they don’t do model based or driven testing. Models need to be more sophisticated and compatible with tools as model driven testing is about generating test cases and in some cases test data as well straight from the models. While it takes more time to create the models, you can safe time in test case generation as you generate many test cases from the edges of the model.
So what do these models look like?
Well, just like human models test models vary: ranging from hand drawn sketches to UML models with hundreds of edges drawn in the visios and enterprise architects of the world (though I would strongly advice not to use too big models but work with sub model then). While it may take some time to buy into the UML conventions, I think it is worthwhile as it supplies a standard set of symbols that can be used. Activity diagrams and state machines are my favourite choices depending on what to actually model. I discourage from using use case diagrams. Although they can certainly provide useful information, they have one major flaw: you can’t really visualize any kind of sequence or order. And testing is going step by step.
A model drawn quickly in Word might look like this:
Those familiar with UML will notice that the rectangles do not really refer to objects. In this diagram the rounded boxes depict user actions while the rectangles depict automatic system actions whose results can be seen by the user. This models has 18 edges which would have to be described but could be automatically combined to 8 test cases. If you designed each test case you would have to design 61 steps (yeah, I know, copy and paste is your friend, but it is not a very sophisticated friend).
I have not been doing model driven testing so far, but made some positive experiences with model based testing:
- Visualization of testing ideas
- helps you identify design short comings
- helps gauging the test amplitude
- earlier test design on a more abstract level
From my experience model based testing does not consume considerably more time. If it does, it is time well spent. Some people might argue that it doesn’t really go well with exploratory testing. But I don’t agree with that one. To me exploratory testing does not mean to delve into a software without a plan and as I wrote early I think test models and test charters can work together quite nicely.
But don’t get me wrong here: models can be a useful tool in a tester’s inventory but should never be mistaken for an unerring approach to replace everything else.
