Salesforce ships three major releases a year: Spring, Summer, Winter. You can't delay them and you can't skip them. Each one can quietly break custom Apex code, a validation rule, a Lightning web component, or an integration that worked fine the week before.
Orgs without a structured testing process find these breaks in production, after users hit them. Orgs with one catch them in a sandbox, before anyone notices.
Salesforce application testing is also harder than testing a standard web application. Lightning components render inside a shadow DOM that blocks the CSS selectors most automation tools rely on. Element IDs are generated dynamically, so a locator that works in one sandbox fails in the next. Multi-factor authentication now guards every production org, which breaks logins for automation scripts that were never built to handle it. And testing Salesforce applications means testing configuration, not just code: a single change to a validation rule or a permission set can break a workflow that no Apex unit test ever touches.
This guide covers every type of Salesforce testing, what each one catches and what it misses, the tools worth considering and when each makes sense, the step-by-step testing process for a release cycle, and the best practices we've drawn from embedding QA specialists directly into Salesforce delivery teams.
Key Takeaways
- Salesforce requires at least 75% Apex code coverage to deploy, but coverage counts lines executed, not correctness. A test with no assertions can hit 100% coverage and still let a real bug through.
- Nine distinct testing types cover a Salesforce org: unit, integration, functional, system, regression, UAT, performance, security, and Agentforce/AI agent testing. Each one has a specific gap another type has to fill.
- Shadow DOM, dynamic element IDs, and enforced MFA are the three reasons general-purpose automation tools (plain Selenium, Cypress without configuration) struggle with Salesforce Lightning.
- No single testing tool fits every team. The right pick depends on whether your testers can write automation code, whether testing needs to live inside a DevOps pipeline, and how deep your Salesforce-specific needs go.
- Don't automate everything. Automation pays off on repetitive, stable tests. UAT, exploratory testing, and scenarios that need human judgment are usually faster and cheaper done manually.
Why Is Salesforce Testing Different from Standard Software Testing?
Salesforce testing is different because four things about the platform actively work against standard test automation and standard QA scope. Here's what makes it harder, and why the usual tools and habits need adjusting.
Shadow DOM Blocks Standard Selectors
Lightning web components render inside a shadow DOM, a browser feature that encapsulates a component's internal markup. Standard CSS selectors, the kind most web application testing tools use out of the box, can't see past that boundary. This is why plain Selenium or unconfigured Cypress fails on Salesforce Lightning, and why Salesforce-specific tools (Provar, Tricentis) or Salesforce's own UTAM framework exist in the first place.
That boundary comes in two different flavors, and the distinction matters more for testing than most guides mention. Lightning Experience and Experience Cloud default to a synthetic shadow DOM: a polyfill Salesforce built because not every browser supported the native Shadow DOM spec when Lightning Web Components launched. Since Spring '24, components can opt into native shadow DOM instead, one component at a time, by setting shadowSupportMode to 'native' on the component. Once a component runs in native mode, every child component nested inside it is forced into native mode too, whether or not it asked for it.
The two modes don't behave the same way under automation. XPath selectors ignore synthetic shadow DOM but respect native shadow DOM, so a locator strategy that worked fine before a component migrated can quietly stop finding elements after. Salesforce's own guidance is to avoid raw XPath and test through UTAM or kagekiri instead, and to re-run both Jest and real-browser tests against any component moved to native mode, since layout and styling issues in native shadow DOM don't reliably surface in a headless Jest run.
Dynamic Element IDs Break Static Locators
Salesforce generates element IDs dynamically. The same field carries a different ID in your development sandbox than it does in production, so any locator built on a static ID breaks the moment you move environments. Salesforce-specific tools solve this by binding tests to metadata, field API names and object names, instead of DOM locators.
Configuration Is Part of the Testing Surface
Standard software testing focuses on code. Salesforce testing has to cover metadata too: validation rules, permission sets, profiles, sharing rules, page layouts, flows. A configuration change that clears code review can still break a business process no Apex unit test was written to catch. That's a meaningfully wider scope than most general software QA has to plan for.
Three Mandatory Releases a Year
Spring, Summer, Winter: the release schedule is fixed, and every release can change LWC rendering behavior, deprecate an API, tighten a security policy, or alter how a flow executes. Automated test suites need re-validating against each one. This ongoing maintenance, not the initial build, is the real cost driver behind Salesforce test automation.
What Are the Types of Salesforce Testing, and What Does Each One Miss?
Salesforce testing breaks down into nine distinct types, and the reason a generic testing checklist falls short is that each type covers a specific layer and misses everything outside it. Knowing what a testing type doesn't catch is what tells you why you need more than one.
Three of these deserve a closer look, because they're where most competitor guides stop short.
Apex Coverage Is a Floor, Not a Quality Signal
Salesforce requires at least 75% of Apex code to be covered by tests before you can deploy to production or distribute through AppExchange, and every trigger needs at least some coverage on its own. That's a platform requirement, not a recommendation. But coverage counts lines of code a test executes. It says nothing about whether the test asserts the right outcome. An Apex test that calls a method and checks nothing can hit 100% coverage and never catch a single bug.
Apex tests also run in an isolated context. Records created during a test roll back once the test finishes, so they don't touch live org data, and @IsTest(SeeAllData=true) should be reserved for the rare case where you genuinely need it. Every trigger and handler should also get tested against at least 200 records in a single run, since bulk data handling is the most common source of governor limit failures once code reaches production.
LWC Testing Has Two Separate Layers
Jest handles unit testing for lightning web components: rendering, interaction events, wire adapters, and mocked Apex responses, all inside Node.js rather than a live org. For end-to-end browser testing, Salesforce built UTAM (UI Test Automation Model) to sit on top of Selenium or WebdriverIO specifically because it can read through the shadow DOM that blocks everything else. Salesforce also shipped beta LWC testing tools through the DX MCP toolset, which generate Jest test suites, flag coverage gaps, and suggest missing test cases and mocking improvements.
Agentforce Testing Needs Structured Test Cases and Output-Based Scoring, Not Exact-Match Assertions
Testing an Agentforce agent doesn't work like testing a deterministic Apex method, because the same correct answer can come back worded three different ways. Salesforce's own testing guidance points to three practices worth building into any Agentforce test plan, instead of trying to force exact-match assertions onto a system that isn't deterministic.
Structure test cases around utterance, expected subagent, expected actions, and expected response, not a single expected output string. Agentforce Testing Center runs test cases from a CSV with those four columns, and only the utterance plus one other column is required. That structure forces you to define what "correct" means at each step of the agent's reasoning, from which subagent picks up the request to which action it fires, not just its final reply.
Test negative and adversarial inputs as deliberately as positive ones. Salesforce's own guidance for setting up Agentforce test criteria calls for testing "positive, expected results" alongside "negative, unexpected, or even invalid results," and frames boundary testing as a risk exercise: predicting how a request might be phrased by someone trying to push the agent outside its intended scope, not just how a typical user would ask.
Score responses with output-based scorers instead of string matching. Agentforce Testing Center evaluates responses with default and custom scorers rather than checking for an exact match, and can auto-generate test cases directly from an agent's subagents, actions, and knowledge sources, which is also the fastest way to catch a knowledge source returning ungrounded or outdated information before a user does.
None of this replaces standard QA discipline. It replaces one assumption: that an assertion written for deterministic code will also work for a system that's allowed to phrase the same correct answer three different ways.
Which Salesforce Testing Tools Fit Your Team?
No single tool is right for every Salesforce team, and treating one as universally "best" ignores what actually drives the decision. Three factors matter: whether your testers can write automation code or need a codeless option, whether testing has to live inside a DevOps pipeline, and how deep your Salesforce-specific requirements go.
As a starting point: technical QA team wanting deep Salesforce-native coverage, look at Provar. Testing that has to live inside a Copado DevOps workflow, use Copado Robotic Testing. Codeless authoring at enterprise scale, Tricentis. Testing folded into deployments without a dedicated tool, Gearset. Developer-led team comfortable investing in open source, Playwright or Selenium plus UTAM. Constrained budget and a non-technical team, ACCELQ or Testsigma.
Read also: Salesforce Test Automation: The Ultimate Guide for a deeper walkthrough of building and maintaining an automation stack.
What Does the Salesforce Testing Process Look Like for a Release Cycle?
A real testing process for a Salesforce deployment or release cycle runs in six steps, from scoping the change to a verified go-live. Here's what it looks like in practice, not in theory.
Step 1: Define the Testing Scope Before Touching the Org
Before any code or configuration change, list every Apex class, flow, validation rule, integration, and permission set the change touches. That list is your regression risk. Skip this step and you'll run tests against things that didn't change while missing the things that did.
Step 2: Write Apex and Jest Tests as Part of Development, Not After
Writing tests after the code is done optimizes for coverage percentage, not for catching bugs, which is exactly the trap the 75% requirement invites. Apex tests should cover positive paths, negative paths, and bulk scenarios (200 records in one run). Jest tests should cover every render state, interaction event, and Apex mock before a component moves from scratch org to sandbox.
Step 3: Run Apex Tests and Static Analysis in a Developer Sandbox
Run the full Apex suite against the changed code in an isolated developer sandbox, and target 85%+ meaningful coverage rather than 75% with empty assertions. Pair it with a static analysis scan, Salesforce Code Analyzer or PMD, to catch hardcoded IDs, missing error handling, and insecure SOQL before promotion. As of Spring '26, RunRelevantTests (beta) can limit a run to just the tests tied to the specific change, which matters once a large org's full suite takes real time to run.
Step 4: Run Functional and Integration Tests in a Staging Sandbox
Promote to a staging sandbox that mirrors production data volume and configuration, then run functional scripts across every affected process. Test integration points in both directions, confirm error handling works, and check that no authentication tokens have expired. Test with multiple user profiles, not just an admin account, and since February 2026, confirm every outbound message uses OAuth rather than a session ID.
Step 5: Run the Full Regression Suite
Run automated Apex tests, scripted functional scenarios, and integration spot-checks together. Start with a fast smoke test, a subset of critical-path scenarios, and stop to fix if it fails before running the full suite. Before each seasonal release, run the regression suite against Salesforce's pre-release sandbox, which is typically available four to six weeks before the production rollout.
Step 6: Run UAT with Business Stakeholders, Then Deploy
Bring in business stakeholders to test real workflows using scripted scenarios with defined pass/fail criteria, not open-ended clicking around. Capture sign-off in writing before deployment. Once you're live, run a smoke test directly in production to confirm the deployment landed before telling users to expect anything different.
What Are Salesforce Testing Best Practices for 2026?
These six practices come from what experienced Salesforce QA teams do differently, and each one names the common mistake alongside the fix.
Treat 75% Apex Coverage as a Deployment Floor, Not a Quality Target
75% is what Salesforce requires to deploy, not a measure of how well-tested your code actually is. A test that calls a method with no System.assertEquals() statements can count toward coverage and never catch a real bug. Set an internal bar of 85%+ with mandatory assertions, positive and negative paths, and at least one bulk test per trigger. Coverage is a compliance metric. Assertion quality is what actually prevents production bugs.
Use Test Data Factories Instead of Inline Setup
Test data written inline in every test class gets duplicated and fragile fast. A dedicated test data factory class makes data consistent, reusable, and easy to update when the object model changes, and it heads off the most common cause of test fragility: a required field changes and inline setup somewhere doesn't account for it.
Test with Realistic User Profiles, Not the Admin Account
An admin account bypasses sharing rules, FLS restrictions, and profile-based UI limits. Testing only as admin misses the issues real users actually hit: fields visible to an admin but hidden from a standard user, records reachable in admin context but excluded by a sharing rule elsewhere. Write test scripts that run as the profiles your team has actually configured.
Build and Maintain a Pre-Release Regression Sandbox
Salesforce makes a pre-release sandbox available four to six weeks before each seasonal release. Running your regression suite there before the release reaches production is the only way to catch a breaking change before your users do. Teams without this sandbox find out what broke on release day. Teams with it fix it before release day arrives.
Name a Single Owner for the Regression Suite
Most production bugs surface at the boundary between configuration and code: a flow change that breaks an Apex trigger, or a validation rule catching data an automated test never sends. Split ownership ("developers own Apex tests, admins own flow tests") leaves that boundary unowned. Name one person or role responsible for knowing what the suite covers, what it misses, and for running it before every production deployment.
Don't Automate Everything, Automate What's Stable and Repetitive
Automation pays off when a test runs often and the feature underneath it barely changes. Automating a UAT scenario that changes every sprint costs more to maintain than it saves. Put automation effort into regression testing, integration smoke tests, and Apex unit testing, which is required anyway. Manual and exploratory testing stay the right call for UAT and for scenarios requiring human judgment, features that change frequently, and edge cases a script wasn't written to expect.
Who Owns Testing in a Salesforce Team, and What Happens When Nobody Does?
In a well-structured Salesforce delivery team, testing splits three ways: developers own Apex unit tests and LWC Jest tests, admins validate configuration changes like flows and validation rules, and QA owns functional, regression, integration, and UAT coordination across the whole solution.
The gap between developer testing and admin testing is where most production bugs start. A developer testing an Apex trigger against a clean sandbox won't see how it behaves against the sharing rules an admin configured the week before. A QA role that owns the regression suite across both layers is what catches that boundary.
On small teams without a dedicated QA role, an admin or tech lead often absorbs testing informally, and that works until the org's complexity outgrows what one person can hold in their head alongside everything else. That's usually the point where untested changes start piling up in the backlog. A project-based QA engagement, a specialist embedded for the length of a build or release cycle, is often cheaper than finding out about the bugs after go-live.
A US education technology company running an ongoing Salesforce delivery team embedded a dedicated QA specialist and saw defects drop and release quality improve across sprint cycles, with the QA role owning the regression suite and coordinating UAT sign-off before every production deployment. A healthcare ISV with an accumulating backlog of test coverage gaps brought in QA capability to strengthen documentation, test case coverage, and code quality across an existing managed package.
MagicFuse embeds certified QA specialists directly into Salesforce delivery teams, not as a separate QA service bolted on afterward, but as part of the project team alongside developers and architects. Our team holds ISTQB certifications alongside Copado Robotic Testing and Copado Salesforce DevOps certifications, part of the 270+ Salesforce certifications held across the MagicFuse team.
If testing gaps trace back to how the org was built rather than how it's tested, the partner doing the building matters just as much as the QA layer on top of it.
Read also: How to Choose a Salesforce Implementation Partner: 2026 Comparison Guide
Read also: TOP 10 Salesforce Consulting Companies for 2026
Read also: Top 20 Salesforce Development Companies
FAQs
- What is the minimum Apex code coverage required for Salesforce deployment?
Salesforce requires at least 75% of Apex code covered by tests before deployment to a production org or distribution through AppExchange, and every trigger needs at least some coverage. It's a platform requirement, not a suggestion, and missing it blocks deployment outright. Treat 75% as a floor: aim for 85%+ with meaningful assertions, positive and negative paths, and bulk test scenarios.
- What is the difference between Apex code coverage and test quality?
Code coverage counts lines of Apex a test executes. It doesn't check whether the test asserts the right outcome. A test that calls a method with no assertions counts toward coverage and catches nothing, so an org can sit at 100% coverage with every test passing and still ship code that's wrong in production. Coverage is a deployment gate. Test quality is what actually prevents failures.
- How do you test Lightning Web Components?
Two layers. Jest tests, run in Node.js through the @salesforce/jest-config package, cover component rendering, user interactions, wire adapter behavior, and mocked Apex responses in isolation. End-to-end browser testing uses UTAM on top of Selenium or WebdriverIO, since UTAM is built to handle the shadow DOM that blocks standard CSS selectors. Salesforce added AI-assisted LWC testing tools (beta) through the DX MCP toolset, which can generate Jest suites and flag missing test cases and mocking gaps.
- What is Salesforce regression testing, and how often should it run?
Regression testing re-runs previously passing tests after a change, whether that's a code deployment, a configuration update, or a seasonal release, to confirm nothing that worked before is now broken. It should run before every production deployment at minimum, and against the pre-release sandbox ahead of each of Salesforce's three annual releases. Teams with a continuous integration and deployment (CI/CD) pipeline (Copado, Gearset) can automate regression runs on every sandbox promotion.
- What is the hardest part of automating Salesforce testing?
Three specific problems: shadow DOM, which exists in both a synthetic (default, polyfilled) and native (opt-in since Spring '24) form and blocks standard CSS or XPath selectors differently depending on which mode a component runs in; dynamic element IDs, which break static locators between sandboxes; and MFA, now enforced on every production org, which has to be handled or worked around for automated test users to log in at all. This is why general-purpose tools like plain Selenium or unconfigured Cypress are unreliable on Salesforce Lightning.
- What testing tools are best for Salesforce?
It depends on team composition and budget, not a single "best" answer. Technical QA teams do well with Provar. Teams on Copado DevOps get more value from Copado Robotic Testing. Enterprise orgs needing codeless, multi-system coverage lean toward Tricentis. Teams embedding testing into deployments fit well with Gearset. Developer-led teams comfortable with open source can build on Playwright or Selenium with UTAM. Teams new to automation without dedicated engineers do better starting with ACCELQ or Testsigma. The native Apex Testing Framework and Jest are free and non-negotiable regardless of what else you add.
- How do you test Agentforce AI agents in Salesforce?
Agentforce agent testing is a discipline of its own, and Salesforce structures it around three practices. Agentforce Testing Center runs test cases built from an utterance plus expected subagent, expected actions, and expected response, not a single expected output string. Test setup guidance calls for testing negative and adversarial inputs as deliberately as positive ones, treating boundary testing as a risk exercise rather than an afterthought. And responses are graded with output-based scorers instead of exact-match assertions, since the same correct answer can be worded several different ways. Standard exact-match assertions don't apply to AI output.
- Can you run Salesforce tests in production?
Apex unit tests can run in production because they execute in an isolated context and every record they create rolls back afterward, so they never touch live data. Functional testing, integration testing, UAT, and performance testing shouldn't run in production, since they create real records, fire real integrations, and affect real users. Keep all non-unit testing in a sandbox environment ahead of deployment.
Where This Leaves You
Salesforce's release cadence doesn't slow down for anyone, which means testing can't be a one-time step before go-live. It has to be a process that runs every four months, whether or not you're the one deciding to change anything.
None of the nine testing types replaces another, no single tool is right for every team, and 75% coverage was never meant to be the finish line. What actually holds up over multiple release cycles is a named owner for the regression suite, tests written alongside the code instead of after it, and a clear line between what gets automated and what still needs a person to look at it.
If your team is stretched thin on QA capacity going into the next release, MagicFuse's Salesforce development team can embed a certified QA specialist into your delivery process before the next Spring, Summer, or Winter release catches you off guard.
