A Salesforce test strategy is a short document that decides four things before anyone writes a test case: what you will test, where, by whom, and when you are allowed to go live. On an implementation, it maps each type of testing to a project phase: unit and flow tests while you build, integration and data migration tests in a Partial or Full sandbox, UAT with business users, a smoke run at cutover, then automated regression for every release after.

In 2027, add one more line to that: plan for the platform changing under you mid-project. Spring ‘27 lands in sandboxes on January 9, and older integration logins are being retired through the year.

That’s the whole answer. The rest of this post is the template, the phase map, the 2027 changes, and the scars.

The short version

• A test strategy is one page of decisions. A test plan is the per-release schedule that follows it. Write the strategy in week one.

• Salesforce breaks differently from custom apps. Config is code, permissions change what users see, and Salesforce upgrades your org three times a year whether you’re ready or not.

• Map every test type to a phase and a sandbox. Most chaos comes from running the right test in the wrong place.

• Start with a risk-based smoke suite of 20 to 40 tests. Not 250.

• Decide who owns what between the SI and the customer before build starts. “QA will handle it” is not an owner.

• Plan for 2027’s platform changes now: three seasonal releases, retiring login flows for integrations, and agents in scope.

• Go-live is not the finish line. It’s the first of many regression runs.

Why I’m writing this

We spend most of our week on calls with Salesforce teams. Admins, architects, release managers, SI partners. So we went back through our call notes from July 30 to October 30 this year and counted which testing problems prospects actually raised.

The top of that list is not exotic. Manual regression that slows every release. Scripts that break when Salesforce changes the UI. Coverage gaps in CPQ, flows and integrations. Security questions. Almost none of these are tool problems. They’re strategy problems that show up later as tool problems.

Most of them get decided, or ignored, in the first two weeks of an implementation. So let’s decide them on purpose.

Test strategy vs test plan on a Salesforce project

People use these words interchangeably. They shouldn’t. One is a set of decisions. The other is a schedule.

A good strategy makes every test plan boring. That’s the goal.

If you need the plan part, our UAT test plan generator builds a Salesforce UAT plan in a few minutes.

Why Salesforce implementations break differently

Strong QA teams from custom-app backgrounds often struggle on Salesforce. Not because they’re bad. Because the failure modes are different.

Config is code. A flow, a validation rule or a page layout change can break a process as hard as a code change. And it often ships without a pull request.

Permissions change the app. The same page looks different to a sales rep, a manager and an admin. A test run as admin passes. The rep still can’t save the opportunity. We wrote about this in why multi-user testing beats admin bias.

Salesforce upgrades you three times a year. Spring, Summer, Winter. Your org gets the release on Salesforce’s calendar, not yours. Sandboxes get it a few weeks early.

Integrations hide in the back. ERP, billing, marketing, data warehouse. The UI looks fine while orders stop flowing.

Most projects aren’t greenfield. One of our SI partners told us only about 30% of their projects are clean new builds. The rest land in an org with years of history, packages and someone’s 2019 workflow rule nobody wants to touch.

A strategy that ignores these five things is a generic QA strategy with a Salesforce logo on it.

What changes for Salesforce testing in 2027

Most of a good strategy is timeless. A few things are specific to programs running in 2027. Put them in the risk register on day one.

Spring ‘27 arrives early in the year. Sandbox previews start January 9, 2027. Production orgs upgrade in waves from January 16 to February 20, depending on the instance. If your build or UAT runs in January, your sandboxes may be on a newer release than production. Check your dates in our Salesforce release calendar. Summer ‘27 and Winter ‘28 follow; plan two more regression windows before the year ends.

Integration logins are being retired. Salesforce is moving integrations off older authentication. Creating new connected apps has been off by default since Spring ‘26, in favor of External Client Apps. Release-update trackers list more retirements for 2027, including older OAuth user-agent flows on February 20, 2027 and the SOAP API login() call for API versions 31.0 to 64.0 in Summer ‘27 (PTC’s 2027 release assessment). Any test harness or integration test that logs in with a username and password needs a plan. Check Setup, then Release Updates, in your own org for exact dates.

Agents are in scope by default. More implementations now include an Agentforce agent somewhere. Agents need multi-turn tests and data checks, not just page checks. There’s a section on this below.

Generating test cases is cheap. Choosing them isn’t. AI can turn every Jira story into ten test cases in seconds. That makes the risk ranking in your strategy more important, not less. Otherwise you get 2,000 tests and no idea which 30 matter.

The 10 parts of a Salesforce test strategy

Copy this. Fill it in. Keep it under three pages.

1. Scope. Clouds, processes and integrations in scope. List what’s out of scope too. Out of scope is where blame goes to live, so write it down.

2. Risk ranking. The top business processes ranked by revenue and blast radius. This drives everything else.

3. Test types and phases. Which tests run, in which phase, in which sandbox. The table in the next section.

4. Environments. Sandbox per purpose, refresh rules, who can deploy where.

5. Test data. Where data comes from, how it’s masked, how it’s reset between runs.

6. Roles. Who writes, runs and signs off each test type. SI and customer split.

7. Tools. Test management, automation, defect tracking, CI. Pick boring ones that the customer can keep after the SI leaves.

8. Entry and exit criteria. What must be true to start and finish each phase. Numbers, not adjectives.

9. Defect process. Severity definitions, triage rhythm, who can waive a defect.

10. Post-go-live regression. How the suite runs for every sprint and every Salesforce release after launch.

Part 10 is the one teams skip. It’s also the one they pay for longest.

Which types of testing a Salesforce implementation needs

Not every project needs every row. But you should consciously decide on each one.

Two notes from the field.

On Apex, Salesforce requires at least 75% code coverage with all tests passing to deploy to production. Salesforce’s own Trailhead calls 75% the lowest bar, not the target. Coverage tells you code ran. It doesn’t tell you the business process works.

On performance, Salesforce sells Scale Test as a paid add-on that runs in a Full Copy sandbox, booked in slots. It also recommends running performance tests separately from functional and regression testing. Don’t point a load tool at production and hope.

Map every test to the implementation timeline

This is the part most strategy docs get wrong. They list test types. They don’t say when. So everything piles up in the last three weeks and UAT becomes system testing with nicer snacks.

Discovery and design. Write the strategy. Rank the risks. Agree on acceptance criteria per story. Pick tools. No tests run yet, but most test failures are born here.

Build sprints. Unit tests, flow tests and functional tests per story. Start the smoke suite now, small. If your stories come from Jira, generate the first draft of test cases from them, then check them against the live UI. Requirements drift. The screen is the truth.

System integration testing (SIT). End-to-end flows across Salesforce and connected systems. Permission tests with real profiles. First data migration rehearsal. This needs a Partial Copy or Full sandbox.

UAT. Business users run real scenarios with realistic data. QA doesn’t run UAT for them. QA makes sure UAT isn’t the first time anything was tested.

Cutover. Final migration, deploy, smoke run in production with a named go or no-go owner.

Hypercare. Daily smoke runs. Fast defect triage. Watch the integrations.

After go-live. Every sprint and every Salesforce release gets a regression run. More on this below.

Your sandbox plan, in one table

Sandboxes are where good strategies quietly die. Two teams share one, someone refreshes it on a Friday, and UAT data vanishes.

Source: Salesforce, Sandbox Licenses and Storage Limits by Type.

A simple path works for most programs: Developer for build, a QA sandbox for SIT, a Full or Partial sandbox for UAT, then production. Write down who can refresh each one. Seriously.

I won’t repeat the full environment playbook here. It lives in our post on Salesforce test environment strategy.

Risk-based testing: pick the right 30 tests first

Generation is cheap now. Picking is the skill.

Our partner 2Pace turned about 25 Jira tickets into roughly 250 test cases for a B2B commerce build. When the client asked for a demo, they didn’t show 250. Their QA lead picked the 20 that mattered most. That became the smoke suite.

Here’s the method in one picture.

Score each business process on two things: how bad a failure would be, and how likely it is to change. Revenue, compliance and customer-facing processes score high on impact. Anything touched by this release, by a managed package or by a Salesforce release scores high on change.

• High impact, high change: automate first. Run on every deploy.

• High impact, low change: automate, run every release.

• Low impact, high change: light checks, run in the sprint.

• Low impact, low change: sample in UAT. Accept the risk in writing.

Ask the business for its top three processes. Write 5 to 10 tests for each. That’s a 20 to 40 test smoke suite. Run it on every deploy before you grow it.

Test data and data migration testing

Bad test data creates fake failures. Fake failures teach people to ignore red builds. That’s how real bugs get through.

• Seed, don’t borrow. Build test data with scripts or a data tool, not by copying production into a Developer sandbox by hand. Mask anything personal.

• Reset between runs. Every test that creates a record cleans it up, or runs on data made fresh for it.

• Keep data out of steps. Environment values and test data live in variables, not hardcoded in the test.

Migration testing is its own track. Reconcile record counts per object. Check relationships, not just rows: does the contact still point to the right account? Validate picklists and owners. Run the full migration at least twice before cutover, and time it. A migration that takes 14 hours does not fit in a 10-hour cutover window.

For volume, test the logic in a few UI flows and push the numbers through the API, Apex or Data Loader. One of our insurance partners did the math: 2,000 premium combinations through the UI was over 66 hours for a single regression run. Nobody runs that. Prove the screen once, then validate the data with SOQL.

Who owns what: SI vs customer

Most implementation fights we hear about are really ownership fights. Settle them in the strategy.

The last row matters most. If the regression suite leaves with the SI, the customer is back to manual testing by the second Salesforce release.

Entry and exit criteria per phase

Write these as numbers. “Mostly stable” is not a criterion.

Tune the numbers to your risk. Just don’t leave them blank.

After go-live: regression for three releases a year

Here’s the part nobody budgets for. Go-live is the start of the testing bill, not the end.

Every sprint ships changes. Every Salesforce release changes the platform under you. In 2027 that’s Spring ‘27, Summer ‘27 and Winter ‘28, three full regression cycles on top of your own roadmap. Locators move. Components switch frameworks. Labels change. A suite tied to page structure breaks even when the feature works.

So the strategy needs three rhythms:

• Every deploy: the smoke suite. Minutes, automated, blocking.

• Every sprint: the regression suite for touched areas.

• Every Salesforce release: the full regression suite on preview sandboxes, weeks before production upgrades.

If you’re doing this by hand today, put a number on it. Our Salesforce regression testing cost calculator shows what manual regression costs per year, including the three seasonal releases. The number usually ends the “should we automate?” debate.

If your current scripts break every release, our free locator healer scores Playwright and Selenium locators for how well they survive Lightning changes.

If Agentforce is in scope

Agents need their own section in the strategy. An agent can give a polite answer and update the wrong record. Test what it did, not only what it said.

At minimum: a list of real user questions per topic, including rude, vague and off-topic ones. Multi-turn conversations, not just single questions. A check on the actions and data behind each answer. Our free Agentforce coverage planner builds that list in a format Agentforce Testing Center accepts, and shows what it can’t cover.

Where automation and TestZeus fit

You can run everything above with spreadsheets, scripts and very patient people. Plenty of teams do. Here’s where tooling earns its keep, with any vendor:

• Automate the smoke suite first, then regression. Leave exploratory testing and UAT judgment to humans.

• Pick automation that the customer team can maintain after the SI leaves.

• Make every important test check data, not just screens.

We built TestZeus for this job on Salesforce. You write tests in plain English or record them from the live app. A test can mix UI steps with API calls, Apex and SOQL checks. You can run as different user profiles. Runs scale out in parallel, and every failure comes with screenshots, video and a root cause. Test Blocks turn a working run into deterministic steps you can replay. For agents, it runs adversarial multi-turn tests with tool-call and SOQL checks. TestZeus is SOC 2 Type II and ISO 27001 certified, can mask data before it reaches an LLM, and runs on-prem if you need it.

Comparing options? Here’s our honest roundup of Salesforce test automation tools. We’re in it. So are tools we compete with.

FAQ

What is a test strategy for a Salesforce implementation?

A short document that decides scope, test types per phase, sandboxes, test data, roles, tools, and entry and exit criteria before testing starts. It’s written once in discovery or design. Per-release test plans follow from it.

What is the difference between a test strategy and a test plan?

The strategy answers how the whole program is tested and changes rarely. The test plan answers what gets tested in one release, by whom, and when. One strategy, many plans.

What types of testing does a Salesforce implementation need?

Apex unit tests, flow and component tests, functional, integration, data migration, security and permission, UAT, smoke and regression testing. Add performance testing when user or data volume is high.

Which Salesforce sandbox should we use for UAT?

A Full sandbox if you have one, because it copies all production data. A Partial Copy sandbox works for many programs. Developer sandboxes copy metadata only, so they’re a poor fit for UAT.

How many tests should a Salesforce smoke suite have?

Start with 20 to 40, built from the business’s top three processes, 5 to 10 tests each. Run them on every deploy. Grow the suite after it’s stable.

What should a Salesforce test strategy cover in 2027?

Everything in the template above, plus four 2027 items: regression windows for Spring ‘27, Summer ‘27 and Winter ‘28; a plan for integration and test logins affected by Salesforce’s authentication retirements; multi-turn testing for any Agentforce agent; and a risk ranking that decides which AI-generated test cases you actually keep.

How do we keep Salesforce tests working after go-live?

Run smoke tests on every deploy, regression for every sprint, and the full suite on preview sandboxes before each of Salesforce’s three yearly releases. Use stable locators or tools that don’t depend on page structure, and hand the suite to the customer team that will own it.

The takeaway

A Salesforce test strategy isn’t a document you write to tick a box in the SOW. It’s the decision of what not to test, written down early, so nobody has to guess at 2 a.m. on cutover night.

Write it in week one of your 2027 program. Keep it to three pages. Rank the risks. Map every test to a phase and a sandbox. Name the owners. Then build a small suite that runs forever.

Start with our free tools, or bring your top 10 test cases to a TestZeus demo and watch them run on your own sandbox.