Model Based Testing nicely deals with modern development methodologies. But also in traditional development projects, this way of testing has many advantages over other testing methods. However, this is highly dependent on the way we organize our MBT testing process and what role is played by the tester. Should the tester blindly assume an already established model or should the tester be responsible for the preparation of the test model?
Increasingly, we see that Model-Based Testing (MBT) is used for software testing. This is a logical step to keep our value as a functional tester high. As a tester, we simply can no longer carry out testing as they previously did, which was accustomed to the traditional development processes. No, especially if we look at the contemporary agile development processes, as a tester we must anticipate the new ways of working. Project properties such as interactive, iterative, incremental and multidisciplinary must therefore be consistent with the current test approach. MBT deals nicely with that, provided that this new way of testing is applied correctly.
The benefits of applying MBT are now known. Thus we can, through the proper use of MBT, address any "open ends", ambiguities, inconsistencies and errors in the requirements, at a very early stage. This will shorten the duration of the project and improve the quality of the software. Another great advantage of MBT is the flexibility and adaptability of the test set. If changes occur in the requirements, we merely need to adjust the model and then we can generate a new test set automatically. This automatic generation of the test set is another great advantage of MBT. The condition is that we have the proper tool.
With regards to the above, I would emphasize that MBT is the modern way of testing and has many advantages over other testing methods, but this is highly dependent on the way we organize our MBT testing process and what tool we are using.
If we look at the traditional development processes, we see that the tester has an independent view on the test basis. Think of the V-model, it shows that the basis for technical testing and development is the technical design and that the tester will use the functional design to set up the test set for the functional test. Precisely this will effectuate an independent view of the tester and any interpretation errors in the requirements will be observed. The tester can make no assumptions and all the required information to establish the tester himself collects a thorough test set. But how does this work in MBT? Is a tester also able to maintain an independent view and does the tester have a clear field to complete the test basis, without making assumptions? The answer is yes, as long as the tester is able to draw the test models himself.
We too often see that within MBT the models that are used to generate the test set are too technical, static or poorly readable and these models have not been produced by the tester itself. Who can say the author of these models has made no mistakes in the interpretation? Who takes care of updating the models after an update in the requirements? Do all project members, such as the tester, product owner, etc., understand these models? Are all test situations captured in these models? And perhaps more importantly, are these models so arranged that for the generation of the test set, a test algorithm can be used, based on the desired test coverage?
The solution to the above-described problems is simple. In MBT, the functional tester must draw the test models. The tester should then evaluate these models with the team members and business and where necessary adapt the model. Just as the functional tester composes the test set within traditional development processes. With this, the functional tester preserves an important independent perspective, these models are world-readable, these models are easy to adjust by the tester itself and these are really test models. From out of these models, now the test set can be generated automatically based on a test algorithm, taking into account the desired test coverage. The tool, which will be used, must be adapted to this. The tester itself must be able to draw the test models in the tool and the tool must automatically generate the test set based on different test algorithms (test coverage).
The conclusion is that for functional testing, MBT perfectly fits to modern development processes, but that the value of the functional tester is even greater, with a correct insertion of this method.
We have developed a tool called DTM Tool, which is based on this methodology and helps functional testers to auto generate the test scenarios.