English | EN 
This summer I had the pleasure to attend Sogeti’s test automation event in Darmstadt, Germany. The event brought together test automation professionals from different parts of Europe, from Denmark to Luxembourg, to share their test automation experiences, practices, tools and ideas. There is something special in meeting a person face to face who has previously been just a name in an email. There was also something special in the topics presented at the event. The organizers from CA/Broadcom had planned a model-based testing hackathon for us.
Model-based testing is the logical endpoint of model-based design. If the system under test can be adequately described as an abstract model, the abstract model can be used as the basis for creating test cases for the system. This means that the test cases can be derived programmatically from the abstract model. And this means saving time and resources.
The hackathon had a simple goal: design test cases for a consumer loyalty campaign using model-based testing. The tool Agile Requirements Designer was used for designing the models, creating test data and exporting the finished test cases. The system under test was a REST API handling the consumer loyalty campaign data.
The idea was to model the system as a flowchart. You can initialize variables and junction points to decide which variables lead to which paths and system outcomes. The same system can be modelled in different ways depending on how the system is viewed.
After a couple of hours of hacking away, our hackathon team had a working model of our system under test. It was a simple model representing the three different customer loyalty levels and their respective discounts. One benefit of the model came clear: that it is easy to read and share information with models. The model provides a quick overview of the system behavior at a glance. This can be utilized to quickly bring new team members up to speed.
After we felt good about our model, we used the tool’s path optimizer to find the minimum number of required test cases. These permutations were then exported to Postman. Using Postman, the thirty requests created from thirty test cases were sent to the REST API.
One potential problem with using models is mapping. How does the abstract model map to reality of the system? To me, it seems obvious that to gain the full benefits of model-based testing, one has to be rigorous and meditative in their development work. Creating a complex model with multiple pathways and conditions can lead to confusion unless well-maintained.
After the long day of hacking, we had a working model for the system. Before the event, model-based testing was for me, like one of those unfamiliar names in emails. Something I’ve known for a long time but haven’t gotten around to visit for a long time. Darmstadt was worth a visit.
