Having been part of the testing industry for so long, I have met quite a few people – including testing experts, automation engineers and decision makers, who have seen BIG successes as well as BIG failures from test automation projects. I generally ask them what has worked for them and what hasn’t. It is very hard to summarize the reasons for such successes and failures – because there simply does not seem to be one solution that fits all.
Having said that, when I think about all those conversations, discussions, project lifecycles, I see some pattern – the projects seem to follow one or two of the common patterns. The first and foremost thing is the reason for adopting test automation. I see the following three most common reasons for adopting test automation –
#1: Because I understand a particular tool / technology
This one typically comes from the technology advocates. Technology is often at the heart of the word “automation” so it is but obvious that it takes the centre stage. With so many tools/ technologies available in the market claiming to “ease the automation”, I have seen that the test automation discussions start with tool comparison. Open an excel sheet -> fill up the columns with the names of tools and technologies -> start filling the rows comparing various features. Whichever tool then fits into the (technical) requirements gets selected and the projects start.
#2: Because the management has asked for it!
I have seen that the organization management (aka the financial decision makers), generally get convinced about test automation when they see the benefits as “wider coverage”, “more testing in less time”, “less resources”. Once the management is convinced, the implementation team gets the decision in the form of an order and the work starts from that point –the implementation team (at many times) is not aware of the reasons why the decision has been taken and what are the expectations. For the implementation team, it comes as a project to be implemented without knowing the end goal – scary as it may sound, this seems to be the reality – a huge gap between expectations and deliverables.
#3: Because test automation is HOT
Whenever the jargons like “faster time to market”, “saving time and money”, “easier test maintenance”, “quality optimization”, “reusability”, “easier test suite maintenance” are discussed, test automation is perceived as a magic wand which take care of everything. “When everyone is talking about it, it must be good” – one may think. It is therefore not surprising to see that many test automation project get started just because of this reason – call it “peer pressure” or “joining the bandwagon”.
#4: Because I know the SECRET SAUCE to succeed
I would love to hear if there really is a secret sauce to guarantee the success. I always thought that every test automation requirement is so unique that there is cannot be standard template which can be applied to all. Yes, there are certain basic principles, generally termed as STRATEGY which can be applied across multiple projects – like the kind of people you would like to have in the team, how to go about defining the scope, how to choose the right tools and technologies and so on. There are lot of factors – both internal as well as external – which contribute to the success or failure of test automation initiatives.
To me most important is being in tune with stakeholders on their demands from test automation, vision for the solution and of course complete ownership of its success and failure. I personally like to approach all test automation initiatives from the ROI perspective – map the test automation goals with business goals and then think of everything else.
I thought I will ask the experts reading this blog on which of the drivers has prompted you to kick start your test automation. Is it any one mentioned above or something else?