The automation of testing is a no-brainer, right?  Anyone can do it.  You just get yourself a framework, buy a tool or two, train up some people and off you go.  The benefits are many: reduced costs, better test coverage, quicker cycle times, etc. etc. etc.  There is plenty of technology out there to help and the tools market is very mature – Selenium, Cucumber, Eggplant, Rational Functional Tester – to name but a few.  So why is it so difficult?  Why do many people set off with the best intentions but soon find themselves in Automation Hell? 

Automation Hell is a scary place which features many of these characteristics:

• There is an over-reliance on one of two members of the team to do the work but they are busy with their day jobs

• The rest of the team don’t have the skills or the aptitude to get involved

• Investment is hard to get - everybody wants to ride on the bus but nobody wants to pay for it

• Creating assets is easy – but developing them to a set of standards and maintaining them is really difficult

• Maintaining, running, fixing and re-running the automation pack is now taking up more time, effort and money than it was to do things manually

• The automation is fine – the environments and data are the problem!

• There are now lots of automated test cases but only a small amount actually get executed

• I’ve invested so much in the automation that I no longer have any real knowledge left in the team

At CQE we believe that automation should not be treated as a technical challenge but as a business opportunity.  The same mindset should apply as for building a business application in terms of agreeing the business case and objectives, setting the scope, assembling the team, agreeing the architecture and design, building the assets and running and maintaining them.    

Critical to this is getting the scope right, especially for regression testing.  Really focus on optimising the test cases that you are going to automate first.  Ideally use an optimisation technique – such as Combinatorial Test Design (CTD) – so you are getting the greatest level of coverage from the smallest number of test cases.  These are the test cases you should then automate and, congratulations, you have arrived at Optimisation Heaven! 

During the design and build phases apply all the same disciplines you would to a business app and treat it like a build project.  Agree the standards that will be applied and think ahead to the long-term.  Also, don’t become over reliant on a single technology that requires niche skills as this may leave you exposed in the future.  We take a wide and independent view of the entire tools market and can advise you on the best technical framework and tool-chain for your needs. 

Be agile.  The test cases become your backlog, the test manager is the product owner and the team gets the chance to share disciplines and learn new skills.  Agree a MVP based on value and stick to it.  Perfect is the enemy of good and it’s better have a good test case that you can run 20 times than a perfect one that runs only once.  We are expert in setting up and running automation build projects and can coach you through the process. 

 Finally, remember that the tool is the fastest but dumbest member of your team (hopefully!). Don’t become over-reliant on it at the expense of real knowledge and experience. 

 The road to Automation Hell is littered with good intentions, false starts and missed opportunities. At CQE we can guide you in the right direction from the start, work alongside you to get established and help you to build your own capability for the future.