What is automated testing?
Automated tests are programs that check that the software works, run automatically on every change instead of manual clicking before release. They're usually split into unit, integration, and end-to-end tests. The business value is that you dare to change things fast without breaking what already works – and one obvious question is what's covered by tests and what's checked by hand.
Automated tests are one of the things that separate software you can trust and keep building on from software everyone grows more afraid to touch. The term sounds technical, but the idea is simple: let the computer check that everything works, instead of relying on manual handling. Here’s what it means and why it affects you as a buyer.
The definition
Automated tests are programs that check that the software works as it should. Instead of a person manually clicking through the system before every release to see that nothing is broken, code is written that performs those checks automatically – and it runs on every change, over and over, in seconds.
The difference from manual testing is that automated tests are fast, tireless, and consistent. They check the same things perfectly every time, thousands of times a day if needed, and they flag a bug the instant it’s introduced. A bug that might otherwise have been discovered by a user much later is instead caught immediately, by the developer who just caused it.
The testing pyramid: three levels
Automated tests come in several kinds, usually described as a pyramid to show how they should be balanced.
- Unit tests check the smallest building blocks individually – a single function, a small piece of logic. They’re fast and cheap to run, and should therefore be the most numerous. They form the pyramid’s broad base.
- Integration tests check that several parts work correctly together – that the code and the database interact as intended, for example. They’re somewhat heavier and fewer than the unit tests.
- End-to-end tests mimic a real user and test the whole flow from start to finish, through the entire system. They give the greatest confidence but are the slowest and most fragile, and should therefore be the fewest – the pyramid’s narrow top.
The shape is the whole point: many fast tests at the bottom, few comprehensive ones at the top. A pyramid standing on its tip – few unit tests, many slow end-to-end tests – becomes sluggish and brittle.
A concrete scenario
Say a developer is adding a discount code to an e-commerce site. The change is small, but it touches checkout – the system’s most sensitive part. Without automated tests, someone has to manually click through the entire purchase flow to check that nothing else was affected, and there’s always a risk of missing a case.
With automated tests in place, hundreds of checks run in seconds as soon as the change is saved: is the total calculated correctly, does payment work, is the receipt sent, is shipping calculation unaffected? If the discount happened to break something else, the tests flag it immediately, with a report of exactly what. The developer fixes it on the spot, before the code even reaches the next step. Same change, but with a safety net that makes it safe to make it fast.
The business value: dare to change fast
That scenario captures the whole value. The real benefit of automated tests isn’t finding a bug once, but making it safe to change the system again and again over time.
Without tests, every change is a gamble: you never know for sure whether a new feature happened to wreck something old, and the fear of that makes development slow and cautious. With good test coverage, the tests flag it immediately when a change breaks something that used to work, so the team can develop fast and confidently. That lowers both the risk and the cost of all future development – which is exactly what determines how long-lived and useful a system becomes. It’s closely tied to how much technical debt builds up.
The question to ask your vendor
For you as a buyer, there’s one simple and revealing question to ask: what’s covered by automated tests, and what’s tested by hand?
A mature team answers without hesitation, can describe how they test, and points to the business-critical flows being automatically covered. If the answer instead is that everything is checked manually before every release, that’s a warning sign – changes become slow, expensive, and risky, and the system harder to trust the more it grows. If you’d like a neutral opinion on the testing in your system, get in touch and we’ll take a look together.
Frequently asked questions
What is automated testing, explained simply?
It's code whose only job is to check that the real code works. Instead of a person manually clicking through the app before every release, the computer runs thousands of checks in seconds and flags anything that's broken. The tests run automatically on every change, so bugs are caught the moment they're introduced instead of by a user much later.
What is the testing pyramid?
It's a model for how different test types should be balanced. Unit tests check the smallest parts individually and should be the most numerous, since they're fast and cheap. Integration tests check that the parts work together. End-to-end tests mimic a real user through the whole flow and should be the fewest, since they're the slowest. Broad base, narrow top – hence the pyramid.
Why are automated tests worth the money?
Because they make it safe to change the system. Without tests, every change is a risk: you never know for sure whether you've accidentally broken something else. With good test coverage, the tests immediately flag when a change breaks something that used to work, so the team dares to develop fast without breaking what's already there. That lowers both the risk and the cost of building further over time.
What does test coverage mean?
Test coverage describes how much of the code is checked by automated tests. High coverage means most of it is checked automatically, which gives confidence when making changes. But the number doesn't say everything – it's possible to have high coverage that still misses what matters. More important than an exact percentage is that the most business-critical flows are well tested, not just the simplest parts.
What question should I ask my vendor about testing?
Ask straight out: what's covered by automated tests, and what's tested by hand? The answer says a lot about how safely the system can be built on further. A mature team can describe their testing and point to the critical flows being automatically covered. If the answer is that everything is tested manually before every release, that's a warning sign, because changes become slow and risky.