Skip to content

Test Automation: A Reality Check

Welcome to Test Automation – a new blog series for QA professionals and product owners who are committed to optimizing the processes involved in building world-class software products and systems.

In this, the first in the Test Automation series, I touch upon the current state of test automation, address common myths about test automation, and identify the reasons why people look to test automation as a viable solution.

Test Automation is authored by me, Hayden Coomber, a Partner at Toronto-based QA Consultants.

The Current State of Test Automation

The current state of automation can be summed up in to the patterns of two groups – both of which look to test automation to save time, reduce effort, and increase test coverage as a means to increase the quality of software.

The first group, which applies ‘Waterfall’ software development life cycle (SDLC) methodologies, draws upon off-the-shelf test automation solutions (i.e. those with advanced record and replay features to help capture automation scripts). As a result, QA professionals who leverage test automation tools are expected to be skilled in testing alone – rather than have developer and/or programming skills.

The second group of automation adopters follow Agile and Agile-like SDLC methodologies. With rapid sprints and scrums in place, this group have a more adaptive approach to test automation. In practice, that means they use ‘Open Source’ tools and leverage ‘continuous integration’ and ‘continuous test’ principles. This approach is applied for developers who have sufficient dexterity in coding tests rather than having to rely on ‘record and replay’ features.

Regardless, of whether you align with one or the other of these approaches, test automation is evolving rapidly and will shape your testing processes, products, and ultimately your business. Because of that, you should be aware of the misconceptions about test automation that are widely circulated. That’s where I turn to next.

Myths About Test Automation

Regardless of your testing experience, you will come across several myths about test automation. Here are the three most common myths:

Myth: All test automation is equal.
Reality: Test automation looks different for every organization – how it is deployed in your organization depends on your company’s products, projects, project scope, team structure, timelines, and budget.

Myth: All test automation tools are equal.
Reality: Every test automation tool has its ‘sweet spot’. That means that, depending on the level of complexity, you may use a blend of test automation tools to achieve your short- and long-term testing goals. Furthermore, the automation tool(s) you use will vary depending on the application that you are testing and the skills of those responsible for testing.

Myth: Test automation is expensive.
Reality: The cost of test automation is made of three components: test automation software, test authoring, and execution. Here are important things to keep in mind: Test automation software ranges from being free-of-charge to costing several thousand dollars. That means, your budget, and targets for cost recovery will dictate how much you spend on automation software.

  •  Test automation software ranges from being free-of-charge to costing several thousand dollars. That means, your budget, and targets for cost recovery will dictate how much you spend on automation software.
  •  By its design, test automation authoring involves creating testing scripts that are meant to be re-used so that the costs are recovered over a period of time
  •  When authoring is done correctly, the cost for automation execution is minimal.
  •  Test automation software can be leased — instead of purchased – as a way to control costs.

Reasons for Test Automation

Having addressed the most common myths, let’s turn briefly to the project (and business) reasons that lead QA leaders/practitioners and product owners to explore test automation as a viable solution:

  • The direct, and indirect, costs associated with manual testing is growing
  • Project schedules demand a need for conducting more tests
  • The number of identified ‘escaped defects’ are rising
  • The costs associated with repairing software defects is rising and/or is unpredictable

In the next Test Automation blog, I will tackle the question that every QA leader and product owner asks themselves: “Will I see a return on my investment in test automation?”

I do welcome your insights about how the issue of how test automation is shaping your priorities and your projects. Let me know what you think by reaching me via email (HCoomber at or via LinkedIn.