Every conversation about automated testing eventually arrives at the same question: where do we start. The wrong answer is "the login page, then work outwards". The right one comes from asking what a failure would cost, not what is easy to automate.

Rank by what breaking costs, not by what is quick

Write down every journey in your product. For each, answer three questions:

1. What happens to money if this breaks? Directly — payments, deposits, refunds, invoices — or indirectly, like a booking nobody can complete.

2. How long before you would find out? A broken sign-in is reported in minutes. A broken monthly report is discovered on the day someone needs it, three weeks later.

3. How often does it change? Code that is edited weekly breaks weekly. Code untouched for a year rarely does.

The first tests belong to the journeys scoring high on all three: money involved, slow to notice, frequently changed. That is almost never the login page — although sign-in usually earns a place anyway, because everything else is unreachable without it.

The list that recurs

Across the products we have worked on, the same shapes keep appearing near the top:

  • Sign-in, sessions and password reset, including the lockout after failed attempts and the token that expires while a form is open.
  • The money path, from the first click to the balance actually changing — asserted against the balance, not against a confirmation screen.
  • The one journey the business runs on: an order placed, a shift closed, a claim settled.
  • Roles and permissions, because "the wrong role cannot open this page" is a test, not a code review.
  • The report someone senior opens on Monday. Rarely thought of as critical until the Monday it is empty.

Test the bad day, not the good one

The happy path is the one your team already clicks through by hand. It will be green on the morning your system is losing money.

What earns a suite its keep is the deposit that fails halfway, the webhook that arrives twice, the network that drops between the payment and the confirmation, the session that expires mid-form. In our own marketplace those are not adjectives — they are file names: deposit_cardpay, deposit_terminal, token_refresh, reset_lockout. When you brief anyone on testing, ask early which failures you have actually seen in production. That conversation usually rewrites the list.

Why fifteen and not fifty

Fifteen journeys is roughly where a suite starts changing behaviour: enough that a developer trusts a green run, few enough that the suite runs in minutes and stays maintained. Beyond that, each new test adds maintenance for a shrinking amount of risk covered — until the suite is slow, half-ignored, and back where this article started.

Cover fifteen properly, live with them for a month, then add the ones the month taught you to want. That order costs less and ends with a suite people believe. That is the shape of the suite we build in two weeks: fifteen journeys, failure cases included, running on every push.

On the same decision, from another angle: your test suite is red and nobody cares. Here is how that happened.