LogiGear CTO Hans Buwalda summarizes ABT’s advantages for agile projects with focus on the relationship between product and automation development life cycles, and the importance of test modules in test design.
Hans Buwalda, CTO, LogiGear
To address the challenges and fears of implementing automation in agile projects, LogiGear CTO Hans Buwalda presents Action Based Testing as the answer.
How can automated functional testing fit into agile projects? That is a question we encounter a lot nowadays. Agile has become more common, but functional testing often remains a manual process because during agile iterations/sprints, there is simply not enough time to automate it. This is unlike unit testing, which is routinely automated effectively. The short answer is:
- A well planned and organized test design and automation architecture
- Organize the test design and automation architecture into separate life cycle
In this article I will show how the Action Based Testing method can help you to do just that. Let me first introduce Action Based Testing, followed by discussing how it can make both test design and test automation fit the demands of agile projects.
Action Based Testing
There are various sources where you can read more about Action Based Testing. Let me summarize the key principles here that are at the core of the method:
1. Not one, but three life cycles
It is common to have testing and automation activities positioned as part of a system development life cycle, regardless of whether that is a waterfall or an agile approach. ABT however regards three distinct life cycles. Even though they have dependencies on each other, in an ABT project they will be planned and managed as separate entities:
- System Development: follows any SDLC, traditional or agile model.
- Test Development: includes test design, test execution, test result follow up, and test maintenance.
- Automation: focuses solely on the action keywords, interpreting actions, matching user or non-user interfaces, researching technology challenges, etc.
2. Test Design
The most important property is the position of test design. It is seen as the single most enabling factor for automation success, much more than the actual automation technology. In ABT, it is considered crucial to have a good “high level test design” in which so called “test modules” are defined. Each test module should have a clear scope that is different from the other and is developed as a separate “mini project.”
A test module will consist of test objectives and action lines. The test objectives outline the scope of the test module into individual verbal statements defining what needs to be tested in the module.
The tests in the test module (which looks like a spreadsheet) are defined by a series of “action lines,” often further organized in one or more test cases. Every action line defines an “action” and consists of an “action word” defining the action, and arguments defining the data for the action, including input values and expected results.
Note here the ABT test case figures, not as central as in some other methods. We feel the test case is too small and too isolated of a unit to give good direction to test development. Rather than having a predefined list of test cases to be developed, we like to make a list of test modules, and let the test cases in them be the result of test design, not the input of it.
Consequences derive from varying test cases and increase significantly during the creative process. Also, each test case can leave behind the preconditions of the next, resulting in a good flow of the test execution.
3. Automation
In ABT the automation activity is separated from the test development. Test design and automation require very different skill sets and interests. There might be people that are interested at doing both, which is fine, but in my experience that is not very common. Also it assigns ownership for “getting the test to work.”
In ABT the automation engineers will concentrate on automation of actions and making “interface definitions” to manage the interaction with the interfaces (user or non-user) of the system under test. This type of automation activity requires advanced skills and experience.
Read more in LogiGear Magazine
He is a pioneer of the keyword approach for software testing organizations, and he assists clients in strategic implementation of the Action Based Testing™ method throughout their testing organizations. Hans is also the original architect of LogiGear’s TestArchitect™, the modular keyword-driven toolset for software test design, automation and management. Hans is an internationally recognized expert on test automation, test development and testing technology management. He is coauthor of Integrated Test Design and Automation (Addison Wesley, 2001), and speaks frequently at international testing conferences.