How Many Test Cases Does a Salesforce Regression Suite Need?

Why is there no fixed number of Salesforce test cases?

There is no fixed number because the count depends on what each change touches, and one Salesforce field appears in many places. A field added to an object shows up on page layouts, Lightning record pages, list views, reports, Flows, formula fields, Apex code and integrations. Every one of those places is a spot where the change can break something.

A change to a field nobody else uses needs a handful of test cases. A change to a field that sits on ten pages, feeds two reports and flows into an invoice needs many more. The same org produces small and large test lists in the same sprint, depending on which fields the tickets touch.

Why does org size give a poor estimate?

Org size gives a poor estimate because Salesforce orgs reuse fields across objects, pages and automations, and object count does not show that reuse. Two orgs with 40 custom objects each can need very different suites. In the first org, each field lives on one page. In the second, the same fields appear on several record pages, drive approval rules and sync to an ERP system.

Pages in the Salesforce org PerfectQA tested for an insurance organization held more than 50 fields each. Data in that org moved from lead to contact to account to quote to invoice and back. A change to one field on that chain reached every object after it, so the test count followed the chain, and the number of objects in the org played little part.

What is a Salesforce regression test case?

A Salesforce regression test case is one check that a specific place in the org still behaves the same after a change. Each test case covers one place, one user role and one expected result, which keeps a failure easy to trace back to its cause.

A regression test case for Salesforce holds 5 parts:

• the place it checks, such as a record page, a report or a Flow

• the user role that runs it, because Salesforce shows and hides fields by profile and permission set

• the starting data, such as an account with an open quote

• the steps the tester or script follows

• the expected result, written as a value or a behaviour a tester can confirm

The table shows one example test case in that format, written for a new subcategory added to an invoice field.

One test case like this per place is what makes the count predictable. Ten affected places mean at least ten test cases, before any core business flows are added.

How do you count test cases for one change?

To count test cases for one change, list every place the change appears and write one test case for each place. The total for the change is the length of that list, plus extra test cases for places that behave differently by user role.

What does one field change touch?

One field change touches up to 10 areas of a Salesforce org. Each area fails in a different way, so each one needs its own check:

• Page layouts and Lightning record pages show the field. A missing or misplaced field here is the most visible failure.

• List views display or filter on the field. A list view that filters on the old values hides records once the values change.

• Reports and dashboards group, filter or sum by the field. A new picklist value that a report does not include drops records out of the totals.

• Flows, approval processes and assignment rules read or update the field. A Flow that checks for the old values skips records with the new one.

• Validation rules check the field's value. A rule written for the old values blocks users from saving valid records.

• Formula fields use the field in their calculation. A formula that does not handle the new value returns a blank or a wrong result.

• Apex triggers and classes reference the field. Code that expects a fixed set of values fails or behaves differently.

• Integrations send or receive the field, such as ERP or billing systems. A connected system that does not recognise the new value rejects the record or stores it wrongly.

• Profiles, permission sets and field-level security control who sees and edits the field. A role without access sees an empty page section or cannot complete its work.

• Records further down the data flow copy or depend on the field's value. A quote that copies the field to an invoice carries any error into the invoice.

Each area that uses the changed field gets at least one test case. Areas that behave differently by role, such as record pages and permissions, get one test case per affected role.

How do you find every place a field is used?

Find every place a field is used by combining Salesforce's own references with a field-usage map your team keeps current. No single tool lists everything, so the search runs in 4 steps:

1. Open the field in Setup and use "Where is this used?". Salesforce lists references in page layouts, Flows, Apex classes and other metadata.

2. Use Salesforce Inspector, a free browser extension that shows field API names and record values on any Salesforce page, to trace the field on busy pages. On pages with more than 50 fields, Salesforce Inspector finds a field that is hard to spot by reading the layout.

3. Check integration mappings with the team that owns each connected system. Salesforce does not list references that live outside the org, such as a field mapping inside a billing tool.

4. Record every place you find in a field-usage map, and update the map with every change.

The field-usage map is the step most teams skip. It turns the next change to the same field from a search into a lookup.

How do you build an impact map for a change?

An impact map is a table of every place a change touches, with the test cases each place needs. The tester builds it before writing any test case, and the test list comes straight from it.

The table shows a simplified impact map for a new subcategory added to an invoice field. A real map lists the actual page, report and Flow names from the org.

Adding up the last column gives the test count for the change. A change that touches more roles, reports or Flow paths produces a longer list.

What happened with one field change in an insurance org?

One new invoice subcategory needed 15 to 20 test cases, and one missed place blocked the testing. The ticket added a subcategory to an invoice field in the insurance org, and the team tested it inside a two-week sprint, the same way it tested every other ticket.

The first test list covered the pages and the invoice data flow the team knew about. The field also appeared in one place that no document recorded. 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 the field appeared was the hardest part of the ticket; running each test case was simple. The team used Salesforce Inspector to trace the field across pages with more than 50 fields each. The lesson from that ticket is the reason the field-usage map comes before the test list.

How many test cases do different types of change need?

Different types of change reach different parts of the org, so each type produces a different test list. A new field reaches only the places it is added to, while a change to an existing field reaches every place that already uses it. The table compares 8 common change types.

Changes to existing fields produce the longest lists, because existing fields already sit in many places. A new picklist value looks like a one-line change and often needs more test cases than a whole new field.

How do you pick which Salesforce test cases to run first?

Pick Salesforce test cases in order of how close they sit to the change and how much business depends on them. Running them in this order finds the most likely defects first and leaves the lowest-risk checks for the end of the window. The order has 5 groups:

1. Test cases for every place the change touches directly. Defects appear here first, because these are the places the developer edited.

2. Test cases for records further down the data flow, such as the quote and invoice after an account change. These defects are harder to notice, because the edited page itself looks fine.

3. Test cases for the core business flows that run every release. These protect the work that stops revenue or service when it breaks.

4. Test cases for the user roles whose access the change affects. A change that works for an admin fails for a role with narrower permissions.

5. The remaining test cases in the suite, when the release window allows a full run.

Groups 1 and 2 come from the impact map, so they change with every ticket. Group 3 is the same every time, so it is the first group to automate.

What goes into the core regression suite?

The core regression suite holds the end-to-end business flows that run on every release, whatever changed. These are the flows that stop revenue or service work when they break, so they get tested even when no ticket touches them.

A Salesforce core suite usually covers 5 kinds of flow:

• the sales flow from lead to contact to account to quote to invoice

• case creation, routing and closure in Service Cloud

• approval processes for discounts, quotes or contracts

• data exchange with each connected system, such as ERP or billing

• login and record access for each main user role

Each core test runs a flow from start to finish across objects. A test that creates a lead, converts it, builds a quote and produces an invoice catches problems that page-by-page checks miss.

Size the core suite by the number of business-critical flows. To find them, ask which flows stop revenue, service or reporting when they break. The number of objects in the org does not set the size of the core suite.

What is the difference between a smoke test and a full regression run?

A smoke test checks that the critical flows still open and save after a deployment, and a full regression run checks every affected area plus the core suite before a release. Between the two sits the targeted run, which tests only the impact list of one change. The table compares all three.

A failed smoke test stops the release on the spot. A targeted run catches defects while the developer still remembers the change. A full regression run finds the defects the other two do not reach, such as a downstream report that a ticket never mentioned.

How does the suite change between internal changes and seasonal releases?

The suite grows with the size of the event. An internal change runs its own impact list, a sprint runs every impact list plus the core suite, and a seasonal release adds the areas Salesforce itself changed:

• Each ticket runs the test cases from its own impact list.

• Each sprint runs the impact lists of all its tickets plus the core suite. A two-week sprint cycle means 26 of these rounds a year.

• Each of Salesforce's 3 seasonal releases (Spring, Summer and Winter) runs the core suite in a preview sandbox before the production upgrade, plus test cases for features named in the release notes and for each item on the Release Updates page.

Seasonal releases change the platform under the org, so the core suite carries most of the load in those 3 rounds. Salesforce publishes the sandbox preview and production upgrade dates for each instance on its Trust site, which sets the deadline for the seasonal round.

Which Salesforce test cases should you automate?

Automate the test cases that run every round and cover flows that no longer change. The core regression suite fits that rule first. Impact tests for fields that change often come next, because the same checks repeat each time the field changes.

A test case is ready for automation when it meets 3 conditions:

• It runs in most rounds, such as a core flow or a frequently changed field.

• The page and flow it covers have stopped changing.

• Its expected result is a clear value or behaviour a script can check.

Keep the test cases for a brand-new change manual for its first rounds, because the page and the flow are still settling. Automated scripts written too early break with every adjustment and cost more to fix than to run by hand.

Salesforce Lightning pages need care in automation, because element IDs change between page loads and components sit inside a Shadow DOM. PerfectQA builds automated Salesforce suites in Playwright and Selenium, with locators based on labels and stable attributes. Our automation testing services page explains how.

What test data do Salesforce regression test cases need?

Salesforce regression test cases need records that match each test case's starting point, for every role that runs it, in a sandbox that holds realistic data. A test case for an invoice report needs invoices that already exist, with the values the report groups by.

Salesforce has 4 sandbox types, and they differ in the data they hold:

• Developer and Developer Pro sandboxes copy the org's setup and metadata, with no production records.

• Partial Copy sandboxes copy the setup plus a sample of production records, chosen by a template.

• Full sandboxes copy the setup and all production records.

Regression testing runs best in a Full or Partial Copy sandbox, because the data there matches what users work with. Teams that test with production copies mask personal and financial fields before testers use them, and agree on data handling in the NDA.

Downstream test cases need connected records. A test of the quote to invoice flow needs an account, a contact, an opportunity and a quote that fit together, so the team prepares these record sets once and reuses them every round.

How do you keep a Salesforce regression suite from growing out of control?

Keep a Salesforce regression suite at a manageable size by retiring, merging and updating test cases after every change. A suite that only grows ends up slower to run and full of checks for things the org no longer does.

The upkeep has 5 parts:

• Retire test cases for fields, pages and flows the org no longer uses.

• Merge test cases that check the same field on the same page for the same role.

• Update test cases in the same sprint as the change they cover.

• Update the field-usage map whenever a field moves or gets a new use.

• Review the core suite after each seasonal release, and add any flow that broke in that round.

A suite maintained this way stays close to the size of the org's real risk. Each test case in it still checks something users depend on.

What mistakes make a Salesforce regression suite the wrong size?

Six mistakes make a Salesforce regression suite too small to catch defects or too large to run:

• Sizing the suite by object count. Field reuse sets the count, and object count does not show it.

• Testing only the page the developer edited. Defects in reports, Flows and integrations go unseen.

• Skipping records further down the data flow. A wrong value on a quote reaches the invoice.

• Testing every change as an admin. Admins see every field, so permission defects never show.

• Never retiring test cases. The suite grows past the time the team has to run it.

• Treating Apex code coverage as regression testing. Code coverage checks code paths and leaves business flows untested.

Each mistake has the same fix: build the test list from an impact map, and review it as the org changes.

FAQs