Automation is not the goal

Some teams and some people think that automation is the goal. But is it? Let's find out.

Why do we automate?

I've seen many teams come up with test automation due to these reasons:

• someone told us to
• we've seen other doing it
• we have the feeling that it will help us

Interestingly enough, all of these are not based on real needs identified by the team that serve a clear purpose.

Why should we automate?

Automation comes as a consequence of a broader strategy. The same applies to test automation, a smaller set of automation (I would recommend doing some search on test automation strategy). These are some reasons why, IME, we should automate, in terms of test automation:

• Have fast feedback loops: know ASAP if a change/fix we're adding into the product, is breaking some existing functionality or if is impacting on some relevant KPIs, such as performance;
• Have time to explore: even though I came to the conclusion that test automation and exploratory testing are not exclusive, if we have a bunch of automated checks and automated KPIs in place, then we can have some "free time" to explore the system freely and uncover things we didn't expect.

These are, IMO, the two main reasons. But there are more:

• Assist on finding the root cause of problems, if the tests are focused enough and have ways to get the context;
• Augment testing with tooling, by providing us insights that otherwise would be hard or impossible to get; performance/load testing are a good example of that.

If you're thinking about costs, or if you have been asked about, of course there are costs related to implementing proper automation. But there are even greater costs whenever you neglect it. Long story short: these are good costs for sure, as they will enable teams to become more aware and more agile with time.

The goal is something else

In my experience, automation is never the goal. Writing lines of code is never the goal.

What concerns test automation, we have to understand the needs that we aim to overcome. There are different types of testing, at different levels and layers, that we can implement. Test automation scripts are not the responsibility of a single person, unless you're the only one in that project. Test automation is code and thus should be close to the heart of developers; it also follows the same rules. Developers need to implement some checks/validations and track some quality metrics from the start, including performance, security and accessibility. If we have people dedicated just to test automation, it would be great if they can complement the already existing testing that is in place, by leveraging more complex or risky testing scenarios/environments for example.

Whenever we think about test automation, and if all that comes to "We have to implement some selenium tests to check is "everything" is ok" or "Automated tests? That's to the test automation team!", then it's a sign we have to rethink it all.

In terms of the why, a conclusion is never the why, I think. The team needs to discuss where they stand, what are their current blockers and where they want to go. How can we make the team be more efficient? How can we depict a problem as fast as we can? Can we have additional sources of information that can assist us? In my perspective, these are some examples of the questions we should ask ourselves. Then, of course, we can come to the "hows". In terms of the "who", testing and quality are responsibility of everyone, where some can contribute in different depth and with different perspectives. Testers can always contribute with their expertise on exposing unknowns and risks that may matter; that's one of their main values. It's not about the test automation scripts.

The goal is to make the team more aware about how their current system/product behaves and how changes we're crafting impact those, so the team can act quickly in case something is getting broken or something is getting negatively impacted (e.g., performance, code quality).

The goal is, and probably most of all, for the team to be more confident.

Only confident teams take risks and try out new things and learn from that, ultimately improving the product. What about your team? Is test automation a goal? Or a consequence of something broader, that involves the whole team and making that team more confident and more agile?