End-to-End Testing of a Service

End-to-end testing follows a complete service journey, from the customer's first action to the final outcome, across every system, team, and supplier involved. Component testing checks that each part works on its own. End-to-end testing checks that the parts work together. That distinction matters because many real failures live at the joins: data passed in the wrong format between two systems, a confirmation that never reaches the customer, a manual step that nobody owns, or a supplier response that the firm's system misinterprets. Under DORA, end-to-end testing helps show that a critical function, taken as a whole, would hold up, rather than that its individual components each passed in isolation.

Consider a mortgage application journey. A customer submits an application online, identity checks run, a credit assessment is requested from a supplier, a valuation is ordered, a decision is issued, and the customer receives a clear outcome. An end-to-end test follows that whole chain, with realistic data, including the points where the journey branches: an identity check that needs manual review, a valuation that returns late, or a decision that requires additional documents. Testing only the online form, or only the decision engine, would miss the handover where an application can stall silently. The journey, not the component, is the unit of testing.

Joins fail for ordinary reasons. Two teams may each assume the other owns a step. A supplier may change a response format without the firm noticing. A system may handle a normal case well and an exception case badly, and exceptions are exactly what the joins produce. End-to-end testing is designed to surface those cases, by including retries, timeouts, partial data, and manual interventions in the test journey. A test that follows only the happy path, where every step succeeds first time, will confirm that the service works when nothing goes wrong. It will say little about the service customers experience when something does.

End-to-end testing needs the people who actually operate the service, not only the team that built one component. That includes operations staff who handle exceptions, customer teams who field enquiries, and supplier contacts where a supplier step is part of the journey. Their participation reveals a different class of finding: a procedure that exists on paper but cannot be followed at the pace of real work, a contact who is unavailable outside office hours, or a workaround that depends on one experienced individual. Those findings are as important as technical defects, because in a disruption the service is recovered by people following procedures, not by systems alone.

Realism here means real data shapes, real supplier behaviour, and real handovers, within safe boundaries. Scope means deciding which journeys to test first. A firm cannot test every journey at full depth, so it should prioritise the journeys behind critical functions, and within them, the branches where failure would harm customers most. The test record should state which journeys and branches were covered, and which were not. A claim that a service was tested end to end, without naming the journeys, is too vague to rely on. The named journey, with its branches and its gaps, is the evidence.

Findings from an end-to-end test often cut across teams, which makes ownership harder and more important. A data format problem may need a supplier change, a process change, and a system change together. Each finding therefore needs a single owner who can coordinate that change, even if several teams contribute. After remediation, the same journey should be retested, including the branch that failed, to confirm the fix in context rather than in isolation. Over time, a set of tested journeys becomes a map of the service as it actually runs, and that map is useful far beyond testing: it informs incident response, change planning, and the scenario exercises covered elsewhere in this cluster.

That map also helps when a new change is proposed, because the firm can see at once which journeys the change touches and which branches would need retesting before the change goes live.