Leverage Your Actions to Get More Out of Test Automation
Test design can contribute greatly to the creation of manageable and maintainable automation. Action-based testing is a methodology to design and organize tests to make them suitable for automation. In this approach, tests are written as a sequence of actions, each of them having an “action word” and any number of arguments.
What actions to use depends on the scope of the test. Typically there will be high-level business-oriented actions, which hide navigation details, and low-level interaction-oriented actions, which test whether the UI or API is working well. For example, a test that verifies an insurance premium calculation should not show detailed steps on how to deal with the interface to enter the mortgage details. Having high-level actions to address business functionalities makes tests more readable and easier to maintain.
Specializing tests can also improve their depth. Instead of testing login steps inside another test, you will typically dedicate a set of tests to do in-depth checks of the login functionality, but keep it within a high-level “login” action for all other tests.
Once you have defined and implemented the high-level actions, you get an additional opportunity to create less common tests. Here are some examples that you might consider.
In “soap opera testing,” tests are written as if they are episodes in a TV soap opera, which typically mimic real-life scenarios but are more exaggerated and condensed in time. It allows domain experts and even end-users to come up with stories that the application under test might find hard to deal with.
Continuous variation is a form of continuous testing where each time you run tests, you pick different ones or use different values and flows. For lower-level tests this may not be easy to organize, but tests with high-level actions would be good candidates for such an approach.
A step further could be something like “a day in the office” testing, where instead of running all tests in their own environments, you run tests in parallel, mimicking what happens in an actual office with multiple workers working on various applications with potentially overlapping data.
A technique we use frequently in our projects is the lead deputy model. In this approach you let test machines run in lead, or deputy, mode. A lead machine can send actions to a deputy machine to execute there, synchronous with the lead or asynchronously with rendezvous points. Letting multiple machines cooperate like this is not unusual, but the use of actions makes it easier to apply, in particular for nontechnical testers.
Another possible use for actions is model-based testing. A model can be used to generate test lines with actions, but you can also turn it around and use actions to define a model.
It is usually up to the teams to decide what tests to develop and how to organize them. Hiding detailed steps in actions makes their automation easier to maintain, and the high-level actions can be leveraged to define less common tests.
