What to Automate First — and What Never to Automate

Most teams automate the wrong things first — usually whatever is easiest to script, not whatever delivers the most protection. A developer picks up a testing framework, writes a test for the function they're currently working on because it's fresh in their head, and repeats that a few dozen times. Six months later there's a suite with 80% coverage of the utility layer and nothing checking whether a user can actually pay.

Automation is expensive to build and, more importantly, expensive to keep working. Spent well, it removes a recurring tax. Spent badly, it becomes the tax. Here's an order that optimises for information per unit of effort.

The priority order

Automate in roughly this sequence:

The pre-release regression sweep. The set of flows a person clicks through before every release — sign up, log in, create the main object, check settings, check billing. It's high-frequency (every release), high-value (it's the last line of defence), and the most tedious thing to keep doing by hand. Automating it buys back real human time immediately and stops coverage from silently shrinking to "the parts we remembered" when a release is late.
The critical user journeys. The three to ten flows where failure is a genuinely bad day: sign-up and onboarding, authentication and password reset, checkout or any money-handling path, and the core create/edit/delete loop your product is built around. These overlap with the sweep but deserve their own explicit, assertive checks — not just "the page loaded" but "the order exists and the balance changed."
Bugs you've already shipped. Every regression that reached production becomes a test before the fix merges. This is the cheapest high-value coverage you will ever write, because the reproduction is already known and the bug already proved it matters. A suite built this way tracks your actual failure modes instead of your guesses about them.
High-frequency checks. Anything a person verifies more than a couple of times a week — a report that has to reconcile, an export that has to be well-formed, a permission boundary you keep manually poking at.

Everything after that is diminishing returns until these four are solid. A team with automated coverage of its sweep, its critical journeys, and its shipped bugs is in a genuinely good position, even if the raw coverage number is unremarkable.

The four questions to ask of any candidate test

For anything you're considering automating, score it against four questions:

How often will this run? A check that runs on every release earns its maintenance many times over. One that runs once a quarter almost never does.
What does failure cost? A broken checkout, a data-corruption path, a security boundary — automate protection for the expensive failures first. A misaligned tooltip can wait.
How stable is the behaviour? Not the UI — the underlying intent. "A user can log in" is stable even if the login page gets redesigned twice a year. "The new experimental dashboard shows the right widgets" is not, because the dashboard itself is still moving.
Is the pass/fail clear? If judging the result needs human taste — "does this feel fast enough", "is this copy clear" — it's not a good automation candidate.

A test that scores well on all four — runs often, guards something costly, tests stable behaviour, has an unambiguous result — is worth automating now. One that fails most of them can wait or stay manual.

Applying the questions

Three candidates, scored:

"A new user can sign up, verify their email, and reach the dashboard." Runs every release, failure means zero new users, the flow's intent is rock-stable, and the result is a clear yes/no. Automate immediately.
"The admin analytics page renders the new cohort chart." The page is being actively iterated, the audience is internal, and "renders correctly" is partly a visual judgement. Leave it manual until it settles.
"An expired credit card is declined at checkout." Rare in normal use but catastrophic if it regresses, stable business rule, unambiguous result. This is a perfect candidate for a small, exact scripted test.

What never to automate

Flows still in active redesign. You'll spend more time reconciling the test with the weekly UI change than the test will ever save you. Wait for the design to stabilise.
One-off checks. If you'll genuinely run it once — a data migration verification, a one-time backfill — run it by hand.
Look and feel. Whether something is visually right, reads well, or feels responsive is a human call. Visual regression tooling can catch unintended pixel changes, but it can't tell you the intended design is good.
Exploratory testing. The entire value is that it isn't scripted. Automating an exploratory session is a contradiction.
Pure vanity coverage. A test that can only fail when someone deliberately breaks it — asserting that a constant equals itself, testing a getter — inflates the coverage number and tells you nothing.

The automation you'll regret

The most common regret isn't a missing test — it's a large, brittle end-to-end suite built too early, before the product stabilised, that now breaks on every merge for reasons unrelated to real bugs. The team stops trusting it, starts rerunning until green, and eventually deletes it after a redesign. All of that effort produced negative value.

The guard against this is discipline about stability (question three) and about keeping the scripted layer small. Broad coverage doesn't have to mean a big maintained suite — see the next section.

A starting checklist

List your top 5–10 critical journeys. Write them as sentences a non-engineer would understand.
Get an autonomous run against staging for a coverage baseline — running your first test.
Turn the must-not-break journeys into explicit checks with real assertions.
Add scripted tests only for the exact assertions an autonomous run can't make.
Put it all in CI. Expand based on where bugs actually escape, not on a coverage percentage.

The test automation guide has a fuller version of this, and the testing pyramid covers which layer each check belongs in.

How autonomous testing shifts the question

"What to automate first" assumes each test costs real effort to build and maintain, so you have to ration it carefully. Autonomous exploration removes that cost for broad coverage: the agent tests the whole app on every run without a script per flow. So the regression sweep and much of the journey coverage come for free from the first run, and your scripting effort — the scarce resource — goes only to the handful of exact assertions that genuinely need code.

That doesn't remove the prioritisation entirely; you still decide which flows get explicit plain-English checks and which exact assertions get scripted. But it moves the hard rationing decision from "which of these hundred flows can we afford to cover" to "which ten flows do we care enough about to assert precisely." See regression testing and the autonomous testing guide.

Bottom line

Automate the sweep and the critical journeys first, lock in every shipped bug as a test, and never script the rare, the unstable, or the judgement calls. Keep the scripted layer small and let autonomous coverage carry the breadth, so your scripting budget goes where precision actually matters.

Start free and get a coverage baseline for your app in one run.