As a software tester, I find that using models is very helpful. Models allow us to understand a business process or how a system should behave in a given situation. In my practice of software testing, I keep sketches of a system’s behavior in various forms: UML, data flow, flowchart and so on, while learning a new solution and then translating these sketches into Excel in one big diagram. This has also provided a great tool to confirm my understanding of the system’s functionality with business users and developers. I always wished there was a way to generate/develop the test cases straight out of my diagrams…
With model-based testing, the model of the system’s behavior is made explicit (not only in the tester’s head for a brief time) and used as the basis for complete automation of testing. Based on my experience, model-based testing is both easy and complex due to unfamiliarity with the tools chosen for this research. I started researching model-based testing, its background and where it is today in the world of software testing. Harry Robinson, one of the proponents of this technique, has used model-based testing in AT&T Bell Labs, HP, Microsoft and recently Google (https://www.nap.edu/read/10695/chapter/15). Surprisingly, model-based testing is not as widely used in North America as it is today in Sweden, Estonia, Germany and many other parts of Europe where they hold annual user conferences and various user groups.
Model-based testing is an approach based on creating test cases from models describing expected behavior (usually functional) of the system under test. I thought this was a nice testing concept but the question is: how is it executed and how effective is it? A wide range of model tools can be used in model-based testing but, for this research, we chose to explore a modeling tool (yEd http://www.yworks.com/en/products_yed_about.html) and a tool that will enable test case generation from the models (GraphWalker http://graphwalker.org/) that are created.
Learning the modeling part is simple, although it requires a different way of thinking. Perhaps many of us are more familiar with flowcharts – model-based testing uses the theory of finite state machine. A finite what? A turnstile is a classic example of finite state machine. It has two states, locked and unlocked, and there are two inputs that affect its state, the coin input and the arm pushing input. In the locked state, putting a coin in the slot shifts the state from locked to unlocked and a person pushing through the arms shifts the state back to locked. Once you have understood how to model, it becomes easy. However, like any testing preparation activity, modeling can be time consuming but a well-designed model is invaluable.
The next step in model-based testing is the generation of test cases from the model. This can take a long time to set up and get running – and involves a lot of trial and error in fixing the model. After getting past this hurdle, the next challenge is how to verify that the generated test cases are correct. This has led me to research and learn the basics of various algorithms that the tool uses to create the test cases.
The tool generates test cases by traversing various paths outlined in the model and uses combinations of parameters on how test cases should be created. Because model-based testing generates test cases from a model based on functional requirements, it is easy to change them when the requirements change. A simple adjustment in the model can generate new test cases. Testers’ time can be used more efficiently by executing test cases rather than manually maintaining them.
Model-based testing has already proven its worth and, even though it will not be the right solution for all projects, it is worthwhile exploring in more detail how much value it will add and what testing skills will be required to perform model-based testing. With the basic concept of model-based testing presented in this article, are you interested in using model-based testing? What types of application would you like to see it being used on?