Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Full Regression Testing entry
How-to guide

Run a Salesforce regression suite before a production deploy

A Salesforce regression suite combines Apex tests, optional UI automation, and a sandbox to run them against. The steps below cover the most common workflow: prepare the sandbox, run the suite, triage failures, then unblock the deploy.

By Dipojjal Chakrabarti · Founder & Editor, Salesforce DictionaryLast updated May 26, 2026

A Salesforce regression suite combines Apex tests, optional UI automation, and a sandbox to run them against. The steps below cover the most common workflow: prepare the sandbox, run the suite, triage failures, then unblock the deploy.

  1. Refresh the sandbox to a recent baseline

    Refresh a full or partial sandbox so the regression suite runs against current data and metadata. For pre-release testing, refresh to the preview pod assignment that exposes the upcoming Salesforce release.

  2. Run the Apex test suite

    Run All Tests in Setup, Apex Test Execution. Watch the test runner for failures and coverage drops. The Tests tab shows per-method pass/fail; the Code Coverage tab shows the lines each test touched.

  3. Run the UI automation suite

    Trigger the UI automation tool (Provar, AccelQ, Selenium) against the sandbox. UI suites take longer to run than Apex suites; budget a few hours for a moderate-sized scenario library.

  4. Triage failures by impact

    For every failing test, decide whether the failure points to a real regression in the change being tested or a test-maintenance issue like a stale assertion or a UI selector that no longer matches. Fix real regressions; update tests for legitimate change.

  5. Block the deploy or unblock

    If the regression suite passes, proceed with the production deploy. If it fails, either fix the change being tested or document an accepted regression with stakeholder sign-off before deploying.

Key options
Apex test execution scoperemember

Choose between Run All Tests (slow, full coverage) and Specified Tests (faster, narrower). Run All Tests before production deploys.

Sandbox refresh cadenceremember

Full sandbox refreshes are slow but produce realistic regression results. Partial sandboxes refresh faster but may miss data-driven bugs.

CI vs manual triggeringremember

Continuous integration runs the suite on every commit; manual triggering runs on demand. CI catches regressions earlier but requires automation investment.

Gotchas
  • 75 percent code coverage is a line-coverage metric, not a behaviour metric. Tests that hit lines without asserting outcomes pass the deploy gate but catch no real regressions. Always pair coverage with meaningful assertions.
  • Apex tests cannot exercise UI behaviour like page layouts, conditional component visibility, or validation message order. UI automation is the only way to cover that layer reliably.
  • Stale sandbox data hides bugs that production data would expose. Refresh sandboxes regularly and treat the freshness of the regression baseline as a leading indicator of regression quality.

See the full Regression Testing entry

Regression Testing includes the definition, worked example, deep dive, related terms, and a quiz.