Visual ATDD – Model-Based Testing en Agile

You’re probably familiar with this scenario: at the start of a new (school) year, we make resolutions. One resolution that has gained popularity, especially in the post-Covid era, is “exercise more.” However, as daily life takes over, we become occupied with various tasks, leaving little time for our resolutions. A year passes, and we realize that we should have focused more on physical activity. The resolution hasn’t been forgotten; it just hasn’t been implemented consistently.

The same applies to the good resolutions in Agile. In our specific context, the resolution is called “Shift Left.” We recognize the importance of addressing testing as early as possible. Why? First, it ensures that testing doesn’t fall short at the end. Second, when test design begins, it often reveals inconsistent, unclear, or missing requirements because someone is systematically and critically examining those requirements. Once identified, open issues can be clarified for the entire project team, increasing the likelihood of preventing defects from occurring.

The most prominent form of “Shift Left” is Test-Driven Development (TDD), a concept that applies to software development and related unit tests. If we look at functional tests, we discover a slightly different approach called Acceptance Test Driven Development (ATDD). Its best-known representative is Behavior-Driven Development. Instead of further refining user stories with textual acceptance criteria, we write acceptance test scenarios right away. These are usually written in the semi-formal Gherkin syntax (GIVEN-WHEN-THEN), because this way they can be read in and automated.

Visual ATDD for Epics and Features

Gherkin scenarios are well suited for user stories, but less so for entire features or epics. This is where model-based testing comes in. Its core idea is to graphically represent the test flow, add necessary information regarding the test of each action, and then use a test case generator to create those test cases that are required for a particular coverage. The test case generator collects all stored information on the path through the workflow and compiles – depending on the tool – abstract or concrete test cases, test procedure specifications and/or test scripts for automation.

The previous paragraph contains a very important piece of information that you should not overlook. The test sequences are modeled, not the system! In the past, MBT was often understood as the reuse of existing models from the product design phase. However, as the name suggests, Visual ATDD clearly places the test at the beginning of the development. As with BDD, the system is specified by the workflows, the information stored in the model and by the test scenarios generated from it. ATDD is also referred to as “Specification by Example”. (The other MBT approaches still exist. They are also “Visual”, but do not ATDD.)

Why is this important? Because we all suffer from a chronic lack of time. Even if this should not be the case, there are still the many small things mentioned at the beginning… Be it self-protection our inner laziness, we resist every task that seems even remotely overhead. Why should I create a model if I only need test cases in the end? Why waste any thought at all on a structured test design if we end up automating everything? Away with it…

As with BDD, in Visual ATDD we describe the system using the examples provided by test specifications. This way, every team member knows what is expected or what will be waved through as acceptable in the end. Unlike in the case of reuse, in Visual ATDD there is only one model, that is the test model. This avoids redundancies and the difficulty of having to keep two models up to date in parallel.

Since the tests are generated from the model, there is a high incentive to keep the model up-to-date. However, the temptation remains to simply maintain the tests manually once they have been generated. This is where tool support is essential. The visual test design tool Yest® from Smartesting is a true tester’s IDE. Numerous functions such as auto-completion, propagation of changes, impact analysis, advanced search functions and many more make the tedious work of test case maintenance easier for testers.

But back to Visual ATDD. The (thanks to Yest®) always up-to-date model represents a living documentation of the product. Newcomers to the project benefit from it just as much as old hands who want to look up something from three months ago.

The idea of test-driven development was that many problems are noticed before they are “burned into” the source code. But this only works if we really start early with our test design. Visual ATDD allows a top-down approach, starting with the general flow of actions. Details are added as soon as they become available. If necessary, the workflows are extended sprint by sprint by the 3 Amigos. The model thus grows iteratively and incrementally in a truly agile way of working.

From a technical point of view, Visual ATDD does not differ from “traditional” MBT. It is organizational aspects that make the difference. In order to work in a test-driven manner, the test must really be placed at the beginning. But this also means that, if necessary, the service providers are involved at an early stage. The advantages are obvious. Quality increases intrinsically due to the significantly improved communication made possible by the clear, graphical representation. Appropriate tool support from Yest® ensures that it is easier to update models than to revise existing tests. That’s how things come full circle!