Comprehensive Guide to End-to-End Testing for Salesforce Professionals

In an era where 88% of customers abandon apps after just two crashes, enterprise leaders face immense pressure to deliver flawless software. End-to-end (E2E) testing has emerged as a critical safeguard, ensuring systems work cohesively in real-world scenarios.

For Salesforce architects and business leaders, mastering E2E testing isn’t just about technical rigor—it’s about protecting revenue, brand reputation, and customer trust.

E2E Testing Basics

E2E testing simulates real user journeys. When performed correctly, it confirms that:

• Applications respond correctly to realistic data and interactions.

• Integrations (like databases, APIs, or third-party services) work harmoniously.

• Critical workflows continue functioning after new releases or hotfixes.

Popular E2E testing methods include

1. Horizontal (checking cross-platform or cross-browser functionalities) and,

2. Vertical (validating layers individually, from database to front end), each offering unique benefits.

Generally, organizations use a mix of approaches/methods depending on the nature of the business, complexity and frequency of tests.

Key Aspects of E2E Testing

• User Journey Simulation: E2E tests mimic user interactions, checking if the software meets business requirements and user needs.

• Comprehensive Coverage: It tests the flow of data across all layers and components of the application.

• Real-World Conditions: Tests are run in environments that mirror production as closely as possible.

Key advantages of E2E testing

• Risk Mitigation - Validates the entire user flow beyond isolated modules.

  • Reduces post-launch defects to a reasonable extent in complex systems

• Workflow Validation: Catches overlooked bugs in complex environments or microservices.

  • Ensures mission-critical processes (e.g., Salesforce lead-to-cash) function seamlessly across integrated platforms like ERP or marketing tools

• Compliance: Ensures accurate data flow and business logic across multiple systems.

  • Critical for industries like healthcare and finance, where audit trails and data integrity are non-negotiable

Common challenges

• E2E tests often run more slowly than unit or integration tests.

• Flakiness can emerge from network instability or dynamic content.

• Frequently changing UI elements can break locators.

Unlike unit or integration tests, E2E answers the critical question: Does the system deliver value in production-like conditions?

E2E Test Pyramid

The Test Pyramid concept suggests structuring tests in layers, with many fast, cheap tests at the bottom (unit) and fewer, more comprehensive tests at the top (E2E). Mike Cohn popularized it, and Martin Fowler refined its practical applications for modern software engineering.

Layers of the Pyramid:

1. Unit Tests (base): Small, isolated, fast. Provide immediate feedback.

2. Integration / Service Tests (middle): Validate modules or services interacting together. Usually fewer in number than unit tests.

3. E2E / UI Tests (top): Comprehensive checks on user journeys to ensure end-to-end reliability.

Picture Credits - https://semaphoreci.com/blog/testing-pyramid

Picture Credits - https://semaphoreci.com/blog/testing-pyramid

• Unit Tests:

• Purpose: To test individual units or components of software in isolation.

• Characteristics: Fast, reliable, and specific. They should cover most of the code base, focusing on edge cases and core functionalities.

• Best Practices: Use mocking to isolate dependencies; aim for high coverage without compromising test speed.

• Integration Tests:

  • Purpose: To verify that different units or services work together correctly.

  • Characteristics: More complex than unit tests, checking interactions between components or with external systems like databases or APIs.

  • Best Practices: Focus on critical interfaces, ensure tests are not too brittle, and balance between coverage and test execution time.

• End-to-End (E2E) Tests:

  • Purpose: To simulate real user scenarios from start to finish across the entire system.

  • Characteristics: Broad in scope, slower to run, and often more brittle due to their dependency on multiple components including UI, backend, and external services.

  • Best Practices: Limit the number to key user journeys; maintain them to avoid flakiness; consider using tools like Selenium or Cypress for automation.

E2E Testing - Architectural Decision Framework

Factor	Unit Tests	Integration Tests	E2E Tests
Speed	Fast	Moderate	Slow
Maintenance Cost	Low	Medium	High
Bug Detection Scope	Narrow	Broad	End-user
Best For	Logic	APIs/Data	Journeys

Popular E2E Variations and Expert Perspectives

Approach	Test Distribution	Key Characteristics	Unique Insights
Google's Pragmatic Approach	- Small Tests (<100ms): Majority - Medium Tests (<15 mins): Some - Large Tests: Few - E2E Tests: <5%	- Categorizes tests by execution time - Emphasizes fast, small tests - Minimizes E2E tests - Focuses on scalability	- Best Suited For: Large-scale enterprises with complex, distributed systems and mature DevOps practices - Google demoted E2E tests due to their brittleness and slow execution but clarifies they still play a critical role for user workflows that can’t be covered by lower-level testing. - Recommends <5% E2E tests due to flakiness - “Every E2E test should answer: ‘Could this failure directly cost $1M+?”
Kent C. Dodds' Testing Trophy	- Static Analysis: Base - Unit Tests: Small - Integration Tests: Large - E2E Tests: Small top	- Emphasizes integration testing - Includes static analysis - Focuses on tests that resemble real usage - Introduces "confidence coefficient" concept	- Best Suited For: Organizations prioritizing user experience and frontend development - Argues for "Write tests. Not too many. Mostly integration." - Considers ROI and confidence provided by each test type
Martin Fowler's Approach	- Unit Tests: Majority - Integration Tests: Some - UI/E2E Tests: Few	- Advocates for a pyramid shape - Emphasizes fast, reliable unit tests - Introduces concept of "subcutaneous tests" - Focuses on self-testing code	- Best Suited For: Enterprises adopting Agile methodologies and focusing on code quality - Emphasizes refactoring as part of the TDD process - Advocates for continuous integration and automated testing - Actionable Insight: Use E2E to validate <10 critical user paths; automate regression checks.

“These viewpoints converge around one central theme i.e. balance it as per business. E2E testing shouldn’t replace lower-level tests but complement them by catching regression issues that unit or integration tests may miss.”

— Example: A bank prioritizes E2E tests for fund transfer flows over profile page tests.

Salesforce E2E Testing Landscape

Salesforce applications often involve custom objects, complex process flows, and integrations with external systems. E2E testing in Salesforce focuses on:

• UI validations for Lightning Experience and custom pages.

• Integration checks (e.g., verifying data sync with external ERPs).

• Workflow automation (like approval processes, triggers, or apex jobs).

• Security rules around profiles, permission sets, and object-level access

When Salesforce’s release cycles introduce DOM changes or new features, standard locators can break. Automated solutions must handle these shifting elements gracefully. Multi-layer dependencies (Lightning Web Components, third-party apps, etc.) amplify the need for robust E2E tests that account for each part of the system.

Why Is Salesforce E2E Testing Complex?

• Dynamic UIs with Lightning Web Components

• 60%+ of orgs use 5+ integrated apps (e.g., Marketo, CPQ)

• Frequent Salesforce updates (3x/year) break traditional selectors

UTAM: Salesforce’s E2E Game-Changer

UI Test Automation Model (UTAM) is an open-source solution by Salesforce for automating end-to-end UI tests on both Salesforce and non-Salesforce apps. It offers:

• JSON-Based Page Objects: Reduces fragility by abstracting away DOM details.

• Lightning Base Component Support: Updated page objects for standard Lightning components, minimizing breakage when Salesforce DOM changes across releases.

• Easy Maintenance: UTAM page objects decouple locators from test logic, letting teams reuse definitions for multiple test scenarios.

• Faster Authoring: Built-in approach for navigating Shadow DOM boundaries in Lightning Web Components, simplifying test creation.

For architects and teams dealing with frequent UI shifts, UTAM shrinks the gap between stable test design and Salesforce’s fast-paced release schedule. It arms you with maintained page objects from internal Salesforce engineering, letting you focus on testing critical business processes rather than chasing broken locators.

The UI Test Automation Model (UTAM) addresses critical pain points:

• Pre-Built Components: 450+ reusable page objects for standard Salesforce elements.

• DOM Decoupling: JSON-based definitions survive UI updates (fewer test breaks).

UTAM's Role in the Test Pyramid

In the context of the Test Pyramid model, UTAM primarily operates at the top layer, which is dedicated to E2E testing. However, its approach brings several advantages that influence the entire testing strategy:

1. Efficient E2E Layer: UTAM makes the typically slow and brittle E2E tests more robust and manageable. This efficiency allows teams to potentially increase their E2E test coverage without the usual drawbacks.

2. Bridging Integration and E2E: The reusable components and page objects in UTAM can sometimes blur the line between integration tests (middle layer) and E2E tests, potentially allowing for more comprehensive testing at a lower cost.

3. Complementing Lower Layers: While UTAM focuses on E2E testing, its efficiency can free up resources, allowing teams to maintain a solid foundation of unit and integration tests as recommended by the Test Pyramid model.

Key Steps to Implement E2E Testing in Salesforce

1. Define Critical Workflows
   Focus on high-risk, business-critical processes like lead-to-opportunity, approval workflows, and third-party integrations.

2. Set Up Realistic Test Environments
   Use sandboxes or scratch orgs that mirror production environments. Ensure data and configurations are up-to-date to prevent false positives.

3. Leverage Automation Tools
   Use tools like Provar, ACCELQ, or Tricentis Tosca for Salesforce-specific testing. These tools simplify testing Lightning components and handle dynamic elements.

4. Incorporate UTAM for UI Testing
   Salesforce’s UI Test Automation Model (UTAM) abstracts DOM details with JSON-based page objects, reducing test fragility and enabling reusable definitions for dynamic UIs.

5. Integrate with CI/CD Pipelines
   Automate E2E test execution within your CI/CD pipeline to catch regressions early. Prioritize fast feedback loops to maintain efficiency.

6. Follow Best Practices

   • Automate repetitive, high-value scenarios first.

   • Collaborate with business users for realistic test coverage.

   • Regularly update test suites to reflect changes in Salesforce releases.

   • Balance E2E tests with unit and integration tests to optimize coverage.

Retail Case Study

A retail giant using Salesforce Commerce Cloud automated E2E tests for checkout flows. The tests uncovered a 15% cart abandonment rate caused by payment gateway timeouts—resolved before peak season, saving $2.3M in potential lost revenue. (Learn more on Leapwork)

The Practical Crux: Implementing E2E Without Bottlenecks

• Scope and Volume: E2E tests should be used sparingly due to their complexity, cost, and maintenance overhead. They are best for validating critical user flows or business processes that span the entire system, ensuring that the integration of all components works as expected from the user's perspective.

• Conduct Risk-Based Prioritization: Map tests to revenue impact; of course, High risk is a candidate for E2E Testing.

  • High Risk: Checkout, Contract Signing

  • Medium Risk: Search Filters

  • Low Risk: Profile Page UI

• Execution: Run E2E tests less frequently than unit or integration tests, possibly in a nightly build or before major releases, to manage build times while still ensuring system integrity.

• Automation Guardrails:

  • Tools: Selenium(web), Cypress or Playwright (Modern Web Apps), UTAM (Salesforce), Appium (mobile),

  • Avoid: Automating edge cases better handled by unit tests.

• Metrics That Matter:

  • Flakiness Rate: <5% (Google’s benchmark)

    • Flakiness Rate is a metric used to measure the reliability and consistency of automated tests. It represents the percentage of tests that produce inconsistent results when run multiple times under the same conditions.

  • Feedback Time: <30 mins for critical path tests

FAQs

• Q: Why is E2E testing important in Salesforce?

  E2E testing ensures that user workflows—spanning custom components, integrations, and automation—function correctly after updates or releases.

• Q: How does UTAM improve Salesforce E2E testing?

  UTAM simplifies UI automation by providing reusable JSON-based page objects that adapt to changes in Lightning components, reducing maintenance overhead.

• Q: What are the challenges of E2E testing in Salesforce?

  Challenges include handling dynamic UIs (e.g., Lightning Web Components), managing frequent updates from Salesforce releases, and maintaining realistic test environments.

• Q: Can I automate all E2E tests in Salesforce?

  Not all scenarios are suitable for automation. Focus on automating repetitive, high-impact workflows while leaving exploratory or edge cases for manual testing.

• Q. How is E2E testing different from unit testing?New Item

  Unit tests focus on verifying isolated pieces of code, like individual classes or methods, and offer quick feedback. E2E tests validate entire user workflows in a test environment, often involving the UI in a sandbox or scratch org, which are slower but provide a more realistic preview of system performance and integrations.

• Q. How does UTAM help reduce flakiness in test scripts?

  UTAM decouples test logic from locators by generating page objects that handle underlying DOM details. This makes tests more resilient to Salesforce updates, DOM changes, and new Lightning component releases.

• Q. When should a team prioritize E2E tests over other test types?

  Teams often reserve E2E tests for high-risk, business-critical functionality—like financial transactions or key data flows—where failures cause significant impact3. Lower-level tests catch isolated bugs quickly, but E2E tests verify that Salesforce processes and third-party APIs collectively work as intended.

• Q. How can QA teams manage frequent Salesforce releases while maintaining E2E scripts?

  They should regularly update their test suites to accommodate new Lightning components, API changes, and UI enhancements. Automations that rely on stable page objects (as offered by UTAM) and continuous integration systems reduce manual effort in adapting to each release cycle.

• Q. Are there best practices for setting up E2E test data in a Salesforce sandbox?

  Yes. Use sandbox seeding scripts or test data factories to produce realistic data sets that mirror production. This approach uncovers data-related defects and ensures consistent test coverage for workflows like lead qualification, case management, or quoting.

• Q. What can be done to speed up E2E test execution in Salesforce CI/CD pipelines?

  Parallelize test runs where possible, focus on critical business journeys, and refine test data to reduce overhead. Some teams use a multi-layer approach, limiting E2E coverage to essential checks while relying on faster unit and integration tests for detailed validation.

• Q. How many E2E tests are enough in a Salesforce environment?

  There is no hard upper limit, but experts recommend a risk-based approach: start with vital workflows, then expand as needed. Too many E2E tests can slow feedback cycles, so prioritize coverage for processes that most significantly affect users or revenue.

• Q. Does E2E testing replace manual exploratory testing in Salesforce?

  No. Manual exploratory testing identifies unexpected issues and user-experience problems that automated scripts may not catch. Automated E2E tests complement manual checks by continuously verifying known paths, while exploratory efforts discover unusual corner cases.

• Q. How does E2E testing impact user acceptance testing (UAT)?

  Successful E2E tests assure that critical workflows function as intended before handing off to user acceptance testing. UAT can then focus on user-specific validations, usability aspects, and further edge cases, accelerating overall approval processes.

References

1. Salesforce UTAM Explained
   Learn how UTAM simplifies UI testing for Salesforce with JSON-based page objects and seamless DOM handling.

2. The Practical Test Pyramid by Martin Fowler
   Deep dive into the Test Pyramid concept and its practical applications in modern software testing.

3. Guide to Getting Started with UTAM
   Official UTAM documentation, tutorials, and examples for implementing E2E tests in Salesforce.

4. Run End-to-End Tests with UTAM (Salesforce Developer Blog)
   Insights on leveraging UTAM for reliable and maintainable E2E testing.

5. Long Live the Test Pyramid - Smashing Magazine
   Explore the evolution of the Test Pyramid and its relevance in modern testing strategies.

6. UTAM JavaScript Recipes on GitHub
   Examples of using UTAM for Salesforce UI testing, including setup and integration with WebdriverIO.

7. Why Google Demoted E2E Testing
   Insights into Google’s approach to E2E testing and its role in a balanced test strategy.

8. Static vs Unit vs Integration vs E2E Tests - Kent C. Dodds
   Explains the trade-offs of different test types and how they contribute to confidence in software quality.

9. Pyramid or Crab? Find a Testing Strategy That Fits - web.dev
   Discusses variations of the Test Pyramid and how to adapt testing strategies for specific projects.