What Is Salesforce Testing? Tips and How to Choose a Vendor

Salesforce is the rare platform where the vendor has opinions about your testing. Deploy Apex to production without enough test coverage and the deployment simply fails — the platform refuses. That single constraint tells you most of what makes Salesforce testing different: you are working inside someone else's system, on their schedule, under their rules, and a meaningful part of your test strategy is decided before you start.

This guide covers what Salesforce testing actually involves, why the interface resists automation, what the 75% coverage rule does and does not mean, how to pick sandboxes and handle data, how to survive seasonal releases, and how to evaluate a testing vendor if you bring one in.

Key takeaways

• Salesforce requires 75% Apex code coverage to deploy to production — a gate, not a quality measure.
• Most business logic is declarative, and declarative logic has no coverage requirement at all.
• Dynamic IDs, shadow DOM and iframes make UI automation harder than on a typical web app.
• Three seasonal releases a year make regression a scheduled, permanent commitment.
• Sandbox choice is a real strategy decision — data, refresh interval and purpose all differ.

What is Salesforce testing?

Salesforce testing is the validation of a Salesforce org after it has been configured, customised with code, integrated with other systems, or loaded with migrated data. It confirms that declarative automation behaves as designed, Apex does what it claims, users see exactly the records they should, integrations stay in sync, and none of it breaks when Salesforce ships its next release.

The distinctive part is the split between two kinds of logic living side by side. Declarative logic — Flows, validation rules, assignment rules, approval processes — is built by clicking, has no source file in the conventional sense, and carries no platform-imposed testing requirement. Programmatic logic — Apex classes and triggers, Lightning Web Components — is code, and Salesforce will not let you deploy it to production without tests.

That asymmetry produces a predictable failure pattern. Teams test the Apex because the platform forces them to, and under-test the declarative layer because nothing forces them to. The declarative layer is where most business logic in a mature org actually lives. A Flow that stops firing does not fail a deployment gate; it just quietly stops assigning leads.

Why is Salesforce hard to automate?

Salesforce is hard to automate because its interface is generated by the platform rather than authored by your team, so the stable hooks that browser automation relies on mostly do not exist. Five specific obstacles:

• Dynamic element IDs. Salesforce generates element identifiers at render time. They change between sessions and between releases, so any locator built on a recorded ID is temporary by construction.
• Lightning Web Components and shadow DOM. LWC encapsulates its markup inside shadow roots. Standard CSS and XPath selectors cannot pierce a shadow boundary — the tool needs explicit shadow DOM support, and traversal has to walk each boundary deliberately.
• Iframes. Visualforce pages surfaced inside Lightning Experience render in iframes, as do many embedded and AppExchange components. Automation must switch frame context correctly or it will fail to find elements that are plainly visible on screen.
• Visualforce and Lightning coexisting. Mature orgs run both. A single user journey can cross from a Lightning record page into a Visualforce page in an iframe and back, and each side needs a different locator approach.
• Three releases a year. Salesforce updates the platform on its schedule. A suite green in one season can break in the next without a single change on your side — a maintenance cost you inherit rather than choose.

Layer on layout variation by profile — the same record renders differently for a sales user and an admin — and brittle UI suites become expensive quickly. The strategic response is to push verification below the interface wherever possible, and to keep browser automation for journeys that are genuinely about the interface.

What should you test in Salesforce?

Test the seven areas where Salesforce configuration meets business outcome, weighted toward the declarative layer that the platform's own gates ignore.

Area	What to verify	How to test it
Apex code	Triggers, classes, bulk behaviour, governor limits, exception paths	Apex unit tests on the platform, with real assertions and bulk data
Declarative automation	Flows, validation rules, assignment and escalation rules, approval processes, execution order	Functional tests through API or UI — no platform coverage gate applies here
Profiles and permission sets	Object and field-level security, record sharing, role hierarchy, permission set assignments	Positive and negative tests per role; negatives matter most
Integrations	Inbound and outbound APIs, callouts, middleware, error handling, retries, sync conflicts	API-level integration tests against sandboxed downstream systems
Data migration	Record counts, field mapping, relationship preservation, duplicate handling, historical records	Reconciliation queries before and after load
Lightning UI	Record pages, layouts per profile, custom LWC, list views, mobile	Targeted UI automation for critical journeys only
CPQ (where used)	Pricing rules, discount schedules, product bundles, quote generation, approvals	Scenario-based functional testing; high business risk, complex rule interaction

Order of execution deserves specific mention. Salesforce applies validation rules, Flows, triggers and workflow actions in a defined order, and automations can trigger further automations. Two rules that are each correct alone can combine into a wrong outcome, or into a recursion that hits a governor limit. Test the interaction, not just the units — that is a scenario test, not a unit test, and Apex coverage will never reveal it.

What is the Salesforce 75% Apex code coverage rule?

Salesforce requires at least 75% Apex code coverage across your org before Apex can be deployed to production. It is a platform-enforced deployment gate: fall below it and the deployment fails. Because Salesforce is multi-tenant — your code runs on infrastructure shared with other customers — the rule functions as a platform-level safety mechanism, not as advice about your quality bar.

The critical distinction, and the one most orgs get wrong: coverage measures execution, not verification. A test that runs a class and asserts nothing produces coverage identical to a test that checks every outcome. It is entirely possible to pass the gate with tests that would not notice if the logic were inverted.

What makes Apex tests genuinely useful:

• Assert outcomes, not execution. If a test has no meaningful assertion, it is coverage theatre. Query the records afterwards and check the values are what the logic promised.
• Test in bulk. Governor limits are the defining constraint of the platform. Code that works on one record can blow a limit on 200. Test with realistic bulk volumes, because that is what a data load will do to it.
• Create your own test data. Tests should not rely on records already in the org. Use test data factories, and use @isTest(SeeAllData=false) — the default — so tests are isolated and deterministic.
• Use Test.startTest and Test.stopTest. They give the code under test a fresh set of governor limits and force asynchronous work to complete, so you are measuring the right thing.
• Test negative and bulk paths. Exception handling, validation failures and permission errors are where real defects live, and they are exactly the branches that never get covered by happy-path tests.

Treat 75% as the floor the platform imposes, not the target you aim for. And remember it applies only to Apex — your Flows, validation rules and permission model carry no coverage requirement whatsoever, which is precisely why they need deliberate functional testing.

Which Salesforce sandbox should you test in?

Pick the sandbox by what the testing stage needs from data, because that is the main axis on which Salesforce sandbox types differ. All copy configuration; they diverge on how much production data comes with it and how often you may refresh.

Sandbox type	Data included	Best used for
Developer	Configuration only, no production data	Individual development and Apex unit testing. Small, quick to refresh.
Developer Pro	Configuration only, larger storage than Developer	Development work needing more seeded test data; integration development.
Partial Copy	Configuration plus a defined sample of production data	QA, integration testing and UAT where realistic data matters but a full copy is unnecessary.
Full	Complete replica of production, including all data	Final regression, performance testing, load rehearsal and production-like UAT. Longest refresh interval.

Refresh intervals lengthen as sandboxes get larger — developer sandboxes can be refreshed very frequently, while a Full sandbox can only be refreshed roughly monthly. That constraint has a real strategic consequence: your most production-like environment is also your least frequently refreshed, so it drifts furthest from production between refreshes. Plan release testing around the refresh calendar rather than discovering it mid-release.

A workable pipeline runs development in Developer sandboxes, integration and QA in a Partial Copy, and final regression plus UAT in a Full sandbox before production. Scratch orgs, created from source and disposable, fit well for feature branches in teams working with a source-driven development model.

How do you handle Salesforce test data?

Build Salesforce test data from factories where you can, and mask it where you must copy from production. Partial Copy and Full sandboxes bring real customer records with them — names, contact details, contract values, sometimes far more sensitive fields — into environments that typically have broader access and looser controls than production.

The practices that matter:

• Mask irreversibly and consistently. The same account must map to the same masked identity across every object and every integrated system. Inconsistent masking breaks relationships and makes the sandbox useless for testing the very journeys you copied data to test.
• Suppress outbound communication. A refreshed sandbox retains real email addresses. Salesforce deactivates email delivery in new sandboxes by default — verify it is still off after every refresh, and before any data load. This is the control standing between you and emailing your customer base from a test org.
• Use test data factories for Apex. Unit tests should create their own records rather than depending on org data. Deterministic, isolated, and they keep working after a refresh wipes whatever you were relying on.
• Point integrations at sandboxed systems. A sandbox wired to a production ERP is a production integration with a reassuring name.
• Re-apply config after refresh. Refreshing overwrites the sandbox with production. Any in-flight configuration that was never promoted disappears. Keep it in version control rather than in a sandbox.

How do you test Salesforce seasonal releases?

Test Salesforce releases in a preview sandbox during the preview window, before your production org is upgraded. Salesforce ships three seasonal releases each year — Spring, Summer and Winter — and upgrades sandboxes ahead of production specifically so customers can test against the new version first. That window is the entire opportunity, and it is easy to miss if nobody owns it.

A repeatable release routine:

1. Read the release notes selectively. They are long. Filter for changes touching features you use, anything being retired, and anything enabled by default — the last category is where surprises come from, because it changes behaviour without you asking.
2. Confirm your preview sandbox. Salesforce publishes which instances get the preview and when. Make sure at least one sandbox representative of production is on it.
3. Run the regression suite there. This is what the suite is for. Prioritise integrations, custom LWC and anything relying on interface structure — the areas most exposed to platform change.
4. Check your automation suite separately. UI locators break on releases. Suite failures may indicate a test problem rather than a product problem; triage them apart or you will chase phantom defects.
5. Log issues while there is time. The preview window is finite. Finding a genuine regression on day one leaves room to raise it and plan; finding it after production upgrades leaves you reacting.

Three releases a year means release regression is not a project — it is a standing commitment on the calendar, three times annually, forever. Teams that treat it as an interruption are perpetually surprised. Teams that schedule it find it routine. This is the clearest case for automated regression testing anywhere in the CRM world: the cadence is fixed, the scope is repetitive, and the work recurs indefinitely.

What tools are used for Salesforce test automation?

Salesforce test automation tooling comes in three layers: the platform's own frameworks, general browser automation, and Salesforce-aware commercial tools. Most working setups use all three, at different levels.

Tool	Layer	Strengths and trade-offs
Apex test framework	Platform, unit	Built in, runs on the platform, required for deployment. Covers Apex only — no help with declarative logic or the interface.
Salesforce CLI and DX tooling	Platform, pipeline	Source-driven development, scratch orgs, automated deployments and test execution in CI. The backbone of a modern Salesforce pipeline.
Jest (for LWC)	Component unit	Salesforce provides a Jest-based framework for unit testing Lightning Web Components off-platform. Fast, and far cheaper than testing components through a browser.
Selenium / Playwright	UI automation	Free, flexible, large talent pool. You own the locator strategy — meaning you own the shadow DOM traversal, the iframe switching and the maintenance after each release.
Provar and similar Salesforce-aware tools	UI and API automation	Bind to Salesforce metadata rather than raw DOM, so tests survive layout changes and releases considerably better. Commercially licensed and Salesforce-focused by design.
Salesforce APIs (REST, Bulk, Metadata)	Integration and data	Dramatically more stable than UI automation for verifying data, automation outcomes and integrations. Cannot tell you what a user sees.

The choice that matters most is not which tool, but which layer. A team that verifies Flow outcomes by querying records through the API will have a faster, calmer suite than one that clicks through the interface to check the same thing. General test-pyramid discipline — described in our test automation guide — applies with extra force on a platform that actively punishes UI-heavy suites.

Salesforce testing tips that actually help

• Test the declarative layer hardest. It carries no coverage gate and holds most of your business logic. Coverage requirements have inverted many orgs' priorities — correct that deliberately.
• Assert, do not just execute. An Apex test without a meaningful assertion is a deployment formality, not a test.
• Always test in bulk. Governor limits are the platform's defining constraint, and single-record tests hide every limit problem you have.
• Automate through APIs before the UI. Same verification, a fraction of the fragility.
• Write negative permission tests. "This profile must not see this field" is the assertion that prevents a data exposure. Positive tests will not find it.
• Version-control your configuration. Config that exists only in an org is config that disappears on refresh and cannot be reviewed, diffed or rolled back.
• Put release regression on the calendar. Three times a year, booked in advance. Not a surprise.
• Test execution order. Individually correct automations combine into wrong outcomes and recursion. Only scenario tests catch this.
• Keep the UI suite small and stable. A handful of trusted critical journeys beats hundreds of flaky ones nobody believes.

If your programme spans several CRM platforms rather than Salesforce alone, the platform-agnostic principles are covered in our guide to CRM application testing, and the broader delivery context in Salesforce testing services.

How do you choose a Salesforce testing vendor?

Choose a Salesforce testing vendor on demonstrated platform depth and accountability for outcomes, not on rate card or headcount. Salesforce testing goes wrong in platform-specific ways, and a generic QA supplier will discover governor limits, sharing rules and the preview window on your project, at your expense.

Criteria worth applying:

• Platform depth, not CRM familiarity. Ask how they test Flows versus Apex, how they handle shadow DOM in LWC, and what their sandbox strategy is. Specific answers indicate real experience; general ones indicate a generic QA team with Salesforce in the proposal.
• Declarative testing approach. If their strategy is mostly "hit 75% coverage", they have misunderstood the platform. Ask directly how they cover Flows and permissions.
• Release-cycle capability. Ask how they handle seasonal releases and whether release regression is included or billed as an extra three times a year. The answer reveals whether they have actually run a Salesforce org over time.
• Automation maintenance model. Salesforce suites need upkeep every release. Ask who pays for it. A build-only engagement leaves you owning a decaying asset.
• Seniority of the actual team. Not the org chart in the proposal — who writes the tests. Salesforce testing rewards judgement about what to test, which juniors following a script do not have.
• Data handling and security posture. They will work with sandboxes containing customer PII. Ask about masking, access control and certifications. This is a data-protection decision as much as a quality one.
• Outcome accountability. Do they own a result you can measure, or do they bill for hours regardless? A partner willing to be measured on defect escape rate or release confidence has a different incentive from one selling capacity.
• A low-risk way to start. A short paid pilot on a real slice of your org tells you more than any reference call. Vendors confident in their work will offer one.

How Appsierra helps

Appsierra builds AI-native quality engineering pods for Salesforce orgs: Apex tests that assert rather than merely cover, functional testing of the declarative layer the coverage gate ignores, permission boundaries tested as explicit negatives, API-level integration checks, and release regression scheduled against the seasonal preview window rather than reacting after production upgrades.

We position as the accountable middle between giant systems integrators and cheap talent marketplaces: ISO 9001 and ISO 27001 certified, CMMI-aligned, senior-led vetted pods, de-risked by our own evaluation platform, and typically productive in about seven days. Engagements start with a risk-free paid pilot tied to a metric you choose — which is exactly the low-risk start we recommend you demand from any vendor, including us.

If your org has grown past what manual regression can carry, or a seasonal release has caught you out, our Salesforce consulting team works on the platform specifically, and our CRM testing practice covers the wider estate around it. Book a free 30-minute call and we will give you an honest read on where your org is most exposed.

Frequently asked questions