Salesforce Regression Testing Services: What's Included and How to Choose a Partner

What does a Salesforce regression testing service include?

A Salesforce regression testing service checks 6 parts of the org after each change. Each part breaks in its own way, so each gets its own test cases.

• Business automation: Flows, approval processes, validation rules and assignment rules fire in the same order and produce the same results as before the change. A Flow that checks for old values skips records with new ones, and nobody notices until a record stalls.

• Data flow between objects: records move through the full chain, for example lead to contact to account to quote to invoice, with every field value carried across. A wrong value on one object travels into every object after it.

• Integrations: ERP, billing and marketing systems send and receive the same data in the same format. A connected system that does not recognise a new value rejects the record or stores it wrongly.

• Permissions: profiles, permission sets and sharing rules give each user role the same access as before. A change that works for an admin fails for a role with narrower access.

• The Lightning user interface: Lightning pages, page layouts and Lightning Web Components (LWC, Salesforce's component framework) display and save data correctly.

• Custom code behaviour: Apex triggers and classes produce the same business result. Developers' Apex unit tests check code coverage; regression tests check the outcome a user sees.

The service covers the clouds the org runs on. PerfectQA tests Sales Cloud, Service Cloud, Marketing Cloud and Salesforce CPQ (Configure, Price, Quote) orgs.

Why do small changes need regression testing?

Small changes need regression testing because one Salesforce field appears on many pages, automations, reports and integrations, so a change made on one screen breaks behaviour on another. Salesforce's three seasonal releases a year (Spring, Summer and Winter) add platform changes on top of the org's own changes.

Most breakage comes from the org's own changes between releases. An admin adds a picklist value, a developer updates a Flow, a new field goes onto a page layout. Each change looks contained to the person who made it, and each one reaches places the person did not open.

What happened when one field changed in an insurance org?

One new invoice subcategory blocked testing because no document recorded every place the field appeared. PerfectQA tested a large Salesforce org for an insurance organization. Pages in that org held more than 50 fields each, and the team tested changes ticket by ticket in two-week sprints.

The ticket added a subcategory to an invoice field. The first round of testing covered 15 to 20 test cases. One place that used the field was missing from that list. Its value never showed up where the test expected it, and the tester stopped to work out why before testing could continue.

Finding every place a field appears was the hardest part of that project; running each check was simple. Data in that org moved from lead to contact to account to quote to invoice and back, so one wrong value travelled through the whole chain.

How does impact mapping prevent missed changes?

Impact mapping lists every page, Flow, report and integration that reads or writes the changed field before any test case is written. The test cases then come from that list, so no affected place is left out.

The tester builds the list from three sources: Salesforce's "Where is this used?" button on the field in Setup, a trace of the field across pages with Salesforce Inspector, and the integration mappings held by the teams that own connected systems. The list goes into a field-usage map that the team updates with every change, so the next change to the same field starts from a lookup. Our guide to how many test cases a Salesforce regression suite needs walks through this method in detail.

Which teams need a Salesforce regression testing service?

Teams need a Salesforce regression testing service when the org changes faster than they can re-test it. Six signs show the org has reached that point:

• The org changes every sprint, and testing falls to the person who built the change.

• Record pages carry dozens of fields, and the same fields appear on several objects.

• The org exchanges data with ERP, billing or marketing systems.

• Users report broken features after deployments, before the team finds them.

• Seasonal releases arrive with no time set aside to check the org.

• The company has no dedicated QA team for Salesforce.

An org that shows two or three of these signs has more change than its team can check by hand. The rest of this article explains what working with a regression testing partner looks like.

How does a Salesforce regression testing engagement work?

A Salesforce regression testing engagement runs in 6 steps, from learning the org to keeping the test cases current.

1. Learn the org. The tester maps objects, data flow, user roles and integrations first. Salesforce needs little test setup compared with a custom web application, so most of the early time goes into understanding how data moves through the org.

2. Map the impact of each change. The tester lists every page, automation, report and integration that uses the changed field or rule. Salesforce Inspector, a free browser extension that shows field API names and record data on any Salesforce page, finds and traces a field on pages with more than 50 fields.

3. Select test cases by impact. Every affected place gets a test case, and places that behave differently by role get one per role. A single field change on the insurance project started at 15 to 20 test cases.

4. Run the tests in a sandbox. Manual tests cover the new change, and automated tests cover stable flows that repeat every release.

5. Report the results. Each run ends with a report of passed and failed test cases, the defects found and what is safe to deploy.

6. Keep the test cases current. The QA team updates test cases after every change, so the next run matches the current org.

PerfectQA sets the cadence to each client's release schedule: sprint by sprint, before internal deployments, or before a Salesforce seasonal upgrade.

What does a testing partner need from your team?

A testing partner needs 5 things from your team to start testing:

• access to a sandbox, with a user account for each role the tests cover

• the release calendar, including sprint dates and planned deployments

• a list of connected systems and the people who own them

• any existing documentation of objects, fields and business processes

• one contact who receives defects and answers questions about intended behaviour

The first weeks of an engagement go into learning the org from these inputs. The field-usage map and the core test cases grow out of that work.

Is manual or automated regression testing better for Salesforce?

Salesforce regression testing works best as a mix of the two. Manual testing covers new and changed features, and automated testing covers stable flows that repeat every release. The table compares the two approaches on a Salesforce org.

A new change stays manual for its first rounds, because the page and the flow are still settling. Move a test to automation once the flow it covers stops changing. The core business flows, such as lead to invoice or case creation to closure, are usually the first tests to automate, because they run every round.

How do Playwright and Selenium handle Salesforce Lightning?

Playwright and Selenium both test Salesforce Lightning, and both need locators built on labels and stable attributes. Playwright and Selenium are open-source browser automation frameworks, and PerfectQA uses both for Salesforce.

Salesforce Lightning builds pages from components inside a Shadow DOM, an encapsulation layer that hides a component's internal HTML, and many element IDs change between page loads. Playwright's locators reach inside open shadow roots by default, and Selenium 4 reaches them through its shadow root API.

Both frameworks need script updates when a Salesforce release changes a component. Our automation testing services page covers how we build those suites.

Who fixes the tests when a change breaks them?

The QA team fixes the test cases, and the client's Salesforce developers fix the defects in the org. A failed test has one of two causes. Either the org changed on purpose and the test is out of date, or the change broke something.

The tester decides which cause applies, and the split decides who acts next. The QA team updates an out-of-date test in the same sprint. A real defect goes to the developers with the steps to reproduce it. Ask every partner who owns this step, and whether it is part of the agreement.

How does a defect move from tester to developer?

A defect moves from tester to developer in 4 steps:

1. The tester confirms the failure by repeating the test case, and checks it against the intended behaviour.

2. The tester logs the defect with the steps to reproduce it, the expected result, the actual result, the user role and evidence such as a screenshot.

3. The developer fixes the defect in a sandbox.

4. The tester re-runs the failed test case and the test cases around it, and closes the defect when they pass.

Step 4 is a small regression run of its own, because a fix is also a change.

What do you get after each regression run?

After each regression run, you get a report that shows which test cases passed and failed, which defects the run found, and whether the change is ready to deploy. PerfectQA shares these results in TestReport.

[IMAGE: anonymised TestReport sample. Alt text: "Salesforce regression test results in TestReport showing passed and failed test cases"]

What does a useful regression report list?

A useful regression report lists 4 things:

• each test case with its pass or fail status

• each defect with steps to reproduce, the expected result and the actual result

• evidence such as screenshots

• a release summary that states what is safe to deploy and what is blocked

[NEEDS: confirm which of these fields TestReport shows]

A release manager reads the summary to decide whether to deploy. A developer reads the defects to fix them. The same report serves both, so each part needs to stand on its own.

How does a regression testing service handle Salesforce's seasonal releases?

A regression testing service handles a seasonal release by running the core business flows in a preview sandbox before Salesforce upgrades production. Salesforce upgrades preview sandboxes several weeks before production, and publishes the dates for each instance on its Trust site.

A seasonal round covers 3 sets of test cases:

• the core regression suite, which checks the business flows that run every release

• test cases for the features in the release notes that touch the clouds the org uses

• test cases for each item on the Release Updates page in Setup, many of which have an "Enable Test Run" option that switches the change on in a sandbox before Salesforce enforces it

A failure in the preview sandbox has two possible sources: the org's own setup or the new Salesforce release. The tester repeats the test in a sandbox still on the current release to tell them apart. PerfectQA runs seasonal rounds when the client's release calendar calls for them.

Staff augmentation or managed testing: which fits your team?

Staff augmentation fits teams that already run their own QA process and need more testers. Managed testing fits teams that want the partner to run the whole regression process.

How do staff augmentation and managed testing differ?

Staff augmentation and managed testing differ in who manages the testers and who owns the test cases. The table shows where responsibility sits in each model.

A team with a QA lead gets more from staff augmentation, because the lead already sets priorities. A team without one gets more from managed testing, because someone has to own the test strategy.

Which fits: one-time or ongoing regression testing?

One-time testing fits a single event, and ongoing testing fits an org that changes every sprint or release.

• A one-time engagement checks the org before a single event, such as a seasonal release, a large deployment or a go-live.

• Ongoing regression testing runs every sprint or release, and keeps the test cases current between runs.

A one-time engagement still produces test cases and a field-usage map, and both keep their value for the next release. PerfectQA sets the model to each client's needs. Teams that want testers inside their own process can start with Hire a Tester.

Does testing across time zones work for Salesforce?

Testing across time zones works for Salesforce when the partner sets working hours that overlap with the client's team and hands over results at the end of each day. Defects logged with full steps and evidence need little discussion, so a short daily overlap covers most questions.

PerfectQA works to each client's time zone and release schedule.

What drives the cost of Salesforce regression testing?

The cost of Salesforce regression testing depends on 6 factors:

• Org size: the number of clouds, custom objects and fields per page. A page with more than 50 fields takes more checks per change than a standard layout.

• Integrations: each connected system adds test cases for the data going in and out.

• Change frequency: a two-week sprint cycle means 26 regression rounds a year, plus 3 seasonal releases.

• Automation share: automated tests cost more to build and less to run.

• Suite size: more test cases mean longer runs.

• Maintenance: interface changes and Salesforce releases mean test updates.

A scoped estimate needs a look at the org's objects, integrations and release calendar. A price quoted without seeing them is a guess.

Automation changes the cost over time. The first months carry the cost of building scripts, and later rounds cost less because the scripts run without a tester clicking through each step. An org that changes every sprint reaches that point sooner than one that changes a few times a year.

How does a testing partner handle your Salesforce data?

A testing partner handles Salesforce data under an NDA, inside sandboxes, with user accounts limited to the roles the tests need. Production data stays in production.

Salesforce has 4 sandbox types. Developer and Developer Pro sandboxes copy the org's setup without production records. Partial Copy sandboxes copy the setup plus a sample of records chosen by a template. Full sandboxes copy the setup and all records. Regression testing runs best in a Full or Partial Copy sandbox, because the data matches what users work with, and teams mask personal and financial fields in those copies before testers use them.

Agree on 3 points before testing starts:

• which sandboxes the partner uses, and which user accounts it receives

• how personal and financial data is masked in those sandboxes

• who owns the test cases, scripts and field-usage map when the engagement ends

PerfectQA works under a full NDA with its Salesforce clients.

What should you ask a Salesforce testing partner before hiring?

Ask a Salesforce testing partner these 8 questions before you hire. Each one comes with the kind of answer that shows the partner understands Salesforce.

1. Ask how they find every place a change appears in your org. A good answer names a method, such as an impact map built from "Where is this used?", page tracing and integration mappings.

2. Ask which Salesforce clouds they have tested, such as Service Cloud or CPQ. A good answer names the clouds and the kind of flows tested in each.

3. Ask which automation tools they use, and how they handle Lightning's changing elements. A good answer mentions locators based on labels or stable attributes.

4. Ask who updates the test cases after a change or a release. A good answer says the QA team does it in the same sprint.

5. Ask for a sample report. A good report shows pass and fail status, defects with steps, and a release summary.

6. Ask how they handle production-like data in sandboxes, including NDA terms and data masking.

7. Ask which working hours overlap with your team, and how results are handed over each day.

8. Ask which certifications their testers hold.

PerfectQA's answers to these questions are in the FAQ below.

When is a regression testing service not worth it?

A regression testing service is not worth it for a small org with mostly standard objects, few integrations and only a few changes a year. For that org, an admin with a short checklist of the main business flows covers the risk. Salesforce's Release Updates page, with its "Enable Test Run" option, covers the platform changes.

A short checklist of that kind covers lead conversion, opportunity closing, case handling and any approval process the org runs. The admin walks through it after each change and before each seasonal release.

When does a regression testing service pay off?

A regression testing service pays off once the org meets one of 3 conditions:

• the org has custom fields that appear on many pages

• the org runs several integrations

• the org changes every sprint

At that point, the checklist grows longer than the admin's time, and defects start reaching users first.

FAQs