There are many different MBT tools out there. As discussed in my last blog post there are different types of models and knowing which modelling language you want to use is the first step for selecting a tool. I personally have experience with Spec Explorer (outdated), TorXakis (textual) and Axini (textual) and through research and discussions I became aware of a few graphical tools. In this blog post I will talk about some of these tools and their purposes.
“Shift left” is a common phrase made in the tech industry, and TestCompass has the MBT solution for that.
TestCompass promotes shift-left with the term “Early MBT”, which helps the user to think about testing as early as during requirements definition. It is an easy to use tool and will generate logical test cases.
It is especially powerful during the requirements phase. For test automation I would advice one of the other tools mentioned later in this blog.
https://www.compass-testservices.com/
Ever wondered how Spotify test their tooling? You probably didn’t expect that they use MBT. The test community at Spotify is a big contributor to the code of the tool Graphwalker. Graphwalker is an open source graphical MBT tool that is easy to use.
Although this tool is easy to use, users might need to be a bit more tech savvy because it has a more complex syntax than for example TestCompass. It is still a very powerful tool for shifting left, plus test automation is included in this tool.
https://graphwalker.github.io/
Complex systems are sometimes very hard to capture in an image. For example, in systems with a lot of data each instance of a variable could mean a different state in the system, resulting in state explosion and unreadable images. In those cases, MBT can still be applied but by describing the behaviour rather than drawing it out.
A tool created by the academic world, using the IOCO theory (Input Output Conformance). Test are executed on the fly to the SUT in random paths. TorXakis uses a combination of Haskell https://nl.wikipedia.org/wiki/Haskell_(programmeertaal) and Promela https://en.wikipedia.org/wiki/Promela for their modelling language.
It is open source and great for complex systems. Its language however is not the easiest to read, so this is a tool more suitable to technical test engineers and software developers.
Axini uses the same IOCO theory as TorXakis but the tool is productised into a MBT tool used at several companies in the Netherlands. Axini is also based on Promela, but this time in combination with Ruby. It has an easier user interface and the possibility to visualize the models during the modelling process.
This visualization enables the users to have conversations about their models with less tech savvy stakeholders, making an image to converse about risks, missed requirements, etcetera.
As mentioned in my previous blogpost, the automation step before MBT is writing test in a Domain Specific Language or in Gherkin. RobotMBT was developed to simplify the transition to MBT for environments already using BDD.
Gherkin is a language developed to talk with stakeholders of different technical levels, so it enables the shifting left as well. It also makes the transition towards MBT easier for environments that already invested in BDD.
https://github.com/JFoederer/robotframeworkMBT
In this blog post I showed a glimpse of the possibilities of a few of the available MBT tools. There are many MBT tools out there, each with their own strengths and limitations. Feel free to contact us if you want to know what would fit best for your company!
|
Kyra Hameleers Test Engineer |