|Introduction to Action Based Testing / ACTION BASED TESTING|
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.).
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.
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.