Data Tools and Software Testing : Elements of MBT

Elements of MBT - Part 3 – Actions and Action Parameters

nihitk — Fri, 06 Jul 2007 02:45:00 GMT

In the last 2 posts we have looked at what we mean by a model of a system and defined what States and State Variables are. In this post we'll look into Actions and Action Parameters.

We can define an Action as something that modifies or exercises the system. Thus "TurnIgnitionOn" (in the car model being used in this series) can be an action which causes the system to change in some way. When considering Actions you need to think about what exactly is it that changes in the system and which all state variables are impacted by those changes. An action is therefore simply something that causes the system to change states.

Actions become much more powerful and useful when combined with the concept of Action Parameters which can be considered to be similar to method parameters. Like a method (in a programming sense) does some work which can be tweaked or controlled by the method parameters, the effect of an Action can be affected by Action Parameters. In the car driving model an example of an Action Parameter would be whether the ignition could be turned on remotely (via the keychain) or locally. In that case we might want to add an Action Parameter to the model such as TurnIgnitionOn(Mode) where the "Mode" action parameter could take values "Remote" or "Local" similar to the way state variables can have different values.

A really interesting point that emerges here is that there is no one way to model the system. In the example above if for some reason you actually wanted to track how you had opened the car, maybe for a later stage in the model when you were actually locking the car then you would need to store this information in a state variable. Anytime you find yourself using the word "track" you should think about having that value as a state variable. We could therefore break our TurnIgnitionOn action into 2 different types of actions, TurnIgnitionOnRemotely and TurnIgnitionOnLocally and track how we opened the car as a new state variable, say S3, with values Remote or Local. Our model would therefore look something like this:

I will end this post with a word of caution. Even though it is quite easy to add a state variable to the model to track some aspect of the system, you should be very careful when adding state variables to your model and strive to minimize this number. The reason for this guidance is to limit the amount of state explosion that takes place as a result of defining these additional state variables. Remember that every time you define another state variable the number of possible states in the model is increasing exponentially. To keep your model manageable you should not add a state variable till it is absolutely critical to the behavior being captured.

UPDATE: Just noticed that this is actually my 100th post on this blog - WOW! Never thought I'd see the 100th post when I started out...it's been fun! :)

Elements of MBT - Part 2 – States and State Variables

nihitk — Thu, 28 Jun 2007 03:52:00 GMT

This is a continuation of the Elements of MBT series of posts which I started last time with Part 1 and covered what is meant by a model of a software system. In this post I shall be covering additional concepts which you will need to know to gain a better understanding of Model Based Testing.

One of the most fundamental concepts required to define a model of a system is that of State Variables which in turn are needed to define what a State is. A State Variable is simply some aspect of the system which changes over time. For e.g. in the car driving model, one aspect that changes (and which you care about tracking for the purpose you are building the model for) is whether the car is moving or not. So this can be a state variable, say "CarMotionState", which can have values such as "Moving" and "NotMoving". Couple of important things to keep in mind is that a state variable can have multiple values (not just 2 as in the example above) and that these "values" are really just semantic terms to help us define the model. What the actual values of these do and result in (especially from an automation point of view) is tied in later when you are implementing the code for the model.

A State then becomes much easier to define as simply a combination of all the State Variables in the model with particular values assigned to each state variable. Thus if your model contains 3 state variables S1, S2 and S3 with multiple values for each state variable, a state will be defined by a unique set of values for each of the state variables S1, S2 and S3. You can therefore think of a state as simply a snapshot of all the state variable values at a given point in time. From the Part 1 car driving model we can now see that the 3 states in the model are comprised of the following unique combinations of state variable values.

S1 = { IgnitionState = IgnitionOff; CarMotionState = NotMoving; }

S2 = { IgnitionState = IgnitionOn; CarMotionState = NotMoving; }

S3 = { IgnitionState = IgnitionOn; CarMotionState = Moving; }

One thing to notice here is that not all possible states need to be defined for a particular model. Depending on the system and the reason you are creating the model or the abstraction level you want to capture, you might not include certain states in your model. Or certain states simply won't make any sense to model such as the state "IgnitionOff" + "Moving" if you do not want to capture the behavior of the car sliding down hill when the ignition has not been turned on. The great thing though is that it forces you to think of that scenario and to consider if that is something you want to capture and if so then what the expected behavior would be.

In the next post I shall cover Actions and Action Parameters and update the model to add an Action Parameter to one of the actions.

Elements of MBT - Part 1 - What is a model?

nihitk — Sat, 24 Mar 2007 03:54:00 GMT

In this series of "Elements of MBT" posts, I will be covering some basic concepts used when trying to build models of software systems for use in Model Based Testing. The aim is to give an explanation of the various elements involved in defining a model of a software system and hopefully this should get us on the same page and allow us to explore the complexities in more detail.

Let us start by going over what we mean by a "model" of a system. Put simply, a model is a description of the system and is much simpler than the actual system itself. What this means is that the model hides a lot of the details about the system and hiding these details allows us to work at a higher level of abstraction. For e.g. a simple model of driving a car could be:

One thing to keep in mind is that there is no perfect model of a system, since the same system can have completely different models depending on what you plan to use the model for. Are you creating the model of a system simply to capture the behavior and requirements of the system? Are you creating the model to auto-generate the code for the model implementation itself? To describe the data flowing through the system? Or are you generating the model to actually test a particular portion of the system?

A quote which captures this unusual thing about models really well is as follows:

All models are wrong; some models are useful.
- George Box

What is worth hanging onto from this definition is that a model that you create should strive to be "useful" more than anything else. It might be rough round the edges and might not tell you everything about the system (for e.g. you don't know from the above model how the gear is to be changed or what happens when a gear is changed) but if it is useful for the purpose it was created it is a correct model.

Another aspect of defining a model is the notion that the model should help predict what the behavior of the system would be under certain conditions. So if you are in the "Not Moving" state and you "ChangeGearAndAccelerate" then you reach the "Moving" state. Are there certain assumptions in the model? You bet there are! Such as assuming that the ignition is on, that the car has wheels, that the car is not hanging in the air, that there is oxygen in the air, we can go on and on and on. The hiding of these details and assumptions is what helps us look at just this behavior we are capturing. If anything is important for the purpose (say testing) for which we are creating the model, we should consider adding that detail into the model. So if we thought that it was important to know whether the ignition was on or off we would change the model to capture this as well.

Now we know that if you are in the "Ignition Off" and "Not Moving" state then if you "TurnIgnitionOn" you reach the "Ignition On" and "Not Moving" state since simply turning on the ignition does not cause the car to start moving in the model that we have created. To start moving you will need to "ChangeGearAndAccelerate" which should take you to the state of having the "Ignition On" and the car "Moving".

Hope this gives you an idea of what a model contains and what it can be used to capture. In the following posts we will look into each element of a model in more detail.