Making a case for less automation

If you're an automation engineer, consultant or trainer (or a mix of these, like me), you'll probably agree that the automation space is a very good place to be in at the moment. I consider myself blessed to have enough options to say 'yes' only to the opportunities I really like, while politely declining those that don't feel like an absolutely great fit.

The market for those who are skilled in the field of test automation is booming: nearly every job listing or project description I see requires automation skills in some form or another, and I don't know of a single organization where automation isn't part of the overall testing strategy, at least to some extent.

The title of this article, in this light, might therefore sound somewhat strange to you. Why would I plead for less automation instead of more? Automation is a good thing, right?

Yes, when done right, automation is indeed a very useful, often even crucial, part of your development and testing efforts. But I don't think that's enough of a reason to automate everything, or even anything, for that matter. What's often forgotten is that automation itself comes at a cost. It takes time and effort to create automation, and then more time and effort to maintain it. That in itself should be good enough reason to think really hard about what you should include in your automation suite, and what might be better left out.

To help you decide what should be included and what can be left out, try asking yourself the following question whenever you're creating a new automated check:

'Are we comfortable with not having the information that this check provides?'

If the answer is 'yes', then I'd suggest not creating the check, or at the very least deferring its creation until later. In a similar fashion, if you're stuck deciding what checks should be made part of your automated build and deployment pipeline (i.e., your Continuous Integration or Continuous Delivery strategy), ask yourself:

'Are we comfortable with not having the information that this check provides before we deploy our product?'

The goal of asking these questions is not to remove any and all automation. Far from that. The goal is to create a lean yet powerful automation suite that covers all of the essentials, but has little to no room for fluff.

As Greg McKeown eloquently put it in his book 'Essentialism - The Disciplined Pursuit of Less', I think we should strive for 'less, but better' when it comes to creating and extending our automation suites.

Once you start taking a more critical approach to adding new checks and features to your automation, you'll likely start to notice that your suite will:

• Generate less noise: since we've reassured ourselves that every check in the suite provides important information, there's less noise to sift through when interpreting the results.
• Require less maintenance: since your suite will be smaller (but better), you'll probably need to spend less time maintaining it, and less effort is needed to keep it running smoothly.
• Provide you with more time to do other things: as a result of the first two points, you'll have more time to spend exploring, researching and learning about what your software does - all things that are critical to testing, but that automation cannot do.

You will probably not get where you want to be the first time, but that's OK. Remember that it's easy to create a lot of automation; on the other hand, creating simple but powerful automation is hard. But when you take small steps and learn from them, then stick with what works while throwing away what doesn't, I am confident that you will get where you want to be.

To put a different perspective on it: I think automation is a lot like bubble wrap:

• Both are used to get another product safely to its destination.
• Both, in itself, have little value, but play an invaluable part in the overall delivery process.
• For both goes that using too much of it doesn't make sense, it just adds unnecessary overhead.
• Oh, and they're both fun to play with, of course!

In all seriousness, what I'd like you to take away from this article is that I think it might be a good exercise to take a more critical approach to automation, instead of adding more and more of it without considering the possible negative side effects. I believe that asking yourself 'Are we comfortable with not having the information that this check provides?' on a regular basis can really help you to build an automation suite that's less, but better.

About me: I'm an independent automation consultant and trainer. You can contact me here on LinkedIn, via @_basdijkstra on Twitter or via my website.