The essential elements of Action Based Testing, apart from test modules, are the actions. An action is a reusable container housing a series of operations and checks.Instead of specifying such operations and checks in detail in the test module, the tester can specify one or more actions.

Actions have arguments that define input values and expected outcomes. The arguments have names that appear as headers in the row above the action line, for instance:

Actions are best regarded as a byproduct of the test design. The testers essentially define the actions and their arguments, although it makes sense to discuss them with the automation engineer before using them on a larger scale.

Actions need to be organized and managed well. In particular, one should take pains not to have more than one action for more or less the same operation. Actions also should be clear and unambiguous and be well documented (meaning, arguments and their default values, etc.).

A few practices that can help:

Many system-level actions, such as click, enter, and check are built-in in TestArchitect. Such actions are usually generic, which means that they are defined for a wide range of UI objects. For example click works on a button in a window, but also works on a hyperlink in a web page.

Those actions that are not available as built-in need to be implemented. In particular, in larger test teams it is generally not advisable to let the testers implement the actions, but instead to leave this to a small group of specialized automation people. The automation process can best be organized as a separate track in the overall automation project, with its own planning, teams, and deliverables. In many projects, tests are finished well before their actions are automated, in particular since the application under test might not yet be available.

The most straightforward way to implement actions is to program them in functions in a programming or scripting language. This goes in the form of an action interpreter that in Action Based Testing is called a harness. In TestArchitect the harness can be done:

In both cases you use the functions of the Action Based Testing library to do things like retrieve an argument of the action or register a result of a check. This is usually called the engine. Examples of working harnesses are available as part of your TestArchitect installation (refer the Lesson #8: Using an automation harness section for details).

Action Based Testing also has an alternative mechanism to implement higher level actions, called action definitions. They allow the automation person to define the workings of a new action using existing actions. For actions that do not contain complicated technical functionality, this is often the preferred way, since it is generally more accessible than programming code.

Copyright © 2021 LogiGear Corporation. All rights reserved. LogiGear is a registered trademark, and Action Based Testing and TestArchitect are trademarks of LogiGear Corporation. All other trademarks contained herein are the property of their respective owners.

LogiGear Corporation

1730 S. Amphlett Blvd. Suite 200, San Mateo, CA 94402

Tel: +1(800) 322-0333