Full 1

Behavior-Focused vs. Model-Based Test Automation

Learn about the differences and why we believe a behavior-focused approach is appropriate for many enterprise applications.

Block

What is Model-Based Test Automation?

There are many companies that attempt to abstract the complexity of enterprise test automation by saying they are “script less.” The general understanding in the industry is that a “script” means programming and that means expensive personnel and high-maintenance. Most companies attempt to abstract the challenge of testing business processes by generating the script themselves and displaying a UI layer that feels more approachable than a traditional test script.

The most modern version of this approach is called model-based testing where the testing solution may scan a given application and produce a web-form style presentation layer that allows non-technical users to input test data without seeing any underlying scripting or coding. Sometimes, these solutions are smart enough to automatically adjust when the underlying system-under-test changes.

Home

Challenges with the Model-Based Approach

We see several potential problems with the model-based approach:

For model-based test generation to work, there is an implicit assumption that the solution must have already been produced. We would make the case this is too late in the game. We should be writing our test cases prior to developing the solution to ensure we are building the correct solution, not the other way around. Therefore, you need to write test cases prior to any development or configuration changes.

When the user who is testing the process is only looking at an abstraction of the application being tested, there is an immediate potential for communication issues to have developed. Usually, the person building/executing the tests in these scenarios is not the business user, and therefore, it is highly unlikely that the tester has a foundational understanding of the business process being tested. It certainly can’t be derived from a model-based abstraction of the system being tested.

Any “savings” derived from the scripts automatically updating could be lost knowing that somewhere, there should be time spent updating standard-operating-procedures to reflect these system changes, and therefore, someone is having to spend that time one way or the other.

Block

How is Cycle's Behavior-Focused Approach Different?

We believe the testing solution should encourage a focus on communication, business understanding, and collaboration to ensure the correct solution is being tested rather than focusing on trying to eliminate test maintenance through abstractions and automation.

Cycle is developed with behavior-driven strategies in mind and focuses on enforcing better communication through a specific set of behavior-driven activities and practices where teams verbally communicate, discuss, and develop test documents as a group before system changes are made. These same documents which are executable test documents provide significantly more value than a traditional model-based abstraction because they provide context, traceability, and understanding of the underlying process being tested.

Block

Benefits of a Behavior-Focused Approach

Cycle’s team-powered testing teaches and enables practices to shift testing left in the process so that business analysts and non-technical stakeholders can actively participate in real test case development.

The test documents can be used for regression testing by building playlists and group tests that can be run in serial or parallel execution via a task schedule or in integration with common continuous integration/continuous delivery (CI/CD) platforms like Jenkins or TeamCity. Cycle is the only behavior-focused testing platform on the market today that allows for authoring and execution of tests in the same approachable UI.

Cycle’s behavior-focused testing approach allows for readable test libraries that can be pre-built and shared so that teams don’t have to start from scratch. Our test accelerator packages, based on our readable testing documents, allow for teams to leverage our packages as foundations — to review them and make small additions or modifications to up-fit the tests for their system. This drastically lowers the barrier to entry and prevents developers from having to duplicate effort by building out test cases that have already been built out by other users or the vendor themselves.