Fairly regularly, I see advice on LinkedIn and other platforms that one should “check one’s automated test scripts regularly” so they can be “kept up to date”.
This advice always baffles me.
How are these automated tests used if they need an intentional action to be checked for up-to-dateness? If you’re not using your automated tests at least daily, probably dozens of times a day, something is very wrong.
Automated tests shine when they give us fast feedback, in a reliable and repeatable fashion. To achieve this, they need to be run as part of an automated CI/CD pipeline, on every commit to main.
Many organisations use automated tests to “replace” human testers. They hire “automation testers” to automate everything in the existing regression test suite because computers can perform those tests faster than humans – right? RIGHT?
Well, yes – but that is not how one wants to use automation.
- The main advantage of automated tests is that they can exercise the code in ways humans can’t (easily).
- They can check individual methods and classes.
- They can exercise two elements or components in conjunction without having to build the entire app.
That doesn’t mean you don’t want to also test a full end-to-end flow, but it means the functional e2e can be much more selective and test what matters: user flows.
Think about it like building a house:
- If you buy a bunch of bricks, each of these bricks gets inspected as part of the building process. This gives you a lot of confidence in the basic building blocks of your house.
- Individual bricks then form walls, which get inspected on their own – that’s your component-level test, multiple individual pieces need to function together.
- Eventually, you’ll make sure the stairs actually lead somewhere, and the doors open the right way, and that kind of thing. BUT you don’t inspect every single brick in that last step – because you know they’ve been inspected. You focus on the things that matter to a user of the house.
If you use your test automation as part of your pipeline, you won’t need to have a separate action to “check and update” your tests – if they’re outdated, they will fail. If they fail, someone doesn’t get to merge their code until they fixed the tests.
It’s that simple.