Multi-Station Testing with Actions—The Lead Deputy Model
Today I want to share a model we use for "multi-station" testing in Action Based Testing. Action Based Testing is a method for defining and automating tests. It relies heavily on designed tests in such a way that they are easily readable for humans and at the same time are fully automated in a maintainable way. To do this, tests are organized in "test modules" as a sequence of keyword based "actions." I have written about this in various articles, including in Better Software Magazine (March 2011).
Let's take as an example a system for bank tellers. These are the friendly people in the bank offices who can help you with transactions, such as depositing checks or withdrawing cash. A typical action based test could look like this:
Notice that the test is written in business terms. You don't see UI details; you aren’t able to distinguish from this test what the platforms for the application are, such as web based, .Net, Java Swing, classic mainframe, etc.
Note: A key recommendation in Action Based Testing is to keep such business tests completely separate from "interaction tests" that verify whether a user—or other system in case of non-UI—can interact with the application under test. Such tests will have more detailed actions, such as "select list item" or "check window exists."
Now let's make the case a bit more complicated by adding that if a requested withdrawal is larger than $10,000, a supervisor needs to approve it. This supervisor can do this from his own workstation.
In this example, "deputy machines" are used. These work like normal test machines; they are able to interpret and execute actions but are in a special mode and listen to commands from the lead machine—or possibly another deputy machine. They also have a temporary logical name assigned to them—in this case "supervisor." Notice that a transaction number is kept in a variable "tx" that is made available to the deputy (">>" is a variable assignment, "#" denotes an expression).
A variation on the model is to allow deputies to work in parallel. For example: Letting a deputy load a large database while the lead machine does some more UI interaction, such as logging into the application. To do this, we have an extra argument "parallel" for "use deputy,” and additional actions "wait for deputy" and "wait for all deputies" to specify when the lead and the deputies should meet again.
I hope this shows how actions can be used to make a relatively complex task like multi-station available at a business level where even non-technical users, such as business domain experts, can easily understand the thought process. The examples included here are logical models. We have implemented them in our own automation framework (TestArchitect), but it is not overly complicated to support them in other automation frameworks as well.
