There are some important considerations I want to make on final state
machines. And more in general, on model based testing. The first one
is about applicability. Testing based on final state machines is a very
general approach, that we can apply in a number of contexts. And in
particular, if you are working with UML, you have state machines for
free. Because state charts are nothing else but a special kind of
state machine. So you can apply the technique that we just saw
directly on state charts, and try to cover their states and their transitions.
Another important point is that abstraction is key. You have to find the
right level of abstraction. The bigger the system, the more you have to
abstract if you want to represent it with a model, and in particular, with
the final state machine. So it's like having a slider, and you have
to decide where you want to move on that slider. The more you represent,
the more complex your system is going to be and the more thorough your
testing is going to be but also more expensive. The less you represent the
less expensive testing is going to be, but also testing might not be as
thorough as it would be otherwise. So you have to find
the right balance between abstracting the weight too much and abstracting
the weight too little. And finally there are many other approaches.
So we just scratched the surface, and we just saw one possible
approach. But for instance, other models that you can use are
decision tables, flow graphs and even historical models. Models that can
guide your testing based on problems that occurred in your system
in the past. And also, in this case, I'm going to put pointers
to additional materials in the class notes.