You cut manual Salesforce regression by running fewer tests, at the right time, in the right place. Split the suite into tiers so only the release run is full. Delete the cases that no longer earn their keep. Move each check to the cheapest layer that can catch it. Fix test data so a case takes minutes, not a quarter of an hour. Then automate your top business flows, in that order.
Most teams start with that last step. That is why the hours barely move. In the worked example below, running tiers removes more hours than automation does.
Why regression keeps growing on Salesforce
Salesforce upgrades every org three times a year. Your team ships every sprint. On two-week sprints that is 26 of your own cycles, plus Spring, Summer and Winter. That’s 29 regression cycles a year before anyone builds a new feature. The Spring ‘27 dates are already set.
Most of that work is still done by hand. In Copado’s survey of more than 275 Salesforce professionals (reported in 2022), 84% of teams relied at least partly on manual testing. 41% said they did not have time to test every change before a release. Gearset’s 2025 State of Salesforce DevOps report (464 respondents) found that bugs caused a Salesforce outage at 21% of businesses in 2024.
Our calls say the same. Between July 30 and October 30, 2026, about 13 different prospects told us manual regression was slowing their releases. Some of the numbers they shared, with names removed:
Two testers running 200 to 300 manual cases: 3 to 4 days every sprint.
One team inside a large, multi-org Salesforce estate: 80 to 100 hours a month on regression.
One ISV: about 2,600 test cases, 90 to 95% run by hand. (More in our ISV testing post.)
One business flow, run end to end by hand: 16 hours.
One QA engineer: 1.5 hours a day fixing Playwright locators after UI changes.
Where the hours actually go
Manual regression is four numbers multiplied together: cases × share run by hand × minutes per case × cycles a year. Every lever in this post shrinks one of them. Our regression cost calculator uses the same formula, with the math shown.
Take a common setup. 250 cases, 70% run by hand, 15 minutes each, two-week sprints plus the three Salesforce releases. That is 175 hand cases, about 44 hours per cycle, and 1,269 hours a year.
This is a worked example, not a benchmark. We assumed each sprint touches about a third of the suite, pruned 15% of cases, cut setup from 15 to 11 minutes per case, and automated the 40% of hand cases that run most. Automation is not free, so we added back 2 hours a week of upkeep. The result is about 294 hours a year, down from 1,269.
Look at the order. Running tiers removes 739 hours. Automation removes 132. Tiering wins because it shrinks the multiplier that every other number sits on.
1. Run tiers, not the full suite every time
The full suite is for Salesforce releases and big launches. Everything else gets a smaller slice.
Tier | When and where it runs | What is in it |
|---|---|---|
Smoke | Every deploy, in every sandbox and in production after the deploy | 20 to 40 cases: log in, create the core record, finish the money path |
Sprint regression | Every sprint, in the QA or UAT sandbox | Smoke, plus cases tagged to the objects and flows the sprint changed |
Full regression | Every Salesforce release and major launch, on a preview sandbox before your upgrade weekend | Every case that survived pruning |
Prune review | Every quarter, in your test manager or sheet | Cases that never fail, repeat other cases, or cover retired features |
The sprint tier only works if every case is tagged with the objects, flows and features it touches. Then the components in a deploy tell you which tags to run.
Salesforce is building the same idea for Apex. The RunRelevantTests test level, in beta since Spring ‘26, runs only the Apex tests relevant to what you deploy. Salesforce says not to put the beta into production pipelines yet. The principle still applies to your UI suite today.
2. Prune the suite every quarter
Suites only grow. Nobody deletes a test case, because deleting feels risky. So teams keep re-running checks for a page layout that was retired two years ago.
Score each case on two questions. What breaks for the business if it fails? How often does that area change? Then clean up:
Merge cases that repeat the same steps with different data into one data-driven case.
Delete cases for features nobody uses. Check field and report usage first.
Move cases that have not failed in a year to the release-only tier.
Merge cases that share the same first ten setup steps. Repeated setup is where hours hide.
We used 15% in the example. Treat it as a starting guess for a suite that has never been pruned, not a promise.
3. Test each check at the cheapest layer
A lot of manual regression is people clicking through screens to check something the database could answer in a second.
Two layers already exist in every org. To deploy Apex to production, unit tests must cover at least 75% of your Apex code, and all of them must pass. Flow Builder has flow tests for create and update record-triggered flows. Use both for logic before you write a UI test for it.
Check data directly. One of our insurance partners did the math on a premium engine: 2,000 combinations through the UI, at about 2 minutes each, is over 66 hours for a single regression run. Prove the screen once. Then push the numbers through the API and check them with SOQL. The full story is in our SI partner post.
Keep UI tests for what only the UI can prove: a real user, with a real profile, finishing a real business flow. Run them as that user, not as an admin. Admins see fields and buttons that sales reps never do. We wrote about this admin bias in Salesforce testing.
4. Fix test data before you automate anything
Minutes per case include logging in, finding or creating test data, and recording the result. On most Salesforce orgs, the data part is the biggest chunk.
Keep a seed script that loads the accounts, contacts, products and price books your cases need. Run it after every sandbox refresh.
Give each test its own records with a unique run ID, so one tester’s edits do not break another’s case. Shared records are also a top cause of flaky Salesforce tests.
Store a test login per profile, not one shared admin login.
Write the expected result next to each case, so checking is a comparison, not a judgment call.
In the example, cutting setup from 15 to 11 minutes per case removed 120 hours a year. No tool needed.
5. Automate the top flows, in order
Now automate. Start with the smoke tier, then the “automate and run every sprint” box. Inside each box, rank cases by how often they run times how long they take by hand.
Pick an approach that survives Salesforce’s UI changes. Tests tied to generated IDs, XPath into Lightning components or page structure break three times a year even when the feature works. We covered the causes in why Salesforce UI tests break. Use labels and roles, and keep flaky tests out of the run that blocks releases.
Budget for upkeep. The example adds 2 hours a week. Teams with brittle locators report far more. One QA engineer spent 1.5 hours a day on it. Another team spent 5 person-days a month keeping a stable Playwright suite’s data and scripts working. If you are weighing building your own, read the real cost of an AI-powered Playwright system.
6. Use the preview window
Salesforce upgrades preview sandboxes before production. For Spring ‘27, preview sandboxes move on January 9, 2027, and production follows on January 16, February 6 and February 20. Look up your instance on our release calendar.
Run the full tier on the preview sandbox in the first week. Sort each failure into “Salesforce changed something” or “real bug”. Fix the tests before your upgrade weekend, not after it.
What not to cut
Exploratory testing on new features. Scripts only find the bugs you predicted.
UAT sign-off. Business owners still need to see their process work. Our UAT test plan template helps.
Permission and sharing checks run as real users.
The full run before each Salesforce release.
A 30-day plan
Week 1, count. Export the suite. Tag each case with its area and owner. Time ten cases by hand. Put the numbers in the calculator so you have a baseline.
Week 2, tier and prune. Pick 20 to 40 smoke cases. Sort the rest into the four boxes. Merge or delete what you can.
Week 3, move checks down. Turn logic checks into Apex or flow tests and data checks into SOQL. Write the seed data script.
Week 4, automate the smoke tier. Run it on every deploy. Compare this month’s regression hours with week 1.
Where TestZeus fits
TestZeus runs Salesforce tests written in plain English or Gherkin, or recorded by clicking through your org with Test Blocks. One test can mix UI steps, API calls and SOQL checks, so you prove the screen once and check the data underneath. Tests can log in as different profiles, and runs scale out in parallel.
It will not decide which cases to delete or which tier a case belongs in. That is the work above, and it pays off with any tool.
FAQ
How much time does manual Salesforce regression take?
It depends on suite size, how much runs by hand and how often you release. A 250-case suite with 70% run by hand at 15 minutes a case, on two-week sprints plus three Salesforce releases, comes to about 1,269 hours a year. Teams we talk to report anywhere from 2 days to 2 weeks per release cycle.
What is the difference between smoke testing and regression testing?
A smoke test is a small, fast check that the core of the app still works after a deploy. Regression testing is the deeper check that existing features still work after a change. On Salesforce, run smoke on every deploy and the full regression before each seasonal release.
What should be in a Salesforce smoke test suite?
20 to 40 cases built from your top business processes: log in as each key profile, create the core record, and finish the money path, such as quote to order or case to resolution.
Can you automate all Salesforce regression testing?
No, and you should not try. Automate the repetitive, high-run cases. Keep people on exploratory testing, UAT sign-off and anything that needs judgment.
How often should we run full regression on Salesforce?
Before each of Salesforce’s three yearly releases, on a preview sandbox, and before any major launch of your own. Between those, run smoke and the sprint tier.
// Start testing //
