Automation in the Agile World

Automation in the Agile World: Agile movement happens not just in the development processes, but also in testing. Test automation is no exception where it moves from being a subset of testing to supporting the life cycle as a separate pillar on its own. The world today is growing more and agiler as we speak. Not just in terms of the processes, but also in the attitude and thoughts which form the cornerstone of any company.

Product-based organizations are trying to adopt the agile process of software development and move away from the traditional waterfall-based models’ thanks to quicker time to market results through agile. ‘Trim the fat, Cut the flab- Stay lean, Stay Agile’, screams a billboard. No, not outside a high-tech gym, but inside the work cubicles of an organization recently adopting the agile model of software development.

Agile World Defination

Wikipedia defines agile as 

a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.’

There are multiple techniques of agile like Scrum, Kanban,  extreme programming, etc. There are unlimited resources on what these techniques are, how to use them, and what the pros and cons of each are.

Traditional method of Automation Approach

Traditionally automation starts from manual test cases. One selects ‘automatable’ cases from a manual regression test plan and proceeds to automate them on an already developed platform. There is limited interaction between the automation testers with anyone other than the test planner.

He/she works in a silo and delivers in sync with a fixed timeline (estimated through traditional techniques) where all the factors are controlled and there are no anticipated risks. Most times, the automation tester is not expected to know the functionality of the application under test.

This approach has worked well under a controlled environment, where there are defined phases of software development and test automation can afford to take it nice and slow. However, in an agile environment, the disadvantages of this method of automation are obvious.

• High Maintenance: Automation follows its own lifecycle of delivery, after the actual development of the application itself. It also goes through the same waterfall model of scripting, unit testing, and feedback. By the time the scripts are ready to be replayed, something in the functionality would have changed in agile and would need to be maintained.
• Slow turnaround time: The value of automation is always in a replay. In the traditional method, there is more focus on the actual development, than the timely replay of the cases. This is because the code check-ins are mostly not on a daily basis. In agile, it becomes a given that the scripts need to get integrated with some build server to provide value through daily replay, or in some cases more than twice a day.
• No focus on functionality: Tester ends up translating step to step, a manual test plan to a working code without understanding the meaning or value that he/she is actually bringing to the lifecycle. This is an unwanted side effect of working in a silo. This also sometimes leads to an ineffective selection of cases/steps for automation. This has disastrous consequences in agile since there is absolutely no time to make mistakes and unwanted script maintenance is very costly.

Automation in Agile World

When development becomes agile, it is just not possible for traditional automation models to work in such a changeable environment. The basic expectation of needing a stable complete application is in itself a questionable assumption in an agile environment. The very definition of agile challenges this need for automation. How then can one automate in flux?

Change in Attitude

Agile is an attitude, not a technique with boundaries – Alistair Cockburn, a pioneer in the agile movement. The prerequisite for a person moving to agile automation is a lot of unlearning and re-learning. There is no more primary contact for an automation tester.

He becomes part of a scrum (if that is the methodology adopted) where there is constant interaction with the product owner for functionality, developer for technical detail access, tester for scenario supply.

His thinking needs to be agiler, his main focus needs to shift from just automating cases, to ensuring module stability, code test coverage, continuous integrations, and other value propositions.

Change in Process

Process movement from waterfall to agile is inevitable in test automation. Scrum methodology warrants daily stand-up calls, Sprint planning meetings, Inspect and Adapt processes, Sprint demos, retrospectives, etc. (Reference: https://www.atlassian.com/agile/scrum).

An ideal process for automating would be to have one more role defined as an ‘Automation tester’ who is aligned with each of the Scrum teams, understands the functionality, identifies what to automate, and automates them. An extrapolation of this approach is to have the scrum tester double up as an automation specialist so that there is more control over what gets automated to derive maximum value from the act.

Automation Specialist Role

The role of an automation specialist is not restricted to just delivering automated scripts on a daily basis. By virtue of being so involved in a scrum team, sooner or later, through automating certain pieces of code as and when they are developed, this person becomes the benchmark for the developer to create ‘testable code’.  This, in turn, increases code quality.

Service Automation

Most of the business functionality of products is built around the services which sit between the UI and data layers. These services can be industry-standard formats like REST, SOAP, or proprietary to the technology on which the product is built. It is important to look at this layer for functional automation.

Much has been written about the test automation pyramid which has Unit testing in a lower layer, Service in the middle, and UI at the top layer. Product APIs, especially in agile, change in the blink of an eye. In such a changeable environment, service automation needs to be part of the automation backlog for ensuring the scripts can be used for longer cycles without too much maintenance.

Doing service automation from a traditional standpoint is not a piece of cake, mostly because there is very little interaction between the developer and automation tester. But, in agile, if some service endpoints are not clear, the developer can expose them for automation.

In some cases, this makes the services more consumable, not just by third-party tools, but also by other channels (clients) who may consume the services. Ultimately, automation in agile adds tremendous business value to the organization by addressing some of the undisclosed pain points.

Continuous Integration

‘Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.’ –  ThoughtWorks.

CI is the ultimate aim of any task. Once the check-in happens, did the previous functionality break? If so, can one catch it early? There are a lot of automation techniques borne out of this intention. Test-driven development (TDD) is one such technique where tests are written for the new functionality so that they initially fail before the actual application and then pass after the development. Then the test goes through a refactoring process to refine further.

Whatever be the technique, the final aim is to integrate the tests into the build process where it gets picked up and run after the area is refreshed or code is checked in. Simplistically, if all the cases pass, it indicates the check-in has not broken the existing functionality, a failure indicates the reverse and needs further investigation.

Now, the new functionality tests developed through TDD or any such techniques are now integrated as part of the build. The cycle continues. What is mentioned here, is but the tip of an iceberg. There are so many ways in which automation needs to change with agile, in quantitative, qualitative, and sublime terms.

Conclusion

Agile process change has now pushed automation to mainstream development as more and more people are beginning to realize that development happening at a steady quick pace needs to be complemented with ‘quick’ and ‘repeated’ testing of the same. Both need to be achieved only through automation, and not just any automation – Agile test automation.