What to automate first when you have no tests at all
Start with the journeys that cost you money when they break.
The short answer
Begin by automating the handful of journeys the business cannot function without — login, checkout, the core workflow — as end-to-end tests running on every commit. Add API tests next because they are faster and more stable, and leave volatile screens to manual testing until the design settles.
Key takeaways
- Cover revenue-critical journeys before anything else; coverage percentage is a poor target.
- API tests give more stability per hour of effort than UI tests.
- Every bug fixed should arrive with a test that would have caught it.
- Delete flaky tests the day they appear.
Teams starting from zero usually ask what coverage percentage to aim for. It is the wrong question — a hundred percent coverage of trivial code catches nothing, and five well-chosen end-to-end tests can catch most of what would actually hurt you.
The order
- 01The money paths. Signup, login, checkout, payment, the main workflow. If these break, the business stops.
- 02The paths you have broken before. Go through your last twenty bug reports and automate the ones that recurred.
- 03API-level tests for business rules — faster, more stable and easier to debug than driving them through a browser.
- 04Permission and role tests, especially in multi-tenant products where a mistake is a data incident.
- 05Everything else, gradually, as screens settle and as bugs teach you where the risk is.
Keeping the suite trusted
- Fast. Under five minutes for the commit suite. Slow suites get bypassed.
- Stable. A test that fails randomly is fixed or deleted the same day.
- Independent. Tests that depend on each other's leftover data fail in confusing ways and get disabled.
- Owned. Somebody is responsible for the suite being green, or it will not be.