Automated UI testing is essential for building on Salesforce. Three major releases a year, plus customizations in your own org, can make it hard to keep up if you’re relying on manual testing only.
Changes to your Salesforce org should be tested, because even small updates can have unexpected effects. Automated UI testing helps you catch any issues early, before users or revenue are impacted.
This guide shares practical strategies for building UI tests that flag issues caused by org customizations or new Salesforce releases. Whether you’re starting from scratch or dealing with a brittle test suite, you’ll find clear steps to create stable tests that protect your most important Salesforce processes and features.
What is Salesforce UI testing and why do you need it?
UI testing answers a critical question: when users interact with your Salesforce application, does it behave the way they expect?
Your Salesforce org is built around your business. The Flows, custom fields, page layouts, and validation rules you’ve set up all work together to create something tailored to you. No two orgs are the same. Every time you make a change, even a seemingly small one, there’s a risk of unintended consequences.
Most regression issues arise from changes in the UI. Salesforce evolves three times a year with major releases. These updates often introduce subtle changes in how components render, how Document Object Model (DOM) elements are structured, or how new features interact with existing customizations. UI testing is the most reliable way to catch these regressions where they’re most likely to appear and confirm that your business-critical processes still work the way users expect.
Failures and regressions stall your entire business. Sales reps can’t quote. Agents can’t fix issues. Users can’t get work done. UI testing validates that your critical business processes — converting leads, creating cases, generating quotes — continue working correctly after you make changes.
London, UK
Agentforce World Tour London
How is UI testing different from static code analysis and unit tests?
Other testing methods focus on the internal workings of your org. Static analysis checks code quality, security, and performance. It tells you if an Apex class is inefficient, or if a Flow has poor error handling. Unit tests confirm that individual pieces of code or logic run correctly in isolation. They’re essential for developers, but don’t cover how those pieces work together in the UI.
UI testing, by contrast, works at the user level. It simulates someone logging in, clicking buttons, filling out forms, and running Flows to verify that the whole process functions in practice. That’s why UI testing is indispensable in Salesforce: it validates not just the technical health of your org, but the real-world workflows your business depends on.
Manual vs. automated UI testing
You can approach Salesforce UI testing in two ways: manually clicking through your org before each release, or automating tests that run on demand. Each has its place, but understanding the trade-offs helps you build a testing strategy that scales with your org.
Manual testing in Salesforce environments
Most Salesforce teams start with manual testing. Before releasing changes, someone (often an admin) clicks through the application, creating test records, filling out forms, checking that buttons work, and verifying that everything looks right.
This usually happens in sandboxes — development, partial, or full copy — where changes can be tested safely before they reach production. Larger teams often add a staging or UAT org, where business users confirm that end-to-end processes still work. And once changes are deployed, a limited smoke test in production is common: running through a few critical paths with test data to make sure nothing broke.
But this process can quickly become overwhelming. Testing one workflow across multiple profiles, browsers, and record types takes hours, with the same steps repeated again and again. The repetition makes mistakes inevitable: after the tenth run of a lead conversion, subtle changes like a new validation message or shifted field are easy to miss.
As your org grows, manual testing becomes impossible to scale. More objects mean more screens to check, automations create hidden dependencies, and integrations add failure points you may not even know exist. You’re left either spending days on exhaustive tests or releasing without full confidence.
This bottleneck slows delivery. Manual testing still has value for user-centric checks — like whether a layout feels intuitive or error messages make sense — but consistency and speed require automation.
Automated UI testing in Salesforce environments
Automated UI testing transforms your quality assurance from a bottleneck into an accelerator. Tests running automatically in your CI/CD pipeline are carried out on every commit, eliminating the human errors that creep in during repetitive manual testing. And it’s scalable — automated tests can run across multiple browsers simultaneously, validate multiple user profiles in parallel, and execute your entire test suite in minutes, not days.
What to test: core UI testing checkpoints
Your testing time is limited, so focus it where failures hurt most. These checkpoints cover the critical areas that protect your users and keep your business running smoothly after every change.
General UI and UX validation
Automated tests can confirm that pages load cleanly, fields render in the right place, labels stay legible, and core interactions (buttons, links, dropdowns, tabs) behave as expected. Include coverage across multiple browsers and devices so you don’t miss failures in the environments your users actually rely on. Reports and dashboards are especially critical — automation should verify that data and charts display accurately and that filters work properly.
Configuration and business logic
Salesforce runs on custom configurations. Automated tests should validate field behaviors (required fields, formulas, picklists, number formatting), plus the rules that control data entry. Validation rules need to both enforce quality and deliver helpful error messages. Don’t skip the edge cases — boundary values, unexpected formats, and rare combinations often reveal hidden issues. And if you’ve got multiple rules in play, check that they work together cleanly without clashing or blocking each other unexpectedly.
Page layouts need to flex based on who’s using them. Sales reps should see opportunity fields that service agents don’t. Record type layouts, related lists, and action buttons should also adapt to each profile.
For Lightning Web Components and Flows, automated checks should confirm that components render without errors, guide users through steps as designed, and fail gracefully when something goes wrong. As not all runtime errors surface in the UI, pairing automated checks with observability tools ensures you capture hidden Flow faults or JavaScript exceptions that don’t display on-screen. Together, this gives you both surface-level confidence and deeper assurance that your automations are resilient.
Security, accessibility, and performance
UI testing should also extend beyond functionality to cover the foundations of a trustworthy org: security, accessibility, and performance. On the security side, tests need to verify that sharing rules, field-level security, and permission sets work as intended so sensitive data stays tightly controlled. Accessibility checks confirm that the platform is usable for everyone — keyboard navigation should be reliable, screen readers must parse the interface correctly, and visual elements should meet Web Content Accessibility Guidelines (WCAG) standards for contrast and clarity. Performance testing ensures the experience remains fast and reliable: complex page layouts should load quickly, dashboards must refresh smoothly even with heavy datasets, searches should return accurate results without delay, and bulk actions need to complete without stalling or timing out.
Layers of UI testing in Salesforce
The strongest UI test suites layer different types of checks to cover both critical paths and broader scenarios:
- Smoke tests: Small, fast checks for essential workflows like lead conversion, case creation, or quote generation.
- Regression tests: Broader suites that confirm existing functionality still works after new changes or Salesforce releases.
- Cross-browser tests: Ensure layouts and interactions behave consistently across Chrome, Firefox, Edge, Safari, and mobile browsers.
- Cross-profile tests: Validate that different Salesforce profiles or permission sets see the right layouts, fields, and actions.
The role of UI testing in end-to-end (E2E) testing
As Salesforce is highly declarative, lots of the platform’s behavior isn’t written in Apex code you can unit test — it’s built with point-and-click configuration: Flows, validation rules, approval processes, page layouts, and permission models. These only fully come together in the user interface. A Flow might look correct in isolation, but its actual impact is only clear when a user triggers it by filling out a form or clicking a button. This means UI testing is key for end-to-end (E2E) testing in Salesforce.
An end-to-end test in Salesforce usually means simulating a real workflow, like “convert a lead, create an opportunity, generate a quote.” This runs through multiple parts of the platform: UI forms, record-triggered automations, integrations, and backend Apex. The only way to validate that all those layers work together is to follow the same path a user would — through the UI. Where unit tests validate a single Apex class in isolation, and integration tests check that components work together, E2E UI tests verify entire business processes from start to finish.
Build UI testing into your DevOps lifecycle with Gearset
In a mature DevOps lifecycle, UI testing isn’t something added at the end — it’s built into the process. A complete DevOps solution embeds UI testing directly into your lifecycle so every deployment is automatically validated against the workflows users rely on most. With UI testing woven into the lifecycle, teams deliver faster and with less risk.
Embedding testing into automated release pipelines
Gearset’s CI/CD Pipelines transform testing from a manual checkpoint into an automated quality gate with embedded UI testing for every change deployed between environments.
Gearset connects directly with leading Salesforce testing platforms like ACCELQ, Keysight Eggplant, TestSigma, and Provar to trigger automated UI tests after a successful org deployment. Once configured, they’ll then run continuously, giving you confidence that every promotion has already met your quality standards. The pipeline visualization keeps everything crystal clear, showing which environments hold which versions, the test status at each stage, and exactly where issues are blocking.
Gearset also supports triggering UI tests through outgoing webhooks. You can call Tricentis Testim’s public REST API at the end of a CI or deployment run to automate test execution. For Provar, you can use webhooks to trigger a custom Jenkins CI server job at the end of a CI run.
Testing becomes inseparable from deployment. You can’t accidentally push untested changes to production because the pipeline enforces quality gates automatically.
Flexible webhooks
For teams using other tools, Gearset’s webhook system will trigger automatically on deployment success or failure, so your pipeline can react in real time. Gearset integrates with Selenium via webhook or GitHub Actions, triggering tests immediately after CI jobs complete. It also supports invoking Provar tests via a webhook that triggers a custom Jenkins job. And teams using Tricentis Testim can fire remote test runs from Gearset by configuring a webhook to their Testim REST API.
Your webhook payloads include all necessary context — which org, what changed, deployment status — allowing receiving systems to trigger appropriate test suites. Configure return webhooks to pull results back into Gearset, creating unified visibility across your entire toolchain.
Cross-functional collaboration
Gearset lets everyone see the same pipeline status, UI test results, and deployment progress. When tests fail, Slack alerts notify the team channel, Jira tickets update automatically, Microsoft Teams posts include failure details, and email notifications reach stakeholders. This immediate feedback allows devs to respond quickly. Admins understand exactly what’s being tested and why. Business users see quality gates protecting their critical processes.
Quality shifts from being QA’s responsibility alone to something the entire team owns. When testing is embedded in everyone’s daily workflow — not isolated in a separate phase — quality improves naturally. Your team catches issues early, fixes them quickly, and delivers confidently.
Ready to streamline your Salesforce UI testing?
Automated UI testing is essential if you want to ship Salesforce apps at the speed today’s teams expect. The real value kicks in when testing isn’t a separate chore but part of your DevOps pipeline. And because manual testing time drops dramatically, your team can stay focused on what matters most: building new features and improving the user experience.
See firsthand how quality gates protect your production org while accelerating delivery. Start a free 30-day trial to experience how integrated CI/CD pipelines with automated testing can transform your release process.
Book a personalized demo to discuss your team’s specific challenges. Our Salesforce DevOps experts will show you exactly how Gearset addresses your testing needs, from simple smoke tests to complex E2E validation across multiple environments.
