Automated testing is a very popular technique to bring in repeatability in a test effort. Testers have long been leveraging this technique from the days of record and play software to the current days of framework driven, behavioural driven commercial and open source test automation. In today’s need for continuous delivery, test automation is a very heavily used technique to bring in the required coverage in the limited amount of time and resources on hand. However, automation is extending into newer horizons. It is definitely not limited to just test coverage anymore. Anything that could be automated to bring in more efficiencies and enhance the team productivity is a good candidate that teams are considering today. In fact the ROI of a test automation effort, which was earlier a heavily used and measured term is now gradually losing meaning, as automation is purely not just about a test effort. From a usage standpoint as well, varied entities be it developers, build engineers, designers, in some cases even business teams use an automation suite – end of the day, automation is increasingly touching newer areas of activities and newer personas. For example, any build related activities, test environment setup, data generation, are all actively considered for automation. How much you have automated is not really a data point that stakeholders are interested in knowing any more. How has automation helped you save the overall release time and enhance end user satisfaction through better quality, is what they are more focused on. Automation has thus become the larger umbrella under which test automation is just one aspect for testers to consider.
With this change, how does one plan an automated effort as part of the larger quality strategy? While the meaning has been expanding, as long as one takes a top down approach in planning and understands the larger goal that they are driving towards, rather than just mere automation numbers it should still be manageable. Automated testing still forms a sizeable quotient of the automation mix. I would say even as large as anywhere between 60 to 80%. Productivity and efficiencies driven automation could form the rest. Also, the team needs to understand that not all automated efforts need to be driven from scratch. Open source driven tools and frameworks provide a lot of room for smart automation today, without a lot of internal spend in terms of resources. Online forums are very valuable in understanding people who have had similar problems and how they addressed the same. Flexibility and dynamic decision making, along with core understanding of the “what, when, why, how” of automation goes a long way in helping the team understand that automation is not purely a testing technique but also a test empowering technique helping the team move one step closer in realizing its goals.
