Blog
Salesforce Testing: Types, Process and Tools
Rishabh Kumar
Published on
Table of contents
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Salesforce is never finished. Salesforce ships three major releases a year. Your admins and developers add fields, flows, Apex and Lightning components every sprint. And the systems around it, like your ERP, marketing platform and data warehouse, keep changing too.
The more you customise Salesforce to fit your business, the more there is to test, and the easier it is for something to break without anyone noticing. Salesforce testing is how you make sure your sales, service and finance teams can keep relying on it.
What Is Salesforce Testing?
Salesforce testing checks that your Salesforce org, including its configuration, custom code, integrations and business processes, works correctly and supports how your teams actually work. It covers everything from individual Apex classes to complete journeys like lead to cash.
What Makes Salesforce Testing Different
What's Different | Why It Matters for Testing |
|---|---|
Dynamic pages | Lightning generates element IDs on the fly and uses Shadow DOM, so tests built on fixed XPath or CSS selectors break often |
Three releases a year | Spring, Summer and Winter releases arrive on Salesforce's schedule, not yours, and can change how standard features behave |
Deep customisation | Custom objects, validation rules, flows, Apex, Lightning components and Visualforce pages make every org unique, so off-the-shelf test scripts won't cover your business logic |
Shared infrastructure | Salesforce is multi-tenant, so performance and behaviour can differ between sandboxes and production |
Lots of integrations | Salesforce exchanges data with ERP, marketing, e-commerce and data platforms, so tests need to cover whole processes, not just Salesforce screens |
Permissions matter | Profiles, permission sets and sharing rules mean different users see different things, so tests need to run as each key role |
When testing falls short, the consequences are real: corrupted customer records, wrong revenue figures, orders that stop flowing to the ERP, sales teams blocked mid-deal and sensitive data exposed by broken access rules.
What to Test in Salesforce
Area | What to Check |
|---|---|
Sales Cloud | Lead conversion, opportunity stages, products and price books, forecasts and approvals |
Service Cloud | Case creation and routing, assignment rules, escalations, SLAs and knowledge articles |
Experience Cloud | Customer and partner portals, logins, self-service and what each user type can see |
Quoting and pricing | Product configuration, discounts, approval thresholds and quote documents |
Automation | Flows, approval processes, validation rules and Apex triggers |
Security | Profiles, permission sets, sharing rules and field-level security |
Integrations | Data moving to and from ERP, marketing, billing and data platforms |
Reports and dashboards | Correct data, filters and totals for each audience |
Industry clouds | Industry-specific objects and processes, like Financial Services Cloud |
For banking and wealth CRMs in particular, see our guide to Salesforce Financial Services Cloud testing.
Types of Salesforce Testing
Type | Who Does It | What It Checks |
|---|---|---|
Developers | Apex classes, triggers and Lightning components work on their own | |
QA | Features, objects, fields, rules and automation work as specified | |
QA and developers | Salesforce exchanges data correctly with other systems | |
QA, usually automated | Changes and Salesforce releases haven't broken anything that worked | |
Business users | Salesforce supports how people really work, before go-live | |
Performance testing | Performance specialists | Pages, reports and APIs are fast enough at real volumes |
Security testing | Security and QA | Access rules, logins and data protection work correctly |
Unit Testing
Salesforce requires at least 75% Apex code coverage across your org to deploy to production, and every trigger needs some coverage . You can run Apex tests from Setup, the Developer Console or the Salesforce CLI:
Bash (Salesforce CLI)
Lightning Web Components are unit tested with Jest, using Salesforce's sfdx-lwc-jest package. Unit tests are fast and precise, but they can't show that a whole process works in the UI, or that data reaches another system.
For testing custom components in more depth, see our guide to Lightning Web Components testing.
Functional Testing
Functional testing checks that each feature does what it should. That includes custom objects across record types and page layouts, field-level security and dependent picklists, approval processes and flows, and custom Lightning components.
Here's an example set of functional tests for one validation rule:
ID | Scenario | Expected Result |
|---|---|---|
FT-12 | Save an opportunity with a discount of 10%, as a sales rep | Saves |
FT-13 | Save an opportunity with a discount of 25%, as a sales rep | Blocked, with the message "Discounts over 20% need manager approval" |
FT-14 | Save the same 25% discount, as a sales manager | Saves |
FT-15 | Save a discount of exactly 20%, as a sales rep | Saves, since the rule says "over 20%" |
Integration Testing
APIs: REST and SOAP APIs return the right data, handle authentication and errors properly, and stay within API limits.
Data sync: data moving both ways between Salesforce and other systems stays consistent, without duplicates or broken mappings.
Middleware: tools like MuleSoft or Boomi route and transform data correctly, and handle failures.
Events: platform events and change data capture trigger the right downstream processes, in reasonable time.
For more on testing APIs and integrations, see our guide to web services testing.
Regression Testing
Every release, configuration change and code deployment can break something that already worked. Regression testing reruns your key tests to catch that, and it needs to run again on every Salesforce major release, ideally in a preview sandbox before production is upgraded.
For a step-by-step process, including sandboxes, release preparation and a release checklist, read our guide on how to perform Salesforce regression testing.
User Acceptance Testing
UAT is where business users confirm Salesforce supports how they really work, before go-live. It's led by sales, service and operations teams, not QA, so it needs realistic scenarios, realistic data and tools business users can actually use.
For how to plan, run and sign off UAT, with templates, see our guide to Salesforce UAT.
Performance Testing
Page load times, especially for pages with complex Lightning components or long related lists
API response times for real-time integrations
Behaviour with many users at once, at busy times
Reports, list views and search as data volumes grow
Salesforce has rules about load testing in its environments, so check its current guidance and get approval before running large load tests, especially against a Full sandbox.
Security Testing
Logins: single sign-on, multi-factor authentication and sessions work correctly.
Access: profiles, permission sets, sharing rules and field-level security stop people seeing data they shouldn't.
Data protection: encryption, masking and audit logging meet your requirements.
Vulnerabilities: custom code is checked for problems like injection and cross-site scripting.
Salesforce Testing Process, Step by Step
Step | What to Do |
|---|---|
1Plan | Decide what to test, based on business risk and how often things change. Choose which sandboxes to use for development, integration testing and UAT. Plan your test data, including how to avoid copying real customer data. Decide what to automate first |
Design tests | Build reusable steps for common actions, like "Create account", "Add contact" and "Create opportunity". Combine them into end-to-end scenarios, like a full sales cycle from lead to closed won |
Run tests | Use manual testing for exploration and usability. Automate regression, smoke tests and anything you run often. Run automated tests in your pipeline on every change |
Manage defects | Link failures to your work tracker, like Jira, with screenshots, logs and steps to reproduce. Work out whether each failure is a real bug, a data problem or a test problem |
Maintain tests | Keep tests current as Salesforce and your org change. Review fixes, retire outdated tests and add tests for new features |
For more on choosing the right sandbox and data at each stage, see our Salesforce testing best practices.
Salesforce Testing Tools
Category | Examples | Good For | Limits |
|---|---|---|---|
Native Salesforce tools | Apex test classes, Salesforce CLI, sandboxes | Unit testing custom code, and required for deployment | Can't test the UI or end-to-end processes |
Component testing | Jest with | Unit testing Lightning Web Components | Only tests components on their own |
Open-source frameworks | Selenium, Playwright, and UTAM (Salesforce's UI Test Automation Model) | Engineers who want full control over UI tests | Need coding skills, and careful upkeep as Lightning changes |
BDD frameworks | Cucumber | Shared language between business and technical teams | Still needs code behind every step |
Recorder-based tools | UFT, TestComplete | Teams that want less code | Recorded tests often break on Salesforce's dynamic pages |
Plain English tests across Salesforce and connected systems, with less upkeep | Not a replacement for Apex unit tests |
For what to look for when comparing options, see our guide to choosing Salesforce test automation tools.
Common Salesforce Testing Challenges
Challenge | What Goes Wrong | What Helps |
|---|---|---|
Dynamic locators | Generated IDs change, so tests break constantly | Finding elements by label, position and context, not one fixed locator |
Shadow DOM | Standard tools can't reach elements inside Lightning Web Components | Tools that handle Shadow DOM directly, so testers can say "click Save in the Opportunity form" |
Salesforce releases | Many tests break at once after a release | Testing early in a preview sandbox, and tools that propose fixes your team can review quickly |
Integrations | Separate UI, API and database tools are hard to coordinate | One test that covers the Salesforce screens, the APIs and the connected systems |
Test data | Building realistic data takes ages, and copying production risks privacy breaches | Tests that create their own data and clean up afterwards, plus synthetic or masked data |
Not enough testers | The org grows faster than the QA team | Plain English tests that admins, analysts and functional testers can write themselves |
If Shadow DOM is the main problem, our guide to automated Shadow DOM testing explains how to handle it.
For realistic test data without copying production, see our guide to synthetic test data.
For more on each of these, read our guide to the top Salesforce testing challenges and how to overcome them.
How to Automate Salesforce Testing
Start with High-Value Processes
Start With | Why |
|---|---|
Revenue processes | Opportunities, quotes and orders affect revenue directly |
High-volume processes | Case creation, contact updates and activity logging happen many times a day |
Regulated processes | Audit and compliance steps need consistent, repeatable checks |
Integrated processes | Journeys that cross into other systems carry the most risk |
Write Tests in Business Language
Instead of coding every click against Salesforce's page structure, describe what the user does. That way, admins, business analysts and functional testers can write and review tests, not just automation engineers.
Plain English (Virtuoso QA)
Build Reusable Steps
Create shared steps for common actions, like "Create opportunity" or "Submit for approval", organised by area, such as account management, opportunities, cases and products. New tests then become a matter of combining steps you already have, and when a process changes, you update the shared step once.
Test Earlier
Write tests from user stories and acceptance criteria before the feature is built, so they're ready to run when it lands. Aim to finish automation in the same sprint as the feature, so test debt doesn't build up.
For how to move testing earlier in delivery, see our guide to shift-left testing.
Build Testing into Your Pipeline
When | What Runs |
|---|---|
Every commit | Apex tests, plus quick smoke tests on critical journeys |
Every night, or each release candidate | The full regression suite |
When an integration changes | End-to-end tests across the connected systems |
Before go-live | Automated UAT scenarios, reviewed by business users |
Each Salesforce major release | Full regression in a preview sandbox |
Measure Whether It's Working
Metric | What It Tells You |
|---|---|
Coverage | The share of key processes and user stories with automated tests |
Bugs caught vs missed | How many bugs testing finds, and how many reach users |
Time spent fixing tests | Whether upkeep is growing or shrinking |
How often tests run | Whether testing keeps up with changes |
Time to feedback | How quickly developers hear about problems |
Release cycle time | Whether testing is speeding releases up or holding them back |
Where Salesforce Testing Is Heading
Trend | What It Means |
|---|---|
AI-drafted tests | Agents read requirements and draft tests in plain English, with people reviewing and approving them |
Continuous testing | Tests run on every commit, pull request and sandbox promotion, not just before release |
Testing what changed | Tests are chosen based on what changed and where bugs have appeared before, rather than running everything every time |
Testing in production | Synthetic transactions check key journeys in production, so problems are spotted before users report them |
Evidence for every release | Teams keep a clear record of what was tested, against which requirement and who approved it |
For a wider look at how generative AI is changing testing, see our guide to the role of generative AI in testing.
How Virtuoso QA Helps with Salesforce Testing
What You Need | How Virtuoso QA Helps |
|---|---|
Tests anyone on the team can write | Tests are written in plain English, with StepIQ suggesting the next step as you write |
Tests from your requirements | Touchstone reads your user stories and specs and drafts requirements and tests, each citing its source, with a named person approving each one |
Tests that survive Lightning changes | Elements are found by label, position and context, and Shadow DOM is handled for you. When a release or change breaks a step, Virtuoso QA suggests a fix for your team to accept or reject |
Reusable business steps | Build steps like "Create opportunity" once, and use them in every test |
Whole processes, not just screens | One test can go through Salesforce, call APIs and check connected systems |
Tests in your pipeline | Runs from Jenkins, Azure DevOps and GitHub Actions on every change, and links results to Jira |
Clear failures | Root cause analysis shows the failing step, screenshots, logs and network calls, with a suggested cause |
Proof for every release | Every run records what was tested, the result and who approved the test |
To see how this works on your own org, take a look at Virtuoso QA's Salesforce test automation.
To explore how Virtuoso QA automates Salesforce end-to-end, watch the detailed walkthrough in the video below:
Salesforce Testing FAQs
How often should Salesforce testing occur?
What are the main types of Salesforce testing?
Does Salesforce require testing before deployment?
Why are Salesforce automated tests hard to maintain?
Which tools are used for Salesforce testing?
Can Salesforce testing be automated without coding?
![](data:image/svg+xml,<svg display="block" id="540005799" role="presentation" viewBox="0 0 12 10" xmlns="http://www.w3.org/2000/svg"><path d="M 6.602 10.182 L 5.727 9.318 L 9.33 5.716 L 0 5.716 L 0 4.466 L 9.33 4.466 L 5.727 0.875 L 6.602 0 L 11.693 5.09 L 6.603 10.182 Z" fill="rgb(8, 7, 7)" height="10.182000000000016px" id="C361dJxCp" width="11.692999999999984px"/></svg>)
