Best for
- Deciding what deserves end-to-end coverage (and what does not)
- E2E suites that take an hour and break on every CSS change
- Proving the money paths work, browser to database and back
What you give it
- Your product's critical flows and your current e2e suite, if one exists
What you get back
- The shortlist: which journeys earn e2e coverage, with the reasoning per inclusion AND exclusion
- Each scenario scripted: steps, assertions at the points that matter, test data strategy
- Robustness rules applied: selectors, waits and data that survive redesigns
How it works
- Selects by the e2e question: does this journey prove an integration that NO cheaper level can? Money, auth and data handoffs usually qualify; form validation does not.
- Scripts journeys as a user would travel them, asserting at the consequential points (the order exists, the email sent) — not at every pixel.
- Applies the robustness rules: semantic selectors, event-based waits (never sleeps), each test owning its own data.
- Prices every scenario: runtime and maintenance are the budget; each journey must out-earn its cost.
Example
You: We have 300 e2e tests that take 70 minutes and fail daily. What should we actually have?
Result: Fourteen journeys: signup-to-first-value, the three purchase paths, the refund, password reset, the permission boundary, and seven more — each proving an integration no lower level can. 260 of the 300 existing tests retest logic already unit-covered; mapped for retirement. The fourteen run in 9 minutes with stable selectors and per-test isolated data — and they caught the next real integration break.
Limits — please read
- E2E proves integration, not every behaviour; the excluded cases belong to cheaper levels — the map says where.
- True third-party calls (payments) run against sandboxes with the gap documented.
- Some flake sources (real networks, real browsers) can be minimised, not abolished; quarantine rules handle the rest.