This post was initially posted on LogiGear’s blog, and I decided to make a copy for my record.

Generally speaking, test automation means doing functional testing through the UI. However, non-UI automation tends to be easier and more inherently stable and should always be looked at in addition to UI automation.

You may struggle with understanding automated tests' logic if you are a non-technical person, like a Business Analyst or project manager. The test doesn't expose any business logic of the application under test (AUT). Instead, its steps link directly to the AUT's UI, and it's eating up your time chasing what automated test does instead of giving you the results you need. So you properly want to redesign these tests to make them readable. But, of course, you still wish to them automated and runnable.

Sounds good, right? You can easily do this with Action Based Testing. Action Based Testing is a modular-design and action-driven test method that provides a systematic approach to increase the success of automated testing. The modular design addresses test planning and case management challenges through efficient test organization. Action-driven test development eliminates most programming work required to automate and maintain long-term tests. This alleviates the need for a technical testing staff.

Here's how to create readable automated tests with Action Based Testing methodology:

Action-Based Testing Design Process

In Action-Based Testing

  • The focus is on a modular approach, where tests are organized in test modules, each with a clear and differentiated scope. The test cases in the module consist of sequences of "action lines," each starting with an action keyword (short "action") with optionally one or more arguments.
  • The automation efforts focus on automating the actions rather than the tests.
  • Actions shift the focus from technology and instead place it on test design as the critical driver of automation success. In other words, a clever automation engineer alone is not enough to fix a situation where tests are poorly designed.

Modular planning

A top-down planning approach creates a logical test flow that results in more efficient test creation.

It also facilitates developing test cases free of unnecessary details or redundant checks that make tests challenging to debug and maintain when the application under test changes.

Test module design

Test Modules are containers for organizing tests — typically around user stories or software requirements. Test Modules increase the efficiency of test development by providing a well-defined test case flow.

Tests within a module can have interdependencies, but test modules are intended to be independent of one another. This simplifies maintenance and allows different project parts to be parsed to other teams without impacting the overall test project.

Action-driven test authoring

Actions are keywords in which most of the programming work of automating tests is separated from the actual test design.

Actions create a plain text business-readable domain-specific language to optimize test automation production. This mini-domain-specific language is called Action Based Testing Language (ABTL) that follows an activity >> outcome syntax.

Tests consist of actions specifying activity followed by the outcome. This makes it possible for testers to write tests using one or more actions rather than lengthy scripts detailing operations and checks.

Final Thoughts

Action-Based Testing is a modern approach to Keyword-Driven Testing — the test development method we all know and love. It represents the continued evolution of the keyword-based testing approach. Moreover, it unlocks the ability to create readable automated tests by non-technical.