Choosing what to automate first

You have decided automation is worth it in principle, you know the pyramid, and you know flakiness is the enemy. Now the practical question a QA actually faces on a real project: you cannot automate everything at once, so what do you automate first? A team that automates the wrong things ends up with a suite that took months and guards little; a team that automates the right things has a small suite that catches real regressions from week one. This lesson is choosing what to automate, and in what order.

Start from risk and repetition

The two questions that rank every candidate test are the ones from the whole part so far:

How bad is it if this breaks? (risk)
How often will this test run and how stable is it? (repetition and payoff)

Automate first the checks that are high risk and high repetition — the things that would be a disaster if they broke and that you would otherwise re-test by hand every single release. That is where automation buys the most: it removes the most tedious manual work and guards the most important behaviour.

Concretely, on almost any app that means starting with the critical happy paths:

The core journey the product exists for — for a payments app, log in, make a payment, see it recorded and the balance change. If this breaks, nothing else matters.
Login and authentication — everything depends on it.
The two or three flows that, if broken in production, would have people phoning you.

Automate the money path first, not the settings screen. The suite should guard what matters most, from the first test.

Then the tedious, deterministic checks

After the critical journeys, the next best automation targets are the checks that are boring and exact — where a machine plainly beats a human:

Regression of settled features — features that are done, that you re-test every release, and that do not change often. Stable and repetitive: ideal.
Data-heavy and combinatorial checks — validating a rule across many inputs, a calculation across many cases, a table of values. Fifty boundary cases are miserable by hand and trivial in code.
API-level checks — because (the pyramid) they are fast and stable, a lot of your early automation value is at the API, not the UI. Automating the API tests you designed in module 5 is often the highest return per hour of any automation you can write.

This is where you convert your manual test design into a fast, repeatable suite that runs on every change.

What to automate later, or never

Deliberately leave some things for later — or for manual only:

Rarely used or low-risk features — a settings toggle used once a year is not worth a test; test it by hand when it changes.
Unstable, still-changing features — automating them means constant rewrites; wait until they settle.
Anything needing human judgement — look and feel, usability, exploratory testing (the when-to-automate lesson): keep human.
Very hard to automate for little gain — a real third-party payment gateway, a CAPTCHA, a hardware interaction. The reliable-automation effort may exceed the value; a manual check may be the right answer.

Saying "we will not automate that" is a legitimate, senior decision — not a failure. The goal is a suite that is worth its maintenance, not a suite that touches everything.

Building the suite up sensibly

Order and shape matter as much as selection:

Thin end-to-end layer, thick underneath. A few UI tests for the critical journeys, and the bulk of coverage at the API and unit level (the pyramid). Do not start by automating every screen.
Start small and reliable, then grow. A handful of trustworthy tests that always mean something beats a hundred flaky ones. Add tests as features settle and as real regressions teach you where the risk is.
Automate the bugs you have actually had. When a real regression escapes to production, add a test for it so it can never come back silently — this is one of the highest-value tests you can write, because it guards a proven-real risk.
Keep it maintainable from day one (the web-automation module's page objects, fixtures): a suite that is painful to maintain gets abandoned no matter how well chosen.

The picture to aim at: a small, reliable, risk-focused suite — critical journeys covered end to end, the real logic covered fast at the API, tedious combinatorial checks automated, and everything unstable or judgement-based left to skilled manual testing. That is a suite that earns its keep and that people trust — which, as the flaky-tests lesson insisted, is the only kind worth having.

Check your work

Rank by risk and repetition. Automate first what is high-risk (a disaster if it breaks) and high-repetition (re-tested every release). That removes the most tedious manual work and guards the most important behaviour.

Start with critical happy paths. The core journey the product exists for (log in, pay, see it recorded), authentication, and the two or three flows that would have people phoning you. Money path before settings screen.

Then tedious, deterministic checks. Regression of settled features; data-heavy/combinatorial validation and calculations; and API-level checks — often the highest return per hour, since the API layer is fast and stable.

Later or never. Rarely used / low-risk features, still-changing features, judgement-based checks (look/ feel, usability, exploratory), and very-hard-for-little-gain flows (real gateways, CAPTCHAs). Choosing not to automate is legitimate.

Build it up. Thin end-to-end layer over a thick API/unit base; start small and reliable then grow; always add a test for any real regression that escaped; keep it maintainable from day one. Aim for a small, reliable, risk-focused, trusted suite.

Practice

For an app you know, list its flows and rank the top five automation candidates by risk × repetition; name which you would automate first.
Identify the single critical journey that, if broken, means nothing else matters — and sketch it as an end-to-end test.
Pick two checks best automated at the API rather than the UI, and say why.
Name two features of that app you would deliberately not automate, and justify each.
Describe how a production bug that escaped should change your suite, and why that test is high value.
Sketch the intended shape of the suite (how many UI vs API vs unit, roughly) and explain it with the pyramid and the trust argument.

Official documentation

Martin Fowler — The practical test pyramid — Shaping which tests to write and how many.
Google Testing Blog — Just say no to more end-to-end tests — Prioritising lower-level tests over UI ones.
Ministry of Testing — What to automate — Practitioner guidance on choosing automation targets.

Next: the web-automation module — Playwright, and your first automated browser test.