Coverage protects nobody
Eighty percent coverage and a broken checkout in production. That combination exists. I have seen it.
Coverage measures lines of code touched. It says nothing about the path the money takes. A suite that thoroughly tests your date-formatting helpers and never your payment funnel reports an excellent number and protects you from nothing.
The question is not "what percentage?". It is "which journeys must never break?"
Choosing the journeys
Three questions produce the list, and it is always shorter than people expect.
Where does the money go through? Sign-up, add to basket, pay, confirm. That path first.
What generates support calls? Your tickets are a map of your failure points, free and already written.
What cannot be recovered? A broken layout gets fixed tomorrow. A lost order, or a confirmation email that never left, does not.
On most products that gives you five to fifteen scenarios. Not five hundred. A suite of five hundred tests nobody watches is worth less than eight tests everybody watches.
Three rings, not one
The common mistake is putting everything at the same point in the pipeline.
Ring 1, the pull request gate. Critical journeys, nothing else. Hard target: under ten minutes. Past that, developers learn to route around it, and a gate people bypass is no longer a gate.
Ring 2, post-deployment smoke. The same journeys, replayed against the real environment right after release, with real configuration and real third-party services. This ring catches configuration mistakes, and those are more frequent than code regressions.
Ring 3, production monitoring. The two or three journeys carrying revenue, replayed against production every fifteen minutes, continuously. This is the only thing that genuinely answers "no regression in production", because it is the only one looking at production.
Testing in production without polluting it
This is the objection every time, and it is a fair one.
A dedicated test account, flagged as such in the database, excluded from analytics and billing. Data created and then deleted by the test itself. For payments, the provider's test card, or stopping the scenario just before the charge, which already covers ninety percent of the risk. And a naming convention that makes cleanup possible even after a failure.
That is a day of design. It saves you learning about an outage from a customer.
Flakiness is the enemy
A suite that fails randomly one run in ten is worse than no suite. Within three weeks the team re-runs without reading, then merges without waiting. You are paying the cost and no longer getting the protection.
The discipline that works: a flaky test is quarantined the same day. It leaves the gate, it keeps its ticket, it is fixed that week. The thing never to do is disable it quietly. That is how suites die, one `skip` at a time.
The metric worth tracking
Not the number of tests. Not the coverage percentage.
The time between the journey breaking and you knowing about it.
With nothing in place, that number equals however long a customer takes to email you. With ring 3, it is fifteen minutes. That is the whole difference, and it is the only figure worth putting on a wall.
What this does not replace
Detection is not correction. Knowing within fifteen minutes that payment is broken only helps if you can roll back fast. Reversible deployments and feature flags are the other half of the system.
Tests tell you what. Rollback decides what it costs.