What It Actually Means
It is the only kind of test that verifies the thing your customer actually does, all the way through, which is why it catches problems every other layer misses.
What It Uniquely Catches
The failure where everything works and nothing works.
Every component passes its own tests. The integrations are sound. And a button is hidden behind another element on a common screen size, or a redirect after payment goes to the wrong place, or the confirmation email refers to a page that no longer exists. Nobody’s code is wrong. The journey is broken.
For anything where a broken path costs money directly, a checkout, a booking, a signup, a quote request, this is the only automated check that would have caught it.
Why To Use Them Sparingly
They are genuinely expensive to live with, and it is worth being honest about why rather than discovering it later.
They are slow. Seconds or minutes each, against milliseconds for a unit test. A large suite takes long enough that people stop waiting for it.
They are brittle. They break when the interface changes, including when it changes correctly. A button moved or renamed fails a test that is testing something else entirely, and the maintenance is continuous.
They fail intermittently. Timing, network, animations, a slow response. A test that fails one run in twenty for no reason is worse than no test, because the team learns to re-run failures rather than investigate them, and a genuine failure gets re-run alongside the noise.
That last one is the real danger. A flaky suite trains people to ignore red, which removes the value of every test you have.
The Proportion Worth Aiming For
The shape that works is many fast tests underneath and few slow ones on top.
Plenty of unit tests, a solid layer of integration tests, and a small deliberate set of end-to-end tests covering only the journeys that matter commercially. For most businesses that is a handful: the purchase path, the signup, the one or two things customers do most.
Trying to cover every screen this way produces a suite that takes an hour, fails randomly, and gets disabled within a year.
What To Ask
- Which journeys are covered? There should be a short list, and it should match where your revenue comes from.
- How often do they fail for no reason? Ask directly. Frequent flakiness means the suite is already being ignored.
- How long does the full run take? Beyond about ten minutes it stops being part of the routine.
- Do they run before release? A suite that runs on a schedule nobody watches is not protecting the release.
- Do they test on mobile sizes? Most traffic is mobile and most automated testing is not.
The Sensible Position
Ask for end-to-end coverage of the two or three journeys that would cost you real money if they broke, kept fast and kept reliable, and resist expanding it much beyond that.
That is a modest amount of work, it covers the risk that actually matters, and it avoids the far more common outcome: an ambitious suite that becomes a maintenance burden, then a nuisance, then an ignored red light nobody has looked at since spring.
More terms are in the glossary.
