Behavior-Driven Vs. Model-Based Test Automation
Learn about the differences and why we believe a behavior-driven approach is appropriate for many enterprise applications.
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.
Challenges With The Model-Based Approach
We see several potential problems with the model-based approach:
- Firstly, 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.
- Secondly, 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.
- Thirdly, 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.
How Is Cycle's Behavior-Driven 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.
Accelerate ROI With Cycle
Cycle’s modern and approachable UI allows test case documents to 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 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 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.
Learn more about test automation for your application
Contact our team to learn more about how Cycle can benefit your business, and request a demo today.
"*" indicates required fields