_edited_edited.png)
Before planning any kind of strategy, it is a wise idea to ponder on WHAT are we trying to accomplish? WHO will be doing this? and HOW can we do this? Let us try to apply the same analogy while designing a test automation strategy too.
WHAT? is our goal? What do we want to accomplish by automation?
Do we want to accomplish Continuous Integration? We want to be worry-free when new features are added to the existing application. So, we want to implement a CI process where all check-ins will be integrated with the build and tested, as and when they are available(typically during end of the day).
Do we want to reduce the load on manual tester doing regression tests? The tester is occupied with new features testing, plus manual regression testing and has the responsibility of doing both these jobs faster and efficiently. Hence, we want to implement automation for regression tests so that tester can focus on new feature testing and release product faster.
Do we want automation for new features? In this scenario, developer and tester work simultaneously to produce features as well as automation test cases by the end of the sprint. This reduces technical debt and also supports tester with time for exploratory testing around new features.
WHO? is going to do this activity?
Developer — NO. Why? Performs coding to support new feature development. May or may not be interested/efficient in testing.
Manual Tester — NO. Why? Performs exploratory and black box testing to find out most costly bugs. May or may not be efficient/interested in coding.
Automation Tester — YES. Why? Because — Automation Tester = Developer + Tester. For example, if our goal of automation is to reduce regression cycle effort. All regression tests need to have a dedicated person to write scripts, monitor scripts as well as maintain/update scripts.
HOW? do we perform this activity?
Think about which tests should be automated? All regression tests? Few tests based on certain modules? Some tests which have high value and risk?
Carefully select tests which include end-to-end scenarios.
Think about implementation techniques — which framework to use, which tool is better, which tool is easy to work with etc.
Where to execute test scripts? Locally? On a separate machine/build? Or on developer’s build?
Decide on a plan on when and who will maintain the scripts. These scripts need to be triaged and maintained regularly as new features are integrated.
This simple 3 step process is the starting point in designing any test automation framework. Finding out and mutually agreeing upon these key points in the initial stages will make test automation a successful initiative.