System Testing
System Testing in the Salesforce development lifecycle is end-to-end validation of a complete Salesforce implementation against business requirements before it is promoted to production.
Definition
System Testing in the Salesforce development lifecycle is end-to-end validation of a complete Salesforce implementation against business requirements before it is promoted to production. The work covers every layer of the org: standard and custom configuration, Apex triggers, Lightning Web Components, Flows, declarative automation, integrations with external systems, security and sharing, and the end-user workflows that tie them together. The goal is to catch defects that escape unit and component testing and only surface when the pieces interact.
System Testing sits between Unit Testing (developer-owned, narrow scope) and User Acceptance Testing (business-owned, validation of fit). It is usually run in a Full Sandbox or Partial Copy Sandbox by a dedicated QA team, with a documented test plan that mirrors the production user journeys. Many Salesforce orgs underestimate the effort and ship integration bugs to UAT or production as a result.
System Testing on the Salesforce platform: scope, environments, and the failure modes that matter
Where System Testing fits in the Salesforce SDLC
Standard Salesforce SDLCs sequence testing in five layers: Unit Testing (developer-written Apex tests, run on every commit), Integration Testing (validates a single component plus its immediate dependencies), System Testing (validates the entire stack as one), User Acceptance Testing (business validates that the system meets their needs), and Production Smoke Testing (post-deploy validation in production). System Testing is the layer that catches issues born from cross-component interaction: a Flow updating a record that fires a trigger that calls a callout that updates another record that fires a different Flow. Unit tests cannot catch these because they mock the dependencies; only System Testing exercises the real chain. Skip this layer and integration bugs land in UAT, where the business loses confidence in the build.
What System Testing covers in practice
A well-scoped System Testing plan covers six areas. Functional testing exercises every user journey through the UI and confirms records are written and read correctly. Integration testing exercises every external system connection (REST callouts, platform events, Salesforce Connect external objects, named credentials). Automation testing exercises every Flow, every Apex trigger, every scheduled job, and every Process Builder process that has not been migrated yet. Security testing exercises sharing rules, field-level security, profile permissions, and any custom permission set logic. Performance testing exercises peak-load scenarios against governor limits and large-data-volume queries. Migration testing exercises the data load path from a representative source data file into the target sandbox. Each area needs explicit test cases tied to requirements, not just exploratory poking.
Environments: Full Sandbox is the right home for System Testing
System Testing belongs in a Full Sandbox refreshed from production at the start of the test cycle. The reason is data shape: System Testing has to exercise real-world data volume, real-world picklist values, and real-world record ownership distributions. A Developer Sandbox or Partial Copy with curated test data misses entire classes of bugs that only surface against the actual production data set. The cost is that Full Sandbox refresh has a 29-day cooldown and the refresh itself can take a day or more, so plan the test cycle around the refresh window. For orgs without a Full Sandbox license, Partial Copy is the next-best option, with the understanding that data-volume edge cases will not be caught.
Test data, masking, and the privacy problem
System Testing against production-like data creates a privacy issue: real customer names, emails, phone numbers, and financial data end up in a sandbox that QA testers, consultants, and ISVs can read. GDPR, CCPA, and most enterprise privacy policies require data masking for non-production environments that contain personal data. Salesforce provides Data Mask, a managed package that anonymizes specified fields in a sandbox after refresh. Sensitive fields (Email, Phone, Mailing Address, SSN-style custom fields) get replaced with synthetic values. Run Data Mask immediately after every sandbox refresh and validate the mask configuration as part of the test setup checklist. Skipping this step in a regulated industry is the kind of governance failure that draws fines and consultant blame.
Documentation, traceability, and test-case management
System Testing is only as good as its test cases. Each business requirement should map to one or more test cases, and each test case should record the steps, expected result, actual result, pass or fail status, and the tester. Most Salesforce teams use an external tool (Provar, Copado Robotic Testing, qTest, Zephyr, ALM) for test case management because Salesforce does not ship a native QA tool. The chosen tool integrates with Jira or Azure DevOps for defect tracking, so a failing test case spawns a Jira ticket assigned to the responsible developer. Without this traceability, defects get lost between sandbox refreshes, and the same regression bug ships repeatedly. Pick a tool early and treat its adoption as part of the project plan.
Common System Testing failure modes and how to prevent them
Three failure modes dominate Salesforce System Testing. First, tests run too late: System Testing should start as soon as the first end-to-end thread is buildable, not after every component is done. Second, tests run too narrowly: testers stick to the happy path and miss edge cases like null inputs, record-level access denials, governor limit hits, and concurrent edits. Third, tests are not repeatable: testers click through manually each time, so regression testing is too expensive to run on every change. The fix to all three is to invest in test automation early using a tool like Provar or Copado Robotic Testing. Automated System Tests run on every deploy, catch regressions in minutes rather than days, and let the test team focus on exploratory testing of new behavior.
Running a System Testing cycle on a Salesforce project
Running a System Testing cycle on a Salesforce project is a repeatable process: prepare the environment, build the test plan, execute the tests, log defects, fix and retest. The mistake most teams make is treating System Testing as an afterthought (a week at the end of the project) rather than a sustained activity. Build the test plan early, automate as much as you can, and run System Testing in parallel with development so defects surface while the developer who wrote the code still remembers it.
- Refresh a Full Sandbox and apply data masking
Refresh the System Testing sandbox from production at the start of each test cycle. Wait for the refresh email confirmation; do not log in before the email arrives. Run Salesforce Data Mask immediately after refresh to anonymize personal data fields per your privacy policy. Validate the mask configuration by querying a sample of records and confirming sensitive fields show synthetic values, not real ones. Activate sandbox-specific outbound integration endpoints so the test sandbox does not call production external systems. Reset the integration user passwords and rotate any sandbox-specific API keys.
- Build the test plan tied to requirements
For each business requirement on the project, write one or more test cases that exercise the requirement end-to-end. Each test case includes the user persona, the entry point (where the user clicks), the steps, the expected outcome, and any pre-conditions (specific record states the test depends on). Group test cases into test suites for each release area (Sales workflow, Service workflow, Integration, Security). Load the test cases into your QA tool (Provar, Copado Robotic Testing, qTest, Zephyr). The traceability from requirement to test case is what makes the test report credible at the project gate review.
- Execute tests and log defects with full repro steps
Run each test case manually or via the QA tool automation. On each failure, log a defect in Jira (or your equivalent tracker) with the full repro steps, the expected versus actual result, the environment (sandbox name, browser, user persona), and a screenshot or screen recording. Assign the defect to the developer or admin who owns the affected area. Maintain a defect dashboard showing open defects by severity, by area, and by age. Triage defects daily with the development team during the System Testing cycle so blockers do not sit unaddressed for days.
- Retest fixes and exit when the gate is met
Each defect fix has to be retested against the original test case plus a regression sweep of related areas. Do not close a defect until it has passed retest in the System Testing sandbox. The exit criteria for System Testing are documented at the start of the project, typically a combination of test case pass rate (often 95 percent or higher), open severity-1 defect count (usually zero), and stakeholder sign-off. When the exit criteria are met, freeze the sandbox and promote the build to UAT. Document the test report and link it from the release tracker.
- Curated test data misses real-world data shape. Production-like data (refreshed from a Full Sandbox and masked) is the only way to surface bugs born from unusual picklist values, ownership distributions, and record volumes.
- Manual System Testing does not scale across regression cycles. Without automation in a tool like Provar or Copado Robotic Testing, every release degrades into a guessing game about what to retest.
- Outbound integration endpoints inherit production values on sandbox refresh. Without explicit reconfiguration, the System Testing sandbox can fire real production integrations and create real-world side effects.
- Data Mask is an additional managed package, not a built-in. In regulated industries, skipping the mask exposes the org to privacy violations regardless of how good the test plan is.
- Exit criteria written at the end of testing are negotiated under pressure. Document them at project start, get sign-off from the business and compliance, and treat them as the gate that they are.
Trust & references
Straight from the source - Salesforce's reference material on System Testing.
- Sandbox OverviewSalesforce Help
- Salesforce Data Mask OverviewSalesforce Help
- Apex Testing OverviewSalesforce Developer Docs
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is System Testing?
Q2. What does it cover?
Q3. Why can't unit tests replace it?
Discussion
Loading discussion…