Which tests should you automate first?

Start from risks, not tools

Choosing a tool comes later. The first question is: which defects would cost the most if they reached production? Journeys that generate revenue, handle sensitive data or carry regulatory obligations are often the first candidates.

Four criteria to prioritise

• Frequency: a test run for every release pays back more than one run once a year.
• Criticality: a payment or login journey comes before an information page.
• Stability: a feature that changes every week will be expensive to maintain as an automated test.
• Effort: a test that is simple to write and stabilise quickly demonstrates the value of the approach.

Illustrative example

Picture an online subscription application. Login, price calculation and application approval run at every release and directly affect customers: they are good candidates. A new personalisation screen still being designed can stay manual while it evolves.

Keep the test pyramid in mind

Many checks can be done below the interface: unit tests on the development side, then API tests. They are faster and more stable. End-to-end UI tests are kept for journeys that must be seen as a user would.

Common mistakes

• Trying to automate 100% of existing manual test cases.
• Automating before test data and environments are stable.
• Tolerating flaky tests: the team ends up ignoring every result.
• Not planning who will maintain the tests once written.

Where to start

List around ten journeys, score them against the four criteria above, then automate the top three or four. Measure their stability before expanding.