Manual vs automated testing: where the line actually falls

"Should we automate this?" is usually asked as a budget question and answered as an identity one — automation good, manual old-fashioned. That framing produces two failure modes: teams that automate everything and drown in maintenance, and teams that automate nothing and re-run the same regression by hand every release. The useful version of the question is narrower: for this specific check, which approach gives a reliable answer at a cost I can live with, release after release?

What each is actually good at

Automated testing is unbeatable at repetition. A machine runs the same path identically a thousand times, in CI, on every commit, without getting bored or skipping a step at 5pm. That makes it the right tool for regression of stable, well-understood behaviour, for fast feedback on critical paths, and for anything you'd otherwise run by hand more than a few times. Its cost is real, though: automation is code you have to build, debug, and maintain — and a flaky suite quietly taxes the whole team until people stop trusting it.

Manual testing is unbeatable at judgement. A human notices that the layout is technically correct but ugly, that the error message is rude, that the flow is confusing even though every assertion passes. It's the right tool for new and changing features, for exploratory work, for UX and accessibility feel, and for anything where "correct" is a judgement call rather than a fixed value. Its weakness is the mirror of automation's strength: it doesn't scale and it doesn't repeat identically.

The decision rule

Automate when the check is stable, repeatable, objective, and run often: the login path that must work every release, the API contract, the regression set you'd otherwise re-run by hand. The clearer "pass" is to define, and the more times you'll run it, the better the automation pays back.

Keep it manual when the check is new, subjective, or one-off: a feature being built right now, the look-and-feel pass, the "does this actually make sense to a user" question, the bug you're reproducing for the first time. If you can't yet write down exactly what correct looks like, you can't automate it reliably — explore it manually first, then automate what stabilises. This is the natural on-ramp described in the manual-to-automation transition.

Manual vs automated: which to use

• Stable behaviour you must prove every release → automate (and put it in CI)
• Critical happy path with a clear pass/fail → automate
• Regression set you'd otherwise re-run by hand → automate the high-value, stable parts
• Brand-new or rapidly changing feature → manual first; automate once it settles
• UX, copy, visual feel, "is this confusing?" → manual (judgement, not assertion)
• One-off reproduction or a quick spike → manual (automating it costs more than it saves)
• Test that would be flaky to automate (timing, third-party, non-deterministic) → manual until you can make it reliable
• Accessibility and exploratory passes → manual, supported by automated checks for the mechanical parts

The line moves — that's the point

The split isn't fixed per feature; it's a lifecycle. A feature starts almost entirely manual (you're learning it), and over time the stable, valuable, repetitive checks migrate to automation while manual effort stays on the frontier — whatever changed this release. Teams get into trouble when they treat the line as a one-time decision: automate everything up front from the spec (and inherit a brittle suite that only checks the assumptions in a thin document), or never move anything to automation (and spend every release re-running the same regression by hand instead of testing what's new). Manual finds it; automation keeps it found. You need both, and you need to keep moving the boundary between them.