The Essentials in 30 Seconds
- End-to-end (E2E) testing simulates a complete user journey to verify that all components of a system work together: user interface, back end, database, and third-party services.
- It detects integration failures that unit and integration tests miss.
- 72% of organizations use some form of test automation (GitLab DevSecOps Survey 2024), but only 18% have fully automated their regression testing (Capgemini World Quality Report 2024–2025).
- E2E tests should remain focused: 5 to 10% of the total test suite, concentrated on critical workflows.
- Mr Suricate enables you to automate end-to-end (E2E) tests using a no-code approach, without any development skills.
A sign-up funnel that validates each step on the front end but never generates the contract on the back end. On the banking side, a transfer that succeeds in the test environment but fails in production due to a change in the payment provider’s API. Or a registration form that doesn’t send any data to the CRM after an update. Unit tests don’t detect any of these issues. That’s the role of end-to-end testing.
At Mr Suricate, end-to-end (E2E) testing forms the foundation of the automation solutions we implement for our clients. This guide explains what end-to-end testing is, how it fits into the testing pyramid, and how to implement it in five practical steps.
What is end-to-end (E2E) testing?
End-to-end testing (E2E) is a software testing method that verifies an application’s functionality by simulating a complete user journey. From the first click to the final confirmation, the test goes through all layers of the system: user interface, business logic, database, and third-party APIs.
In other words, the goal is to verify that all components communicate properly with one another under conditions similar to those in production. If any link in the chain fails, the test fails.
Unlike unit tests (which isolate a single component) or integration tests (which verify communication between two modules), E2E testing adopts the end user’s perspective. In practical terms, it focuses not on the internal workings of the code, but on the observable result.
Comparison of End-to-End Testing, Unit Testing, and Integration Testing
| Criterion | Unit Test | Integration Test | E2E Test |
|---|---|---|---|
| Scope | An isolated component | Two or more modules | Complete User Journey |
| Execution Speed | Very fast (ms) | Speed (seconds) | Slow (minutes) |
| Maintenance Cost | Low | Medium | High |
| Detects integration bugs | No | Partially | Yes |
| Simulates real-world use | No | No | Yes |
| Fragility (flakiness) | Very low | Low | High |
| Recommended portion of the suite | ~70 % | ~20 % | ~5–10% |
This diagram illustrates the testing pyramid model formalized by Mike Cohn. The broad base consists of fast and stable unit tests. The narrow top comprises E2E tests, which are slower and more expensive but essential for validating critical workflows.
Why E2E Testing Is Essential (Despite Its Limitations)
E2E tests are slow, fragile, and expensive to maintain. And yet, no serious testing strategy can do without them. Here’s why.
They detect what other tests miss. A unit test verifies that a component does what it’s supposed to do. An E2E test verifies that the final result matches what the user expects. The distinction is fundamental: each component may function perfectly on its own but produce an inconsistent result when they are put together.
They protect the user flows that generate revenue. Whether it’s an e-commerce checkout, signing up for an insurance policy, booking a trip, or onboarding a SaaS user, these critical user flows involve 5 to 10 different components. A single point of failure is enough to block the conversion. E2E testing is the final safety net before production.
They reduce the risk of regression. According to the 2024 GitLab DevSecOps Survey, 72% of organizations use some form of test automation. But the 2024–2025 Capgemini World Quality Report reveals that only 18% have fully automated their regression testing. Automated end-to-end (E2E) tests bridge this gap on the most critical test paths.
The Challenge of Flaky Tests
The main criticism of E2E tests is their instability: a test that passes and then fails on the same code, without any changes. This is what’s known as a “flaky” test.
The Bitrise Mobile Insights 2025 report (10 million builds analyzed over 3.5 years) shows that the proportion of teams dealing with flakiness rose from 10% in 2022 to 26% in 2025. An academic study (Eck et al.) indicates that 58% of developers deal with flaky tests at least once a month.
In practice, the main causes are dependencies on unstable third-party services, test data shared across environments, variable network latencies, and fragile interface selectors.
How to reduce flakiness:
- Isolate test data by run
- Use intelligent retry mechanisms (no blind retries)
- Equipping maintenance: on Mr Suricate The AI classifies the cause of each failure and proposes a correction that the team validates.
- Eliminate recurring flaky tests rather than ignoring them (an ignored test has no value)
The Two Types of E2E Tests
Horizontal E2E Testing
Horizontal testing covers a complete user journey throughout the entire application. Here are a few examples by industry:
- E-commerce: log in → search for a product → add to cart → checkout → order confirmation
- Online banking: strong authentication → check balance → add payee → transfer → confirmation and notification
- B2B SaaS: account creation → onboarding → project setup → first business action → data export
This is therefore the most common type of E2E test. It validates the end-to-end user experience as the customer actually experiences it.
Vertical E2E Test
Vertical testing breaks the application down into layers (UI, API, database) and tests each layer thoroughly on its own. It often precedes horizontal testing: by verifying each layer separately, issues are isolated before testing the entire application.
Implementing E2E Testing in 5 Steps
1. Identify critical paths
However, not all user flows warrant an E2E test. The 5–10% rule applies: focus your end-to-end testing on the flows that generate revenue, reach the most users, or are most likely to fail.
Examples of critical paths:
- Registration and Login (including SSO and password recovery)
- Complete purchasing process (search → shopping cart → checkout → confirmation)
- Online Enrollment (Insurance, Health Insurance, Loans)
- Business Forms (Quotes, Reservations, Demo Requests)
- Workflows involving third-party APIs (payment, CRM, ERP, messaging)
- Logistics Workflow (Order Tracking, Inventory Management, Shipping)
2. Choose an E2E testing tool
In summary, the choice of tool depends on the team's technical skills and the volume of tests to be maintained.
No-code tools: Mr Suricate, Leapwork. Accessible to non-developers; maintenance is made easier by self-healing. Suitable for autonomous QA teams.
Open-source frameworks: Selenium, Cypress, Playwright (web), and Appium (native mobile, hybrid, and mobile web). They offer greater flexibility but require development skills and a significant investment in script maintenance. See our comparison of automated testing tools to make an informed choice.
Cloud platforms: BrowserStack, Sauce Labs. Useful for large-scale cross-browser and cross-device testing without having to maintain your own testing infrastructure.
3. Design test cases
Each E2E test case must simulate a real-world usage scenario. It includes:
- The Specific Steps of the User Journey
- Input data (usernames, products, amounts)
- Checkpoints at each stage (not just the final result)
- The expected result
In other words, a good E2E test is not a technical script. It is the translation of a business workflow into verifiable steps. The involvement of Product Owners and business teams at this stage is a key factor for success.
4. Run in an environment similar to production
E2E tests are only valuable if they are run under realistic conditions. The test environment should replicate the production environment as closely as possible: the same server configurations, the same third-party services, and representative data.
Integration into the CI/CD pipeline allows tests to run automatically with every deployment. Continuous testing detects regressions before they reach users.
5. Analyze, correct, iterate
An E2E test that fails is only useful if the team can quickly identify the cause. Modern tools provide screenshots, execution videos, and detailed logs for each step of the process.
Three habits to develop:
- Fix broken tests or delete them (never ignore them)
- Track the flakiness rate as an indicator of pipeline health
- Review the test cases with every major update to the application
The Role of AI in End-to-End Testing in 2026
AI is transforming two critical aspects of end-to-end testing: creation and maintenance.
Self-healing. When an application's interface evolves, the selectors for its elements (buttons, fields, links) change. Without self-healing, each modification breaks existing tests. Modern platforms use AI to detect these changes and automatically update the selectors, significantly reducing test maintenance time.
Automated test case generation. Generative AI can propose test scenarios based on functional specifications or recorded user flows. It identifies edge cases that human testers do not always anticipate.
Intelligent analysis of results. AI helps distinguish a true bug from a flaky test by cross-referencing execution results, test history, and recent code changes.
The Capgemini World Quality Report 2024–2025 confirms that 68% of organizations are already using generative AI in their quality engineering. For end-to-end (E2E) testing, the most immediate benefit is a reduction in maintenance time, which is the primary barrier to adopting automation.
Best Practices for E2E Testing
Keep the E2E test suite lightweight— 5 to 10% of the total test suite. Each additional E2E test increases pipeline runtime and the risk of flakiness. Add an E2E test only when the business risk justifies it.
Test in the order of the pyramid. Start with unit and integration tests to fix obvious issues. End-to-end (E2E) tests come last to validate the complete workflows. If an E2E test fails due to a bug that the unit test should have caught, you need to improve the unit test coverage.
Track the data flow. Tracing the data through each component helps identify dependencies and potential points of failure between systems.
Prioritize user flows based on business impact. User flows that generate revenue or reach the most users take priority. An end-to-end (E2E) test on an “About” page does not have the same value as a test on the checkout flow.
Automate your E2E tests with Mr Suricate
Mr Suricate is the French no-code automated testing platform designed for teams that want to test their critical user flows without writing code. The visual scenario editor replicates user actions (clicks, data entry, navigation, submissions), and the solution runs these scenarios at regular intervals on your environments.
Functional, non-regression, end-to-end, performance, accessibility, API, and production monitoring tests: a single platform for all your QA needs.
FAQ
This test simulates a complete user journey to verify that all components of a system work together: interface, back end, database, and third-party services. It validates the application from start to finish, just as a real user would.
A unit test verifies an isolated component of the code. At the next level, an integration test verifies communication between two modules. Finally, an E2E test validates an entire flow through all components. Each level detects a different type of bug. The testing pyramid recommends approximately 70% unit tests, 20% integration tests, and 5 to 10% end-to-end (E2E) tests.
As few as possible, on the most critical workflows. The standard recommendation is to limit E2E tests to 5–10% of the total test suite. Each additional test increases the pipeline’s execution time and the risk of flakiness. Focus on the workflows that generate revenue or affect the most users.
A flaky test is a test that passes and then fails on the same code, without any changes. According to the 2025 Bitrise report, 26% of teams face this issue. Solutions: isolate test data, use self-healing to automatically adapt selectors, and remove recurring flaky tests rather than ignoring them.
AI is used in three key areas: self-healing (automatic updating of test cases when the interface changes), the generation of test cases from specifications, and intelligent analysis of results (distinguishing between true bugs and flaky tests). According to the Capgemini World Quality Report 2024-2025, 68% of organizations already use generative AI in their QA processes.
For teams without dedicated test developers, no-code platforms such as Mr Suricate make it possible to automate quickly. Open-source frameworks (Selenium, Cypress, Playwright) offer more control but require technical skills and an investment in maintenance. The deciding factor is often the total cost of maintenance over 12 months, not the initial cost.
