As a consultant, trainer, author and developer who specializes in software quality and automated testing, I frequently get asked for my opinions and advice on how to approach designing a test automation stack.

So today I thought I would prioritize sharing some extracts from my forthcoming guide that states my opinions about what makes a good test automation stack, and how you can approach creating one for yourself.

What Makes a Good Test Automation Stack?

My opinion about individual products and vendors changes with time, just like the products themselves. But what will never change are my four golden rules about test automation, which are:

1. The purpose of test automation is to provide hyper-fast feedback to developers.

“Feedback” means both confirmation of success and notification of a problem. For example, a bug is a type of feedback that signals a problem, typically reported well after the developer thinks their work is complete. Similarly, a test failure is another form of feedback and this happens at coding time.

Why is this so important?

Because of my second golden rule that concerns feedback itself, which states:

2. The longer feedback lives in a system, the more costly it is to deal with it.

Think of a bug that is fixed quickly when the developer that wrote the code still has context versus when the bug is discovered weeks later and fixed by someone that has to relearn the code. Which would be quicker and therefore cheaper to fix?

In addition,

3. The more unresolved feedback that accumulates in a product, the lower the quality of the product itself.

For example, if customers are providing feedback that the product is not serving their needs, and this feedback is captured but not dealt with, then the product is not fulfilling the potential value to its users and is therefore of low quality.

All of the above amounts to my fourth rule, which is:

4. The faster you can detect and deal with feedback, the lower cost of development and the higher the quality of your product.

You can increase quality if you focus your efforts on detecting and dealing with feedback. It’s that simple. Therefore, every decision you make in the design and implementation of a test stack must be in service of optimizing the speed of detecting feedback as that’s the first step to dealing with it.

Who Should Design Your Test Automation Stack?

Any member of your team may contribute to the design and implementation of your test stack. Natural leaders of the effort would typically be the technical architects, a strong full-stack developer or perhaps the leader of the QA team. But most importantly of all,

The developers themselves MUST own the test stack.

To understand why, think back to the previously mentioned golden rule — “The first priority of test automation is to provide hyper-fast feedback to developers.”

This golden rule applies at every aspect of your delivery cycle, but especially in the local development environment. So for a test automation stack to succeed in practice, it has to complement the workflow of developers and deliver feedback in real time as code is written. Not after, but during.

Too often I see the QA team owning the test automation, but the QA team operates after development and that’s too late! In more advanced teams I see developers relying purely on their continuous integration servers to run their automated tests. While this is lightyears ahead of the QA team owning the test automation, it’s still suboptimal.

Think about it this way: if you’re driving somewhere using a GPS system and you take a wrong turn, would you prefer to be told immediately or would you rather wait until you arrive at the wrong destination?