In the software testing world, automation is the ability to run scripts, tests, checks, and other applications with minimal (or zero) direct intervention from the user. Automation allows us to detect or verify a broad range of issues with the simple click of a button.

This can be a huge timesaver – whether you’re working on mundane tasks or more involved projects.

At Testuff, we love automation and try to use it wherever and whenever we can. We also built an easy process to enable reporting automation test results to Testuff.

But just as spellcheck has made many writers lazier – and cruise control has made roads less safe – is it possible that automation has dumbed down our profession? Has hands-off software testing dulled our senses and robbed us of critical problem-solving skills?

Yes and no. It depends on how one approaches automated software testing.

Let’s explore.

The Case Against Automation in Software Quality Assurance

You can do a lot with automation – especially if you work within the same general environments, conducting the same general types of tests, over and over and over again.

Set up your workflow once, and then forget it thereafter.

But therein lies the danger.

When automated scripts do all of the heavy lifting for you, it’s easy to get lulled into a false sense of complacency. Sooner or later, there will be a task or test that breaks the mold – an outlier that is ill-suited for prep-programmed, formulaic analysis.

When we become too reliant on automation, we sometimes fail to ask the right types of question or engage the right types of logic.

And we end up blaming the tool (“But I used spellcheck – how could this have happened?”)

I’m reminded of that scene from Jurassic Park in which the scientists set up automated trackers to make sure all dinosaurs are accounted for. They program these trackers to ensure that at any given time, there are exactly N number of Velociraptors on the island. If and when the population dips below this N threshold, the scientists receive an “automatic” alert.

Set it and forget it. Simple enough.

What they fail to realize, however, is that this automation is only scanning for population declines. But because several dinosaurs change sex and procreate, the number of Velociraptors on the island actually increases.

This growth is something that their automated setup was never designed to check.

And voilà – you have a movie.

Obviously, this is as “worst case” a scenario as one could ever imagine. With most of the programs that you and I work on, there is little danger that prehistoric beasts will multiply uncontrollably. But the above example does highlight the potential dangers of becoming too reliant on – and too trusting of – automation. The above also illustrates how automation can actually waste time instead of optimizing it.

However, it doesn’t always have to be like that.

Making the Case For Automated Software Testing

Automation isn’t a solution or a babysitter or a final destination. It is a productivity tool that allows us to accomplish more – using fewer resources (usually time, which means also money).

The efficacy of this tool lies in its use – not in its mere existence. A hammer in unskilled hands can do tremendous damage. But in the right hands, that hammer can help build skyscrapers.

Automation follows the same principle.

When working on certain tasks – especially mundane tasks – automation frees us up so that we can focus on aspects of the project that really matter. We can concentrate on those components that require critical problem-solving skills and a real human presence.

Any why wouldn’t we embrace this convenience?

Software testing is already quite expensive. It doesn’t make sense to tie up valuable resources (i.e. time) with repetitive tasks that can be automated safely and effectively.

But what does it mean to safely automate in software testing?

Finding the Right Balance in Software Test Automation

Automation can be a dangerous crutch. It can also be a time-saving godsend.

So how do you find the right balance?

We’ve said it before, but one should carefully consider the “what” and “why” of every step in the software testing process. It is our responsibility to remove the guesswork before breaking out our tools:

  • What exactly are you testing?
  • Why are you testing this?
  • What is the best way to verify your results?
  • Why is this the best way?

By answering these questions, you can avoid the complacency trap while simultaneously optimizing limited resources for optimal impact.

This remains true whether you’re trying to detect programming bugs or build dinosaur-themed amusement parks.

Has automation ever gotten you in trouble before? And would asking/answering the above questions have helped you avoid the issue?

Please comment down below.