Nowadays more and more test activities are being automated, especially when it comes to executing test cases. But what about the development of test cases? Are the test cases still being developed in a structured way with a certain test coverage and based on a well-considered risk? When there is a change in the test basis, are the test cases easy to maintain? If we are mainly focused on automating the test execution then what about the Shift-left testing approach? I believe that with Model Based Testing (MBT) we already have the answer to many of these questions. In this blog I would like to share my vision to you on this.
Model Based Testing
It is well known that Model Based Testing (MBT) has many advantages over other test approaches and that MBT offers a solution to automate the developing of test cases. This is very important because in the present there is no time to manually set up the test cases and work them out using the traditional test specification techniques. Despite the limited time, the goal remains unchanged; develop test cases with a certain test coverage in a structured way for the purpose of test execution.
If we, as testers, want to keep up with the ever-faster development cycles and still want to deliver the same test quality, we also need to automate the preparation of the test cases in the preparation phase. With MBT we can automatically generate the test cases from a model. And when there are any changes to the test basis, the maintenance is minimal. We only have to update the model and the test cases can be automatically generated again and again.
Shift-left test approach
Furthermore, MBT fits within the Shift-left test approach, which means that the test activities must start earlier in the Software Development Life Cycle (SDLC). By applying MBT you prepare a model in the test preparation phase and then derive the test cases from that model. With this you Shift some test activities to the left. By starting testing earlier, we ultimately ensure that we can provide feedback earlier and that we discover any bugs earlier in the process. Ultimately, any bug we find earlier is cheaper to fix, as also described in the well-known “Law of Boehm”.
But the question is if it is early enough? Even with a Shift-left test approach and / or MBT. Especially when we realize that about 60% of all bugs in production can be traced back to the requirements. To avoid these bugs, we will therefore have to start testing the requirements (static test)! Ultimately, the requirements are also the basis for developing and testing the desired software. So we need to make sure that this foundation is complete and clear. So that all stakeholders are on the same line even before we even start writing the first lines of code and testing it. Because before we know it the first bugs will appear pretty soon!
Early Model Based Testing (eMBT)
As described above, MBT fits perfectly within the Shift-left test approach. However, MBT is often started too late in the process or used in a way without the approach of testing the requirements, but purely to generate automated (executable) test cases. We will therefore have to apply MBT in a specific way, at the earliest possible stage. I call this test approach early Model Based Testing, eMBT for short. By applying eMBT you will break down the requirements at the earliest possible stage by modeling them by means of a so-called eMBT-model. Such an eMBT-model has a high level of abstraction and by drawing it up you will quickly encounter ambiguities, contradictions, open ends, questions etc. Which at this point you can then discuss with the stakeholders. When drawing up an eMBT-model, as a tester you will think differently about the requirements and you will put yourself more in the shoes of the final customer. You are currently testing the requirements in an exploratory-like way and already give meaningful feedback, namely feedback on the basis. In addition, an eMBT-model is a user-friendly visual representation of the desired situation and is readable for all stakeholders. So it is defintively not technical or difficult to read the model. The user-friendly visual representation of an eMT-model stimulates the communication between all stakeholders with the aim of achieving a shared understanding of what needs to be built and therefore also what exactly needs to be tested.
Tooling (TestCompass)
The eMBT approach does require a tool that supports this approach. For example, the tool must offer the possibility to draw a model with a high level of abstraction, like the eMBT-model. This not only increases the readability of the model, but by drawing the eMBT-model you, as a tester, are also forced to think about both the ‘happy’and ‘non-happy’ flow. Furthermore, the tool must have the possibility to include the questions and comments you have on the model. The tool which supports this eMBT approach is TestCompass. A Cloud based eMBT tool.
Example
Below an example of a type of eMBT-model from TestCompass, based on the following requirements (figure 1).
2 Comments
Rashmi Bhandari
How can we create models using the tool?
What approach should be taken to create the models and eventually the test cases?
Smira Cacace
Hi Rashmi,
Thanks for your question.
To create test models you can use TestCompass and select the tab ‘Model’. By simply dragging and dropping, you can select different nodes and place them on the canvas. It works very simple and intuitive. You can watch an instruction video via Tutorial How to draw a Test Model in TestCompass.
The approach on how to draw a test model, generate the test cases, run the impact analysis, etc. is explained in the other instruction videos on the website:
https://www.compass-testservices.com/tutorials/
Please let me know if you want some more info about TesCompass, the easy to use and early Model Based Testing (eMBT) tool in the Cloud.
Kind regards,
Silvio Cacace