14 Dec Creating a Tool Agnostic Strategy for Test Automation

Test Automation is a key player when it comes to releasing software to Production at a fast speed. The significance of Test Automation can by no means be negated and it has been adopted widely in the modern software industry. The successful Test Automation strategies however have been few and rare.

Test Automation decision usually starts when a business or product owner’s wants to save time and effort on testing and also have improved confidence in frequent releases to Production. Often times this leads to the next step, which is the choice of tool. In my opinion Tool is, if not the last, a more “later stage” decision in the journey of Automation development.

An efficient test automation strategy can be a 4-staged process:

1. Initiation & Feasibility
2. Test Design
3. Development
4. Support & Maintenance

1) Initiation & Feasibility:

This stage should be exploring the following:

1. What are the current pain points or problems I want to resolve with Test Automation
2. What are the risks associated with NOT doing test automation?
3. Who is the benefiter from it and who pays for it?
4. Who are the RACI (Responsible, Accountable, Consulted and Informed)?

…… and the list can go on. This is a very thorough and detailed layout of the planning stages, keeping in mind that most of the work done in this stage will not only help those who need the test automation but also those who have to approve or pay for it.

The output for this stage is a strong business case of why or why not the Automation is utilized for the testing. It should be considered a fairly normal event to reject the feasibility of Automation based on the questions above (or more).

2) Test Design:

Risk should be a fundamental element in the test design. This stage is critical and the lead time should not be rushed. A well planned and architected design defines the many stages in future that will make this automation as a success or failure.

One thing I have always advocated for the Automation Architects is not to design the automation against the manual test cases completely or worst against what is asked for UNLESS that is the right decision as per the Architects experience. Most of the times there are projects who want to rush automation or there is an unavailability of fresh test cases and the Architects have to find their way through poorly documented or obsolete test cases or documentation. In this case sufficient time is invested by the Architect to “explore” the application, maybe conduct a PoC to ensure the technical viability of the required scenarios.

The choice of framework is determined based on a scalable solution in this phase and must not be undermined. This choice will define the long-term maintenance for the automated test cases

3) Test Development:

My perception about this phase is that if sufficient time and effort is spent in 1 and 2 then this is the fastest stage. The risk and business case for Automation had already been developed in the initiation phase and the architecture of the upcoming test cases has been refined in the design stage.

This stage directly deals with the choice of Tool. Either you choose a low-code platform or a code/programming intensive platform, the concept and the intention for Automation should not change. The developer or scripter must not (ideally) spend any time in investigation or design, as that information should naturally be provided to them.

Coding standards or Best Practices are the keywords for this stage. Wherever possible the best practices and standards must be implemented which may vary for any specific tool. Fortunately most of the modern tools provide options for implementing these whether they are at the test case level, test data level, for test environments etc.

4) Support & Maintenance:

This is the stage for which 1, 2 and 3 are done. This is a never-ending phase in a perfect world. According to an opinion, the real value of test automation is achieved after it has been executed for at least 5 times in the intended test environment.

To make the maintenance as low costs, the design, coding standards, best practices etc. all play a pivotal role. Most of the times, the personnel who are involved in the development stage are not the same as those who own the maintenance. The style of development should be as standardized as possible. The only true intention for this phase is to keep the automation running and never pausing, even if there are failures.

If failures are there it should be considered a good thing and not discouraged from reporting for the following 2 reasons:

• It is a real failure and must be fixed to remove the anomaly
• The test case needs to be updated hence it needs to appear on the metrics.

Now that we have laid out all the stages for implementing an effective Test Automation Strategy we can clearly see that it is tool-independent. Whether your tool is pre-selected or you have already designed your test cases and still not selected a tool for implementation, the Automation principles remain the same:

• Save time and effort for testing
• Cover the high-risk and critical business processes for testing
• Be able to maintain and reuse the tests over time

My argument in this article is that in order to make automation successful we need to fit the tool within the automation process instead of vice versa. There is no denying the fact that the tool is critical and even if you have a great test design but lack the platform to support it then it is of no use. The good news is, unlike the 90’s or early 2000’s, there are a vast variety of tools in the market, which can fulfill the needs of any test designs. From low to no code platforms to highly scalable tools, from no cost to expensive licenses, easy to maintain with modular design vs. self-maintenance required solutions, there are many feasible options that the teams can pick and choose.

Please feel free to share thoughts and comments in the feedback form below.