Catalog
method#Quality Assurance#Reliability#Integration#Observability

End-to-End Tests (E2E)

End-to-end tests validate complete application workflows and interactions across system boundaries to verify integrations, data flows and business processes in realistic scenarios.

End-to-end tests validate full application workflows from user interaction through backend systems.
Established
Medium

Classification

  • Medium
  • Technical
  • Design
  • Intermediate

Technical context

CI/CD system (e.g. Jenkins, GitLab CI)Issue tracker (e.g. Jira) for defect trackingMonitoring and alerting for production alignment

Principles & goals

E2E tests validate real user flows, not only technical integrations.Limit E2E tests to critical paths to reduce runtime and maintenance.Isolated, reproducible test environments and managed test data are essential.
Build
Domain, Team

Use cases & scenarios

Compromises

  • False confidence if E2E tests are poorly maintained.
  • High test flakiness leads to wasted debugging effort.
  • Costs and delays due to slow test runs.
  • Limit E2E tests to a few critical scenarios.
  • Use deterministic test data and idempotent setups.
  • Parallel execution and sharding to reduce runtime.

I/O & resources

  • E2E test cases and acceptance criteria
  • Stable test environments with access to required services
  • Versioned test data or anonymization processes
  • Test reports with failures, runtimes and flakiness metrics
  • Release recommendation
  • Artifacts for stakeholder review

Description

End-to-end tests validate full application workflows from user interaction through backend systems. They verify integrations, data flows, and business processes in realistic environments. E2E tests detect regressions but are costly to maintain and can be flaky; combine them strategically with unit and integration tests and manage test data and environments.

✔

  • Detects integration failures and regressions in real flows.
  • Supports acceptance processes and stakeholder validation.
  • Increases confidence in end-to-end integrity of critical business processes.

✖

  • High maintenance effort for UI-dependent tests.
  • Long runtimes and slower feedback cycles in CI.
  • Sensitive to flaky external services or unstable environments.

  • First-pass rate

    Share of E2E runs that pass without failures on their first execution.

  • Average run duration

    Mean execution time of the E2E suite in the CI environment.

  • Defect detection rate

    Number of production defects found per E2E run or release.

E2E suite for a SaaS product

Use of a stable E2E suite in CI to verify critical paths before each release.

Product acceptance via stakeholder tests

Stakeholders execute selected E2E scenarios for acceptance in a demo environment.

Integration test for microservice architecture

E2E tests validate message flows between multiple microservices and external APIs.

1

Identify critical business flows and prioritize test cases.

2

Provide reproducible test environments and data.

3

Automate E2E scripts in a stable framework (e.g. Cypress, Selenium).

4

Integrate E2E suite into CI with parallelized runs.

5

Monitor flakiness and analyze root causes systematically.

6

Continuously maintain tests and remove non-value-adding cases.

⚠️ Technical debt & bottlenecks

  • Outdated, unstructured test suites without modularization.
  • Missing test data management and unrepeatable setups.
  • Manual synchronization steps in automation scripts.
Test environmentsTest data provisioningFlaky tests
  • Running full E2E suites serially every day blocking CI pipelines.
  • UI-sensitive locators without error handling leading to unstable tests.
  • Using E2E tests as a substitute for missing unit tests.
  • Unclear ownership for test maintenance across teams.
  • Over-tight coupling to internal implementation details.
  • Unaccounted network latencies in test environments.
Test automation (UI/API)Scripting and CI configurationSystem and integration understanding
Integration complexityData consistency across servicesTest environment isolation
  • • Constraints due to API rate limits of external services
  • • Differing system configurations between test and production
  • • Privacy and anonymization of real data