When to Use E2E Testing: Best Practices & Real Examples

Shipping more code does not automatically mean delivering more value. In SmartBear’s 2026 survey of software quality leaders, 60% said they had experienced application quality problems because development moved faster than testing, while 64% were concerned that applications were not being tested across all deployment environments.

Adding hundreds of end-to-end tests is not the answer, though. Large E2E suites are expensive to run, difficult to maintain, and often slow down the very delivery process they are meant to protect.

The better question is: Which risks can only be checked by running a complete user journey through the real system?

This guide focuses on when to use E2E testing, when to choose a lower test level, and which best practices keep an E2E suite useful. For a broader explanation of the methodology, see our complete guide to end-to-end testing.

When should you use E2E testing?

Use an E2E test when all or most of the following are true:

• The workflow is critical to revenue, safety, compliance, or customer trust.

• It crosses several application components or services.

• A failure may not be visible at the unit or API level.

• The workflow has broken before or changes frequently.

• The final result must be validated from the user’s perspective.

• The cost of a production failure is higher than the cost of maintaining the test.

In practical terms, E2E testing is best reserved for a relatively small number of high-value workflows.

A useful rule is that an E2E test should protect an outcome, not merely confirm that a page loads.

Industry data: Why selective E2E coverage matters

Validating complete workflows remains difficult even for experienced teams. TestRail’s 2025 Software Testing & Quality Report identified end-to-end testing across integrated systems as the leading QA challenge, reported by 33% of respondents. Developing automated tests followed closely at 32%.

The same report found that:

• 35% of teams ranked increasing test coverage as their top QA priority.

• 20% prioritized reducing defects in production.

• 13% named automating more tests as their primary objective.

• 70% tracked test pass and fail rates.

• 60% tracked defects found in production.

• Only 43% tracked the number of automated tests created, while 42% tracked automation execution.

These figures highlight an important distinction: teams want more coverage, but simply counting automated tests does not show whether the important risks are covered. A suite with 1,000 low-value tests can provide less protection than 50 carefully selected E2E scenarios.

The need for cross-system validation is also supported by a large Microsoft Azure study. Researchers analyzed 2,051 high-impact incidents across 468 services and found that:

• More than 75% of incidents involved multiple contributing factors.

• More than 50% involved four or more factors.

• An incident involved approximately 3.6 contributing factors on average.

• Dependencies contributed to 37% of the incidents studied.

The researchers also noted that anticipating these combinations through integration and E2E tests is difficult. The finding does not mean that E2E automation can prevent every production incident. It shows why testing components only in isolation leaves an important gap.

1. Use E2E tests for critical user journeys

The strongest candidates are workflows directly connected to the product’s core value.

Examples include:

• Creating and verifying an account

• Signing in with multi-factor authentication

• Completing checkout and payment

• Upgrading a subscription

• Booking an appointment

• Sending or receiving money

• Uploading medical data

• Inviting a team member and assigning permissions

• Cancelling an order and receiving a refund

The E2E scenario should verify more than the visible confirmation message. A checkout test, for example, may need to confirm that:

That is where E2E testing adds value: each component might pass its individual tests while the overall transaction still fails.

DeviQA observation

Start with the journeys product and support teams would classify as “the product is unusable if this breaks.” This normally produces a much more valuable initial suite than converting an existing manual regression checklist line by line.

2. Use E2E testing for cross-system workflows

Modern products depend on identity providers, payment processors, CRM systems, analytics platforms, messaging queues, cloud storage, and numerous internal services.

Use E2E tests when a user action must travel through several of these boundaries before the expected outcome appears.

Good candidates include:

• SSO login followed by role-based access

• Payment followed by order creation and invoicing

• File upload followed by processing and notification

• Booking followed by calendar synchronization

• Customer registration followed by CRM creation

• Password reset followed by email delivery and session invalidation

TestRail’s finding that 33% of teams see E2E validation across integrated systems as their leading challenge is understandable: no single service owner necessarily sees the entire workflow.

However, not every integration variation belongs in an E2E suite. Validate detailed payload combinations, error codes, and boundary conditions through API, contract, and integration tests. Keep only representative business journeys at the E2E level.

For a closer comparison of the two levels, see our guide to integration and end-to-end testing.

3. Use E2E tests before high-risk releases

A focused E2E run is valuable before releases that change several parts of the system or carry substantial business risk.

Typical examples include:

• A major checkout redesign

• A payment-provider migration

• A new authentication system

• Database or cloud migration

• Introduction of a new user role

• Launch in a new country

• A significant mobile application update

• Changes to pricing or subscription management

• A release before a high-traffic event

The suite should act as a release-confidence check, not repeat every test already executed at lower levels.

A risk-based pre-release suite might contain:

• Five to ten business-critical smoke journeys

• Journeys affected by the release

• Previously failed production scenarios

• Tests involving changed integrations

• Selected negative and recovery paths

For example, after replacing a payment provider, testing only a successful card payment is not enough. The release-specific E2E scope may also include a rejected payment, interrupted redirect, duplicate submission, refund, and delayed provider callback.

4. Use a small E2E smoke suite in CI/CD

Running the entire E2E regression suite after every commit can make feedback too slow. A smaller smoke suite can still prevent obviously broken builds from progressing.

Good CI smoke tests are:

• Business-critical

• Stable

• Independent

• Fast enough to provide actionable feedback

• Easy to diagnose

• Limited to supported, representative configurations

A practical pipeline can separate E2E tests into several layers:

The exact runtime depends on the product. A five-minute smoke suite may be realistic for one platform and impossible for another. The goal is not an arbitrary number; it is feedback fast enough that the team will act on a failure.

5. Use E2E tests for roles, permissions, and data lifecycle

Many serious product defects are not isolated UI problems. They appear when data changes state or passes between users with different permissions.

Examples include:

• A manager approves an employee request.

• A doctor shares a report with a patient.

• An administrator disables a user’s access.

• A buyer submits an order that a supplier fulfills.

• A document moves from draft to approved and archived.

• A refund changes payment, order, inventory, and accounting records.

These workflows are well suited to E2E testing because the final result depends on several actions, roles, and systems.

The test should verify both sides of the workflow. If an administrator revokes access, for example, confirm that the user cannot open the protected resource, existing sessions are handled correctly, and the audit trail records the change.

6. Use E2E tests during modernization and migration

Legacy platforms often lack reliable unit and integration coverage. A small set of characterization-style E2E tests can provide a temporary safety net while the system is refactored.

They are particularly useful during:

• Monolith-to-microservices migration

• Database replacement

• Framework upgrades

• Cloud migration

• API version transitions

• Authentication modernization

• Replacement of third-party providers

Select workflows that must behave identically before and after the change. Run the same scenarios against both versions where possible, and compare business outcomes rather than implementation details.

E2E tests should not become a permanent substitute for missing lower-level coverage. As the architecture improves, add unit, component, contract, and API tests that localize failures more effectively.

When not to use E2E testing

E2E testing becomes counterproductive when it is used as the default solution for every requirement.

Do not use E2E tests for exhaustive business-rule coverage

Consider a loan calculator with dozens of combinations of amount, term, rate, customer category, currency, and rounding rule. Driving every combination through a browser would create slow, repetitive tests.

Test the calculation logic at the unit level and validate representative API combinations. Keep one or two E2E scenarios to confirm that the UI sends the correct data and displays the result.

Do not use E2E tests to find the exact source of a failure

An E2E failure tells you that a journey is broken. It does not automatically reveal which service, deployment, configuration, dataset, or dependency caused the problem.

Unit and integration tests remain better diagnostic tools. E2E tests need logs, traces, screenshots, network records, and correlation IDs to make investigation practical.

Do not duplicate lower-level tests through the UI

If an API test already validates 40 input combinations, recreating those combinations in the browser adds maintenance cost without proportional risk reduction.

Use the E2E layer to confirm that the complete system can deliver the business result. Use faster levels for detailed coverage.

Do not automate unstable requirements too early

A workflow that changes every few days can consume more automation effort than it saves. During early product discovery, exploratory and manual testing may provide faster feedback.

Automate once the flow is important enough and sufficiently stable – or when its risk justifies maintaining the test despite frequent change.

Do not use functional E2E tests as a substitute for specialized testing

A successful user journey does not prove that the product is secure, accessible, or scalable.

Use dedicated approaches for:

• Performance and stress testing

• Penetration and security testing

• Accessibility testing

• Compatibility testing

• Resilience and chaos testing

• Data migration validation

An E2E scenario may be included in these activities, but the functional test alone is not sufficient.

A practical way to select E2E test candidates

At DeviQA, we find it useful to assess a proposed scenario against five questions. Score each answer from 0 to 2.

As a working heuristic:

• 7–10 points: strong E2E automation candidate.

• 4–6 points: consider one targeted E2E scenario, supported by lower-level tests.

• 0–3 points: keep the coverage at the unit, component, API, or integration level.

This is not a universal formula. It is a prioritization tool that helps product, engineering, and QA teams discuss risk using the same criteria.

A payment flow might score nine because it is revenue-critical, crosses external systems, changes regularly, and has several failure modes that only appear after a full transaction. A tooltip might score zero or one.

E2E testing best practices

1. Build tests around business outcomes

Avoid structuring tests as long lists of UI actions without a meaningful result.

A scenario called “Open account page and click buttons” communicates little. “Existing customer upgrades from Basic to Pro and receives the correct entitlement” defines an outcome that product, engineering, and QA teams can understand.

2. Keep most coverage below the E2E layer

There is no credible universal rule that E2E tests must represent exactly 10% or 20% of a test suite. The right balance depends on architecture, risk, regulatory requirements, and release cadence.

The principle is more useful than a fixed percentage:

• Unit tests cover logic and edge cases.

• Component tests cover isolated UI behavior.

• Contract tests cover service expectations.

• API and integration tests cover data exchange.

• E2E tests cover selected business journeys.

The higher the test sits in the stack, the stronger its business justification should be.

3. Create data through APIs where possible

Using the UI for every setup step makes tests unnecessarily slow and fragile.

If a scenario checks invoice approval, create the customer and draft invoice through an API or controlled fixture. Use the UI for the behavior under test: authentication, approval, and visible result.

The same principle applies to cleanup. Remove or reset data through reliable backend mechanisms rather than depending on another long UI sequence.

4. Give every test isolated data

Shared users, orders, and accounts cause collisions when tests run in parallel. They also make results depend on execution order.

A stable approach includes:

• Unique data for every run

• Predictable account states

• Idempotent setup and cleanup

• Automatic expiration of test records

• Separate credentials for different roles

• No dependency on test execution order

Test data is an industry-wide obstacle. Capgemini’s World Quality Report 2025–26 found that 60% of organizations struggle with secure, scalable test data. The same report found that synthetic-data use increased from 14% in 2024 to an average of 25% in 2025.

Synthetic data can help, but only if it preserves the relationships and constraints required by the workflow.

5. Synchronize with application state, not time

Fixed delays such as wait(5000) make suites both slow and unreliable.

Wait for observable conditions instead:

• A specific API response

• A status change

• A visible element

• Completion of a background job

• A message arriving in a controlled queue

• A database or API state becoming available

Use stable selectors created specifically for testing. CSS classes tied to styling and brittle XPath expressions tend to break during harmless UI changes.

6. Decide which dependencies should be real

“End to end” does not mean every test must call every live third-party service.

A balanced approach can include:

• Contract tests for detailed provider behavior

• Service virtualization for rare or expensive conditions

• Provider sandboxes for a small number of realistic journeys

• Production monitoring for conditions that cannot be reproduced safely

For a payment provider, most edge cases can be covered through API and sandbox tests. A few E2E scenarios can verify that the application handles the complete redirect, callback, order update, and customer notification flow.

7. Make failures diagnosable

An E2E test that reports only “checkout failed” creates a new investigation task.

Capture enough evidence to answer where the journey stopped:

• Screenshot or video

• Browser console

• Network requests and responses

• Application and service logs

• Distributed trace or correlation ID

• Test-data identifiers

• Environment and build version

• Retry history

Microsoft’s Azure incident research found that more than 75% of high-impact incidents involved multiple contributing factors. That is another reason E2E failures need cross-system evidence rather than a screenshot alone.

8. Control flakiness aggressively

Flaky tests train engineers to ignore failures.

In a widely cited Google benchmark, approximately 1.5% of all test runs produced a flaky result, nearly 16% of tests showed some level of flakiness, and 84% of observed pass-to-fail transitions involved a flaky test. Google published these figures in 2016, so they should not be treated as a current universal benchmark. They remain a useful illustration of how quickly intermittent failures can overwhelm a large CI environment.

Set a clear process:

Blind retries may make a pipeline green, but they also hide declining suite health.

9. Run the right suite at the right time

Do not make every developer wait for every browser, role, localization, and data combination.

Tag tests by:

• Business criticality

• Feature

• Risk

• Browser or device

• User role

• Environment

• Execution frequency

• Expected runtime

This lets the pipeline run a small blocking suite after each merge while broader combinations run nightly or before release.

10. Treat E2E automation as production code

E2E tests need design standards, code review, ownership, documentation, and refactoring.

Review the portfolio regularly:

• Does the workflow still exist?

• Is it still business-critical?

• Is another test already covering the same risk?

• Could the scenario move to a faster level?

• Is the test failing for meaningful reasons?

• Has its execution time increased?

• Does it still use supported data and dependencies?

The goal is not to preserve every test ever written. It is to maintain a reliable set of tests that protects current product risks.

Metrics that show whether an E2E suite is working

A high pass rate does not automatically mean the suite is healthy. A suite can pass consistently while missing important journeys.

Track a combination of reliability, speed, coverage, and outcome metrics.

TestRail found that 70% of teams monitor pass/fail rates and 60% track production defects. Those metrics become more informative when connected. If pass rates remain high while production defects in covered journeys increase, the suite is testing the wrong things or asserting too little.

Real E2E testing results from DeviQA projects

Healthcare platform: From 2.5 weeks to one day

For Abbott’s glucose-monitoring ecosystem, DeviQA built an automated regression solution covering interconnected web applications, cloud services, devices, browsers, and 27 localizations.

According to the published Abbott case study, the engagement produced:

• More than 1,700 automated scenarios

• 90% application coverage

• Support for 27 localizations

• Coverage across more than 20 devices

• Regression time reduced from 2.5 weeks to one day

• Smoke testing reduced from seven days to one day

• An 18-fold faster regression run

The number of tests was not the decisive factor. The value came from organizing them around real product configurations, running them through CI, and making the regression scope selectable by browser and localization.

This is a case where extensive E2E coverage was justified: the platform had many user types, devices, localizations, and connected systems, while failures could affect access to healthcare information.

Dental SaaS: Fast smoke feedback plus broad regression

For a dental-management platform spanning web and mobile applications, DeviQA introduced a QA process and built both API and E2E automation.

The published Arklign case study reports:

• More than 900 automated E2E tests

• More than 100 automated API tests

• 24 parallel execution threads

• Automated smoke tests running in approximately 10 minutes

• 95% test coverage

• More than 100 successful web releases and 50 mobile releases

The useful lesson is the separation of feedback layers. API automation handled appropriate lower-level coverage, a short smoke suite provided fast release feedback, and the larger E2E portfolio supported broader regression.

A large suite became practical only after parallel execution, CI/CD integration, and clear separation between smoke and regression scopes.

E2E testing checklist

Before adding a new E2E test, confirm that:

• The workflow is important to revenue, safety, compliance, or user trust.

• It crosses components that are already tested individually.

• The risk cannot be covered more effectively at a lower level.

• The expected business outcome is explicit.

• Setup and cleanup can be automated reliably.

• Test data is isolated.

• Dependencies have a defined sandbox, mock, or virtualization strategy.

• The scenario can run independently.

• Failures will include sufficient diagnostic evidence.

• The test has an owner.

• The test is assigned to the correct pipeline stage.

• Its value justifies its execution and maintenance cost.

When implementing the scenario, follow a consistent structure. Our guide on how to build E2E test cases covers test-case design in more detail.

Build confidence without slowing delivery

E2E testing is most valuable when it protects a small set of outcomes that truly matter: completing a purchase, receiving a medical report, approving an invoice, managing access, or finishing another core user journey.

Use it when the risk crosses system boundaries and cannot be understood through isolated tests. Keep detailed logic and edge-case coverage at faster levels. Separate smoke checks from full regression, control test data, investigate flakiness, and measure whether the suite is reducing real product risk.

If your team needs help selecting critical journeys, designing the automation architecture, or stabilizing an existing suite, DeviQA’s end-to-end testing services can help you build coverage that supports releases instead of slowing them down.

See how your QA could grow with you

Schedule a call

Frequently asked questions

Should E2E tests run after every commit?

Usually, only a small smoke subset should run as a blocking check after every merge. The broader suite can run nightly, on release candidates, or when relevant components change.

The decision depends on execution time, infrastructure cost, and failure reliability. A fast, stable E2E check can run frequently. A 90-minute cross-browser suite should not block every developer change.

How many E2E tests should a product have?

There is no correct universal number or percentage.

Start with the smallest set that covers critical business journeys and major cross-system risks. Add a scenario when it protects a distinct risk, not simply because another manual case exists.

Monitor suite duration, duplication, flakiness, and defect escapes as the portfolio grows.

Should E2E tests use mocks?

Use real components when the purpose of the test is to validate their integration. Use mocks or service virtualization when a dependency is expensive, unsafe, unavailable, or unable to reproduce the required condition.

Many teams use both: broad E2E coverage against controlled dependencies and a smaller number of tests against realistic provider sandboxes.

Can E2E testing be manual?

Yes. Manual E2E testing is useful for exploratory workflows, new functionality, and scenarios that are difficult to automate.

Automation is more appropriate for stable, repeatable journeys that must be checked frequently. The best strategy often combines automated regression with targeted manual exploration.

Which tool should we use?

The choice depends on the product, technology stack, supported platforms, team skills, and existing CI infrastructure.

For browser applications, Playwright and Cypress are common options. We cover their implementation separately in our Playwright E2E testing guide and Cypress E2E testing guide.

Tool selection matters, but test architecture, data control, observability, and ownership usually have a greater effect on long-term reliability.

About the author

Mykhailo Ralduhin

Senior QA engineer

Mykhailo Ralduhin is a Senior QA Engineer at DeviQA, specializing in building stable, well-structured testing processes for complex software products.