"Should we automate this?" is usually answered "not yet, and maybe never."
Manual and automated testing aren't competing — they answer different questions
Automated tests are excellent at answering one very specific question, fast and repeatedly: "does this exact, known scenario still work the way it did yesterday?" That's regression testing, and it's the ideal automation target because the value is in repetition.
Manual, particularly exploratory, testing answers a different question: "what happens when someone does something we didn't anticipate?" That requires judgement and curiosity — a script can only ever check what it was explicitly written to check.
The test pyramid isn't just for developers
You've probably seen the testing pyramid — lots of fast unit tests at the bottom, fewer integration tests in the middle, a small number of slow, comprehensive UI tests at the top. The same logic applies to deciding what a QA team automates: favour automating checks that are cheap to write, fast to run, and stable, and keep the small, expensive, flaky-prone end-to-end scenarios manual, or automate them last, sparingly.
A practical checklist for what to automate first
Ask these questions about any test case you're considering automating:
- Will this test be run more than a handful of times? A one-off check for a one-off migration isn't worth automating. A login flow that runs on every release, forever, is.
- Is the expected result stable and unambiguous? If "correct" depends on human judgement, automation is the wrong tool alone.
- Is the flow itself stable? Automating a screen that's actively being redesigned means rewriting the automation every sprint.
- Is it high-risk if it silently breaks? Login, checkout, core data-entry workflows deserve automated coverage even if they're annoying to automate. See the real cost of skipping QA.
- Can it be tested below the UI? If the same risk can be covered by an API or database check instead of a full UI test, do that first — it's faster, and far less flaky. See our API testing guide.
The flows that score well on all five — smoke-test-style checks of your most critical, most stable, highest-risk paths — are almost always the right first automation targets. Not the newest feature. The boring, critical path that runs the same way every time.
Why automating the wrong things first kills automation efforts
A common failure pattern: a team automates a large, complex, still-changing feature first because it feels like the highest-value target. The tests are flaky because the underlying feature keeps changing shape. Flaky tests get ignored, then skipped, then the whole suite is treated as untrustworthy, and the automation effort quietly dies a few months later.
Automation doesn't replace manual testers — it changes what they spend time on
The goal of automating the repetitive, stable checks isn't to reduce the need for testers. It's to free up a tester's time from re-checking the same known-good paths every release, so they can spend it on the thing automation genuinely can't do: exploring new features, thinking adversarially about edge cases, and using judgement a script doesn't have. A mature QA process uses both, deliberately, for what each is actually good at.