The origin of Software Test Automation harkens back more than 30 years ago to what was claimed as the first commercially available automation testing tool – AutoTester, which was introduced in 1985. One would think that a technology based solution in existence for such a long period of time would have evolved into a mature, reliable and cost effective industry pumping out high quality, feature rich applications like a “well-oiled software testing machine.”

But why haven’t many organizations that have invested heavily in test automation seen the anticipated benefits to make this a reality?

I’ll pause for a moment to await for the deluge of passionate rebuttals… Ok, pause over. I know there are companies that have had positive automation experiences, but I would consider this the exception rather than the rule. My experience is that many, if not most organizations have a tendency to struggle with test automation.

A recent general survey concluded that 80% of the companies interviewed have automation rates of less than 50% and a significant percentage of the same have experienced less than 10% automation. Even though the automation rates range vary from fair to mediocre, many industry experts believe it’s even worse. A better assessment may be that many companies executing automation approach only 20% of the time.

A number of factors contribute to these low realization rates as revealed by QA expert, Dorothy Graham, in her 2014 survey. Nearly 60% of companies in Graham’s survey claim they lacked the necessary resources and/or expertise to effect automation. Of the respondents reporting that have automation, 50% stated that their scripts are unreliable. Another 44% said that automation is too expensive and 63% indicated that they have limited time or resources to conduct test automation properly. This seems to infer that the respondents have either stopped automation or conducting it on a rather limited basis.

Using the above observations, we can begin to associate some key factors contributing to reasons why test automation has failed to deliver its intended results:

  • Lack of expert resources
  • Unreliable or brittle scripts
  • Excessive costs to implement automation or maintain scripts
  • Insufficient time for automation

I’ll even add a few more contributors to failure when embarking on a test automation journey:

  • Lack of Senior Management commitment
  • Unrealistic testing expectations
  • Tool selection that fails to match the need or resource skill sets
  • Absence of a strategy or focus, (… test automation is a process, not a project)

Over the course of my career I have encountered many of these issues, but it wasn’t until about a year ago, that we discovered the remedy for the majority of these challenges.

Let’s face it, there may not be a lot one can do about forcing senior management to commit or alter unrealistic expectations. You might develop the best solution in the world, but it won’t overcome these two obstacles; so let’s set them aside for the moment. The same concern applies to a lack of strategy, because if you don’t have a “good handle” on what and how you want to achieve test automation, you’ll end up in an unexpected place – “nowhere”!

Fortunately, we have found a solution that addresses many of the barriers that prevent organizations from achieving successful test automation. This solution essentially eliminates the “technical expert problem” because it doesn’t require highly technical resources to build automation test cases.  It doesn’t rely on scripting or programming languages which can render test cases brittle, hard to maintain, and costly. It is a fully integrated framework and it supports over 30 commonly used platform/architecture solutions; answering the question as to “Will it meet your needs?”

This is a model based, script-less solution that reduces automation development and maintenance costs. It includes “risk based testing” features that promote a test strategy and saves time and money because the focus is on the right number of scripts for “risk coverage”; not generating scripts simply for the sake of automating every manual test case.