Agile methods are becoming more and more popular and successful for developing IT systems. Typical properties of an Agile method, like Extreme Programming, involve continuous user involvement and emphasize on the testing role (‘Users’ may be the actual users of the system you are creating, customers, or business analysts who provide the requirements on behalf of the end-users). Testing is positioned in Agile system development as a driver for system development, with tests often created before the functionality they are verifying.
At LogiGear we promote and support Action Based Testing (ABT), a very successful method for creating maintainable automated tests. In ABT the focus is on development of products called “test modules”, an activity that can be independent from system development. It has no specific preference on when in the life cycle those test modules are developed. That makes it easy to integrate the methodology into an Agile life cycle. In this article I want to give some perspective on how this can best be achieved.
In my view, there are the following ways to enter ABT into an Agile project:
- Closely couple test development to system development
- Keep test development as a separate life cycle and use an Agile approach to build the tests
- Hybrid approach: business-level tests are developed early; detailed, typically UI-specific tests are created in parallel with the development life cycle
Allow me to expand on each of these approaches:
- Closely coupling test development to system development would mean sticking to what most Agile life cycles prescribe. The tests, in the ABT test modules, are created together with users, whenever the life cycle needs it. The advantage is that this is highly recognizable as an Agile approach, and it allows for better interaction between users and developers, with tests serving as a means of communication.
- The alternative is to have a separate life cycle for developing the test modules. In my experience, this is the most common approach. This might be a good choice if there are experienced testers available who can work with the users to develop good and representative tests. Those tests are then input for the developers, who can still interact with the users, but have a finished product to work with: the test modules. This alternative is probably the more manageable one, since test development can have its own life cycle, and can be dealt with in an early stage when the users have room in their schedule. Another advantage here is that even if your software development cycle is following a traditional ‘waterfall’ approach, your test and automation development can still be ‘Agile’.
- The hybrid approach is in my view the most attractive proposition. In the test development life cycle for business level tests, the users and test developers can concentrate on the business process and business specific issues, like how to calculate a monthly premium for a mortgage. Then when the developers are ready to define the user interaction with the system the users can create tests like “if I click on a customer, I see a list of his/her account balances”.
No matter which alternative is used, I would make the following recommendations:
- Plan well, and make every effort to create good efficient tests, with a high level of re-use and automation
- Make sure participants know what is expected of them, and have the experience and knowledge to deliver their part
Agile methods are a relatively new phenomenon in the software world, with great promise and many early success stories. Carefully fitting testing into the Agile life cycle will improve both system development and test development, and lead to successful Test Automation.
