Anecdotally, the phrase “keeping up with the Joneses” means acquiring additional “things” or behaving in a specific way because your friends, neighbors, colleagues, etc. all have those things or behave that way. The thought is that if you don’t want to be viewed as lesser than those people, you need to at least maintain parity with their social and economic standing. My neighbor gets a new car, then I need a new car. My colleague gets a new MacBook, then I need a new MacBook. Netflix has a chaos monkey, then I need a chaos monkey. You see, even in tech, we can fall victim to a similar phenomenon when we look at other organizations and companies regarding how they approach various technologies and disciplines, testing and test automation included.

So… why do we automate? Of course, I’m talking about automating portions of our testing (because that’s what I do), but it’s really a broader question than that. It’s also a question that I don’t think we ask ourselves enough.

Again, why do we automate? When should we automate? When should we not automate? OK, that’s more than one question, but you get my drift.

I frequently speak with teams who automate some aspects of their testing because “we’re Agile”, “we do Scrum”, “we do DevOps”, or “Netflix/Amazon/Facebook do it like this”. Those are all great inspirations for automation, but none of those reasons are justification for creating automation. As much as we want to make test automation a technological mandate of some process or to automate in a certain way because the MAANGs (i.e., The Joneses) do it that way, at its core, automation exists to provide value. In general, test automation’s value is in helping teams provide information about the behavior of an app or product so that decision-makers can incorporate that additional information into their “ready for release” risk assessments. The decision on what to automate is a business decision informed by both business and technology information.

It’s generally irresponsible to undertake automation without considering both the technological and the business sources of information; if we discount one or the other of those information sources, we risk reducing the value of our automation and even expending more effort than the value we’re obtaining. Though automation decisions seem to be technological decisions, make no mistake: the aforementioned questions about automation absolutely have a business context and business connotations.

When we think with a technology-only mindset, we forget about things like opportunity cost, total cost of ownership, and budgetary limitations. One of the challenging things for techies, like me, is having to factor in monetary considerations even when we are trying to do “the best thing”. This leads me to the term “best-in-class”. In my talk about choosing a test automation tool, I caution against always choosing the best-in-class tool (or process, programming language, etc.). What we should be striving for is “most appropriate in class”: the thing that fits our needs our needs most appropriatly.

We should take care not to fall into the trap of keeping up with the MAANGs, uh, Jonses, or doing “process-driven” automation. Being mindful of the value that automation provides in our context, will help us to make appropriate technological and business decisions about when, how, and what to automate.

Like this? Catch me at or book me for an upcoming event!