In late 2016, I wrote this blog post describing how I define automation for testing. For the TL;DR crowd, here’s the definition I typically use for automation:

automation is the judicious application of technology to help humans do their jobs.

I still use this definition today. When I talk to clients, this definition gives me additional latitude in how I help them by introducing automation as a force-multiplier for testers as opposed to strictly a replacement for tester tasks.

Why am I bringing this up again and why now?

Over the last couple of months, I’ve seen social media posts and been involved in chats about automation not being feasible, valuable, appropriate, etc. early in the development process. Though I’ve heard, and probably said, similar things over the years, I now think I have my brain sorted enough to write about this topic. Based on the above definition of automation, I suggest a different mindset regarding “too early”.

First, here are the thoughts I have regarding some common refrains I hear regarding early automation:

It’s too early to automate
If we apply the above automation definition, this is not true. It may be too early to build traditional automation based on test cases like smoke or regression testing scripts, but we may be able to write some software to help testers during this time of churn. Data creation and log collation scripts are typical candidates for early automation as are scripts that “turn the crank” for testers; these kinds of automation free testers from repetitive drudgery so they can spend more time on knowledge work. The article here may offer some ideas.
The GUI is not stable yet
To this, I say: so, what? Not all automation needs to be driven via the GUI. In particular, I like to ask the question, “are you automating the GUI or are you automating through the GUI?” If the latter, automating “behind the GUI”, i.e. API or service-based automation can provide value while not having that value eroded by GUI churn.
That interface isn’t finished yet
Again, I say, so? Automation is not an all or nothing venture; if we can obtain value by having technology help us do part of our jobs in a way that provides value, we would be remiss in our duties if we didn’t explore such opportunities.

When discussing a specific task, some questions I like to ask regarding “should we automate this task now” are:

  • How many times will we perform this task?
  • What value will we gain from automating this task?
  • When could we start using the automation?
  • When do we expect the automation to be available? Note that we can answer this question even if only know when part of the automation will be available; this subset may still be useful enough to provide value.
  • Do we expect the automation of this task to be long-lived or disposable?
  • Will this automation bring more value than cost? If so, why do we think that?

Of course, the answers to the questions above will vary between teams, applications, and the specific tasks themselves. Though we should not automate every task and not all tasks are candidates for early automation, we should seriously consider automating any task where that automation would provide appropriate value…regardless of when in the application’s lifecycle we start that automation.

Like this? Catch me at an upcoming event!