An end-to-end suite of 340 tests takes four hours and fails spuriously about half the time. The team wants to parallelise it. Is that the right move?

Parallelising treats the symptom

It might halve the runtime. It will not touch the flakiness — in fact parallelisation often worsens it, by exposing shared-state contention that sequential execution hid. And it does nothing about the underlying economics.

At ninety-nine percent per-test reliability, a 340-test suite passes cleanly about three percent of the time. The observed fifty percent implies the tests are individually more reliable than that, but the direction is the same: broad end-to-end suites degrade super-linearly.

The real question: what does each test prove?

Cost grows faster than linearly — runtime, environment, data, and compounding flakiness. Value grows sub-linearly, because test 340 traverses much of the same routing, authentication, session handling and configuration as test 1, and only its final assertion is new.

Somewhere below a hundred tests those curves crossed. Past the crossing point, each addition made the suite slower and less trusted, and an untrusted suite is not a gate.

What to do instead

1. Classify the 340. For each, ask what it uniquely proves.

• Journeys whose failure would be a serious incident — checkout, login, payment. Keep. Typically twenty to forty.
• Business rules and edge cases — pricing, discount logic, validation. Move down to unit and integration level, where they run in seconds and pinpoint the failure.
• Service-to-service compatibility. Move to contract tests. This is usually the largest group and the biggest saving.
• Tests that duplicate another end-to-end test with a different input. Delete.

2. Fix flakiness in what remains rather than across all 340. Quarantine, investigate by category, and treat real non-determinism as a system defect.

3. Then parallelise the reduced suite, which is now worth the effort.

Expected outcome

Roughly 30 end-to-end tests running in fifteen minutes at high reliability, plus a larger, faster set of contract and integration tests providing better failure localisation than the suite they replaced.

The objection you will get

"We are reducing coverage." You are reducing end-to-end coverage and increasing total coverage, because the moved tests run more often, more reliably, and tell you where the fault is. A four-hour suite that fails half the time is not providing the coverage it appears to — it is providing a rerun button.

Track it: change failure rate and escaped defects before and after. If they do not worsen, the coverage argument was about the count of end-to-end tests rather than about risk.