What to automate (and what not to)
Automation is a bet: you spend time now to save time forever. Good testers know which checks pay that bet back — and which quietly lose it.
7 steps · 5 minAutomation is an investment
Every automated test costs time to write and time to maintain, and pays out a little every run. A check you'll repeat on every release for years is a great investment. A check you'll run twice is not — do it by hand and move on.
The question is never 'can we automate this?' It's 'will this pay for itself?'
Which of these is the best candidate for automation?
The test pyramid
The classic shape for an automation suite: lots of fast unit tests at the bottom, a solid middle layer of API/integration tests, and a small set of end-to-end UI tests on top. Lower layers are faster, cheaper, and more precise about what broke.
The pyramid isn't a law — it's a reminder that UI tests are the most expensive kind, so spend them carefully.
A team automated 400 UI tests and almost nothing else. The suite takes 3 hours and fails randomly. What's the actual problem?
What stays human
Automation checks what you already know to look for. Exploration finds what you didn't. New features, risky changes, UX judgment, and 'something feels off' all stay human — automation exists to free your hands for exactly that work.
Your regression suite is fully automated and green. You have a free afternoon before release. What's the highest-value use of it?
The strategy in one line
Automate the checks you'll repeat forever, at the lowest layer that can catch the bug — and spend the time you save exploring what no script can see.
Next: automated tests are only useful if you can trust them. Time to deal with flaky tests.
Lesson complete.
You now think about automation like an investment: automate the stable and repeated, keep exploring by hand, and shape the whole thing like a pyramid.