Writing Tests: Action Abstraction
Keywords have become a popular way of writing tests. Over the years, I used keywords to devise a method called Action Based Testing (ABT) in which tests are written as sequences of “actions” represented with keywords. However, keywords are just a physical representation of actions, and there are other ways to do this.
ABT views test design as the central way to achieve both quality tests and maintainable automation. If, for example, a test case contains many detailed steps, it will be hard to maintain it, regardless of the technical skills of an automation engineer. Encapsulating detailed steps in higher level ones can improve maintainability and make it easier to read and write the tests as well.
In the ABT method, tests are written as a series of “actions.” Higher level actions are defined as sequences of lower level ones. Tests are organized in “test modules” to help organize them according to scope. The scope of a test module in turn gives direction on how detailed the actions should be and what checks should be performed. When the scope of a module is clear, non-technical members of a team can comfortably create matching test cases with little worry about engineering principles like refactoring.
In our practice, we use keywords to describe actions and their arguments. In our product TestArchitect, we have a spreadsheet-like editor for it, which in particular is popular with non-technical testers, such as testing professionals and domain experts—and actions are easy to manage and maintain this way. An example might look like this:
However, keywords are only a format, and there are alternatives. A simple alternative is using function or method calls, like EnterPayment("Fred", "$33"). It will feel more technical and less readable than keywords, but for smaller projects it may do ok.
Another way of specifying actions is as “shared steps” in tools like MTM. They do the job but can be cumbersome, because in the ABT action model every step would need to be a shared step. Also, when using steps, be careful with the “expected results” column. Testers are likely to populate that column for every step, resulting in many checks that do not fit in the scope of the test module and making the tests hard to manage and maintain.
A particularly elegant format for actions are Business Driven Development (BDD) scenarios. Actions can be written with natural language business level sentences that look like “when I make a payment of $30 to Fred,” which is easy to read and understand. However, in larger projects. BDD phrases can be hard to manage and maintain. To overcome this I made a conversion tool to translate BDD sentences into keyword driven actions—and vice versa. This helps combine the business level appeal of BDD with the manageability of keywords.
Regardless of the physical format, actions are a good way to think about tests and their automation. Making a good design will help manage both the tests and their automation.
