Whenever I explain my work in detail, people often respond by saying that model‑based testing is “the wave of the future.” While MBT tools continue to mature and new solutions enter the market, the underlying concepts and practices have been around for more than two decades. I’ve personally been implementing and managing MBT projects for over 10 years.
There are several “flavors” of model‑based testing, and I’ve had many in‑depth conversations about the differences between “model‑centric,” “model‑driven,” and “model‑based” approaches. That’s a complex topic of its own, so I’ll save it for another day.
For now, when I refer to MBT, I mean the practice of creating a diagram that represents the intended behavior of the implemented system, then using a structured, repeatable process to generate tests that verify whether the system behaves as designed.
Because MBT has been around for some time, researchers such as Anne Kramer and Bruno Legeard have compiled valuable statistics on its adoption and effectiveness. I referenced several of these findings in a recent webinar, Model‑Based Testing Using Cause‑Effect Models. What stood out to me most is that the vast majority of survey participants reported that MBT either partially or fully met the expectations that led them to adopt it in the first place.
Example of a model of a business rule as a logic diagram that can generate test cases.
Cause-Effect Model of Intended Behavior
Question 3 from the 2019 MBT User Survey
One statistic that I didn’t mention in the webinar that I’ll point out now is that the overall number of hours reported to achieve maximum value from MBT has dropped 75% from 2014 to 2019!
I believe there are a few of reasons for this:
- The goals and benefits of MBT implementation are better understood by users
- Increased management buy-in, resulting in more support for those learning the process
- MBT tools have improved, shallowing the learning curve
So, the people who are using an MBT approach to testing are getting what they expected out of it and the reported amount of time to attain maximum value is significantly less than it was just five years ago; both great things.
What do these statistics mean for organizations who are looking to adopt an MBT approach to their testing?
In the aforementioned webinar, I discuss a long list of advantages and benefits that come along with the MBT approach, so I won’t rehash those here.
Instead, I’ll focus on what adopting MBT really looks like and share some of the experiences I’ve had in helping many of our customers develop their MBT capabilities.
The first thing I call out prior to starting an MBT project is the set of expectations. In my experience, there’s an assumption that implementing MBT is simply a matter of handing a new tool to the testers and expecting them to hand back a test suite and a big list of defects they detected and prevented. This is simply not the case.
If the HR department of an organization changed their time tracking and time off system, there would be an entire initiative to retrain the users and those impacted by the change (management, accounting, up- and down-stream vendors). The same has to be true when an organization changes the way they develop the tests for their software.
You see, MBT is a process, not simply a tool.
One of the crucial aspects to a successful MBT approach is collaboration. Collaboration has to happen at every step of the process to achieve the maximum value to all involved. This collaboration is not solely for the benefit of the tester; in fact, the opposite is true.
By creating a model of the desired system or application (or of a change to the system or application), you create a view of the system that allows stakeholders of nearly any role, expertise, or technical skill level to engage on the same level. In other words, you’ve created a layer of abstraction that encourages people to think in terms of ‘What’ without getting bogged down in the ‘How’.
In order to enjoy stakeholder communication benefit, the expectation must be set that collaboration will happen early and often in the development process. The ‘hurl these over the wall and have QA test them’ mantra simply doesn’t work.
One great thing that this collaboration allows teams to do, and I’ve seen this first hand with the successful MBT adoptions I’ve been a part of, is to use the model as the starting point when someone has an idea for a new feature or a change that they think will improve an existing feature.
Rather than trying to define their idea in a text-based artifact (requirements, user stores, use cases, etc.), team members will get into the habit of using the model to draw a picture of their idea as their starting point. Sharing an idea in the form of a model is a very effective way to convey the idea and at the appropriate level of detail.
This ability to go from idea to a minimum viable product to a fully functional, completely fleshed out definition using the model as the layer of abstraction saves time, saves effort, and eliminates rework.
I’ll talk more about the process of going from idea to completely defined product in the second episode of our Model-Based Testing webinar series, which you can register for here (or view on demand if you’re reading after the date of the webinar).
