In short: Salesforce release testing means checking your own processes, code and integrations on the new release before it reaches production. Winter ’27 has been in preview sandboxes since late August, and production orgs follow about six weeks after that. Run your regression tests in a preview sandbox and fix what breaks before your upgrade date.

Three times a year, Salesforce upgrades every org to a new release. You don’t pick the date, and you can’t skip it. Winter ’27 is the next one. Salesforce tests its own release. Your custom fields, Flows, Apex code and integrations are yours to test, and that is where Salesforce testing pays off.

When does Winter ’27 reach your org?

Winter ’27 reaches your org in two steps. First the sandboxes. According to Salesforce’s sandbox preview instructions, preview instances moved to Winter ’27 on 28 and 29 August 2026. Sandboxes that stayed on Summer ’26 move on 9 or 10 October 2026. Then production. Salesforce says production instances are upgraded around six weeks after the sandbox preview starts. The exact date depends on your instance, so look it up on Salesforce Trust, the official status site. Salesforce plans upgrades at quiet times and at weekends. It also asks you not to plan admin work in that window. Every release follows the same rhythm, with Spring in February, Summer in June and Winter in October, so you can plan for it.

What should you test before a Salesforce release?

Test the parts of your org that Salesforce didn’t build. That is where a platform change meets your own changes. It is also where a release can break something that nobody notices for days. Start with what would hurt most if it stopped working. Then work down this list.

• Key business flows: creating and converting a lead, closing an opportunity, handling a case. Test them from start to finish with realistic data.
• Your own code and automation: Apex, Flows, validation rules and custom page parts, especially where they touch standard objects.
• Integrations and scheduled jobs: data to and from your ERP, marketing tools or website. Nobody watches these every day, so they break quietly.
• Permissions: profiles, permission sets and sharing rules. A release can change what a user role is allowed to see.
• Reports and dashboards: the ones your managers use to make decisions.
• Release updates: changes Salesforce turns on for everyone on a set date. Find them in Setup under Release Updates, switch them on in a sandbox first and test there. The Winter ’27 release notes list what changes.

How do you use the sandbox preview?

The sandbox preview gives you a copy of your org on the new release, weeks before production gets it. That makes it the best place to run your tests. For Winter ’27, a sandbox had to be created or refreshed by 27 August 2026 to join. Salesforce publishes that cut-off date before every release. Use the preview in five steps.

1. Keep at least one sandbox on the preview for every release. Put the cut-off date in your calendar.
2. Run the same regression tests in the preview sandbox and in a sandbox on the current release.
3. Compare the results. A test that fails only on the preview points to a change in the release. A test that fails in both points to your own org.
4. Fix or adapt what breaks, then test again before your production date.
5. Keep the results as the start of your checklist for the next release.

Missed the preview this time? Then test straight after the upgrade, starting with the flows that hurt most, and plan the preview for Spring ’27.

Why automate Salesforce regression tests?

Automate them because the work comes back three times a year, on top of every change your own team makes. A manual round of Salesforce testing means logging in as different users, clicking through the key processes and checking the data. With many roles and processes, that can take days. Automated tests run the same checks every night and after every release. You know within hours if something broke. Salesforce builds its pages on the fly and changes them between releases. That makes general test tools fragile on Salesforce. Tools built for the platform, such as Provar, read how Salesforce describes each page and cope better with those changes. We are a Provar partner. The same rule applies to any tool: pick one that understands Salesforce. Keep the suite small enough that someone looks after it.

Automation also helps with the part people tend to skip. After a busy release week, nobody wants to click through permission checks for ten user roles, so those checks are the first to be skipped. Automated tests run them every time. One risk we see in many teams applies to Salesforce too: quality depends on one or two people who know how everything really works. Then you can only test a release properly when they are available. An automated suite takes that dependency away.

What this means for your team

Look up your production upgrade date on Salesforce Trust today. Then write down the five flows that must work on the Monday after the upgrade, and test them in a preview sandbox. If you already have automated tests, run them there. If you don’t, this release is a good moment to start with those five.

Nekst tests Salesforce releases alongside your admins and developers, and your team decides what goes live. For IMCD’s global Salesforce implementation, we set up the test scenarios, ran many test cycles and helped with the data migration, on an ambitious timeline. Marco Vleeschdraager of IMCD put it like this: “Having Nekst IT on board gave relief and reassurance to the project team”. With Salesforce Quality Solutions, you get testers who know the platform. With Test Automation as a Service, your regression tests run every night, release after release, and we keep them running.

Frequently asked questions

How often does Salesforce release updates?

Salesforce has three major releases a year: Spring in February, Summer in June and Winter in October, according to its upgrade release schedule FAQ. Every org is upgraded automatically, so each release needs a round of testing.

What is Salesforce testing?

Salesforce testing checks that your org still does what your business needs. It covers your processes, custom code, automation, integrations and permissions. You test after your own changes and before each of the three seasonal releases.

Is Salesforce testing easy?

Starting is easy: click through your key processes in a sandbox. It gets harder as your org grows. Dynamic pages, many user roles and integrations make manual testing slow, and general test tools can break when Salesforce changes its pages.

What are the best tools for Salesforce testing?

That depends on your team and your org. Salesforce-specific tools such as Provar handle the platform’s dynamic pages well. General tools like Selenium or Playwright can work, but they need more upkeep on Salesforce. For Apex code, Salesforce has its own unit tests, which your developers already need to deploy code.