What to Automate First: A Practical Starting Checklist

The question isn't whether to automate. It's what to automate first, because automating the wrong tests wastes time and creates a suite nobody trusts. Here's a practical filter.

Start with what you run on every release

If a test is executed manually on every single release regardless of what changed, it's a strong automation candidate. These are usually core regression checks: login, checkout, core navigation, the paths that must never break.

Then look at what's slow and repetitive, not what's hard

Teams often try to automate the most complex test case first because it feels like the highest-value win. In practice, automating ten simple, repetitive checks usually returns more time saved than automating one complex edge case that runs rarely.

Skip anything that changes every sprint

A test tied to a UI or workflow still being actively redesigned is expensive to maintain and will break constantly. Let that stabilize first, or you'll spend more time fixing the automation than you saved by writing it.

Check whether the environment is stable enough to automate against

Automation against a flaky staging environment, inconsistent test data, or a service with unreliable third-party dependencies will produce false failures that erode trust in the whole suite faster than any bug would.

A simple checklist

• Run on every release, not just sometimes
• Stable: the underlying feature isn't mid-redesign
• Repetitive and time-consuming to run manually
• Has a clear, deterministic pass/fail outcome
• Runs in an environment stable enough not to produce false failures

A handful of tests that hit all five points will do more for release confidence than a large suite that hits only two or three.