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.