I have spent many years developing test automation solutions to work with some of the worlds largest software providers, doing the leg work so my clients don’t have to. But as with most things in life, automation solutions are only one piece of a much larger testing puzzle, and without insight and understanding you can become one of the growing casualty’s of digital transformation, wondering where it all went wrong. For anyone who is looking at test automation now or in the near future, I thought I’d help out with a few essential things to consider if you want to be successful.

Here are 7 key takeaways to consider when looking at your test automation needs today:

  • ROI. what really is ROI? Are you just comparing saving in testing labour costs? Not only is that rather simplistic, but probably means you are lacking a proper justification for faster, better and smarter delivery. If our ROI is only being decided on test labour costs saved, then you may struggle to deliver this, as currently test automation people do cost more especially, if you go down the Open Source route. If you use a largely script-less or component-based tool however, then this gives you an opportunity to mitigate these costs on a large scale. What is the benefit? Is it defects saved in production? Are we looking to benefit the business shareholders? This goes on the previous point. The main thing is automation of testing is an opportunity to improve overall delivery. If you want to speed up a bit of your testing that is fine but use this as an opportunity to improve delivery in all aspects of your software deployment. Think big picture here.
  • Define the pain point you are trying to address honestly? Why is your testing taking too long? Do you have other lifecycle issues? Is this an opportunity for process improvement? think of all the factors and then decide how to address it? Testing taking too long doesn’t mean test automation will fix it!
  • Do not automate testing to make a deadline, it will fail. I recall a sales meeting with a retail customer who wanted test automation to speed up a late release due to code quality issues and later delivery and poor environment control. I told them he had spent his contingency and to focus on a risk-based approach manually. I recall our test technology partner was not happy, but I can’t advocate a customer spending on an untrue objective.
  • Frameworks and tools: Tools should be the last decision, define the pain point, the issue you are trying to address, address the lifecycle process issues affecting the delivery, the skills deficit in the people and then look at the automation. You will be disappointed if you jump to tools first. As for framework, address the need, the data, errors, delivery cycle, skills and then look at the framework. Some tools are also frameworks, see useMango.co.uk.
  • Open Source/Enterprise tooling – I’ll be honest, this is not a relevant discussion. In the modern delivery world, Open Source works and it’s brilliant but it has its flaws too and you must fix them yourself. If you are not a mature technical team then you will struggle to deliver value. If you really need to own the IP, scripts, and be your own master then do it. Most people are choosing Open Source tools though to increase the value of their consultant contract days and inflate their hourly rates for their next role and really are not in the interest of the business making the most out of their software. There I said it, you can slaughter me, but this is true in a lot of cases I see!
  • Frameworks Part 2: There are load of Open Source frameworks out there and some are good, and some are bad. Simply put, consider what you need. At Infuse we thought about the non-technical tester that wasn’t an expert coder and build useMango. If you don’t want a simple framework for non-technical testers that is fine but then don’t get the non-techie to do it.
  • Training and Professional Services: I personally can be trained by Andre Agassi/Boris Becker and Ivan Lendl, I’ll still be rubbish at tennis, and even though I’d make a better cricket player for the village pub if I was coached by Sachin Tendulkar, I’d still probably be surpassed by the bar owners 13-year old child. It’s important for business to consider what they want and to use the right people, tools and framework. On top of this choose the right partner, we at Infuse are experts in this area.

So, there you have it, simply put, don’t believe the hype, check the credibility of who is doing this and don’t use it as a simple experience to inflate your value in your next job, because if you are doing it right, you will get that anyway.

Want to know more about Infuse and how we can help you? Click here to book in a 15 minute consultation.

With 20+ years’ experience in software engineering, Nalin is an expert in Process and Technical Testing. He founded Infuse in 2002 and has worked on hundreds of test projects across the globe.