Research guide
What Should You Actually Test End-to-End?
You can’t — and shouldn’t — test everything end-to-end. This guide gives a framework for choosing the journeys that matter: the ones that protect revenue, trust, and access.
Start from what breaks the business
Rank every journey by blast radius: what happens to revenue, trust, and access if it breaks. Login, checkout, payments, and the core action usually top the list.
A journey that is rarely used but expensive to fix can still matter, but the priority order starts with revenue, trust, and access.
Map the critical journeys
Signup to first value, login to session, browse to checkout to receipt, invite to permission. Each is a chain of screens, and each chain is a candidate for one E2E test.
Mapping journeys instead of pages keeps the suite aligned with how users move through the product.
Weight by change frequency and risk
A stable page rarely needs E2E coverage. A page that changes with every release needs it most. Combine blast radius with change rate to pick what to test now.
The test list should be a living decision, revisited when the product, providers, or UI change.
Leave room for smoke coverage
Keep a small smoke set of the most important journeys running after every deploy, so a broken build is caught before users see it.
Smoke and full journeys are different jobs. Smoke answers “is the build alive,” and the journey suite answers “does the flow still work.”
Revisit the list as the product changes
A new payment provider, a new auth flow, or a new subscription tier changes what needs E2E coverage. Re-run the selection and keep a written shortlist so the change is deliberate.
Without a written shortlist, the suite grows by whoever wrote the last test, and coverage drifts from risk.
From selection to coverage
Once the journeys are chosen, describe each one in plain language and let the test adapt to the current interface.
For writing those journeys well, use the writing-good-test-cases guide and the 50-examples list.
Key takeaways
- Choose journeys by blast radius: revenue, trust, and access.
- Weight by change frequency, not just importance — stable pages need less E2E.
- Keep a written shortlist and revisit it when the product changes.