In short: In Salesforce testing, tests break most often after small changes in your own org. The three big releases a year are only part of the story. A renamed field, a new validation rule or a screen update can break flows and test scripts further down the line. You keep regression under control by testing business logic below the screen, handling integrations on purpose, and running the regression set after every change.

Most teams prepare well for the Spring, Summer and Winter releases. They read the release notes, test in a sandbox and plan a test round. Then, in a quiet week in between, an admin renames a field or adds a new rule. Suddenly half the automated tests turn red. Nobody changed the tests. The org changed underneath them.

Why do Salesforce tests break after a small change?

Salesforce tests break after small changes because everything in an org hangs together. A field is used in a flow, and the flow updates a record. That record feeds a report and a link to another system. A test script follows that whole path through the screen. Change one part and the effect shows up somewhere else. In the projects where our Salesforce testers look after automated tests, four causes come back again and again:

• Small changes with big ripples. Renaming a field or changing a rule makes flows and scripts fail further down, often far from the change itself.
• Integrations that answer late. Links with marketing tools, product data systems or chat tools cause timing problems. Limits and delays make tests fail now and then, and those failures are hard to repeat.
• Screen updates. When Salesforce changes the page structure, for example with Lightning updates, the locators that tell a script where to click need maintenance.
• Results nobody reads. When test reports don’t show what the business wants to see, failures get noticed late.

These problems show up in good teams too. They come from testing a system that keeps changing mostly through its screens.

Which Salesforce changes need a regression run?

Every change that touches data, logic or access needs a regression run, also outside the release season. A simple rule helps: if an admin can change it in Setup, it can break a test. In practice, plan a run after changes to the items below.

• fields, picklist values and page layouts.
• validation rules and required fields.
• flows, approval processes and Apex code.
• profiles, permission sets and sharing rules.
• integrations, connected apps and their settings.
• the three yearly releases, tested in a preview sandbox first.

The release season has its own checklist for testing before a Salesforce release. In our experience, though, much of the breakage happens in the months between releases, after your own changes.

How do you make Salesforce test automation less fragile?

You make Salesforce test automation less fragile by testing each rule at the lowest level that can prove it. Keep the screen tests for what users actually do. Four measures make the biggest difference:

1. Test logic below the screen. Salesforce has built-in flow tests for record-triggered and autolaunched flows, and Apex has its own unit tests. Business rules tested there run fast, and they don’t care where a button sits. The same idea works for integrations through the API.
2. Use stable locators. Some scripts find fields by their Salesforce metadata, not by their place on the page. Those survive most screen changes. Tools built for Salesforce can do this. Plain browser scripts often can’t.
3. Handle integrations on purpose. Where a test isn’t about the integration, replace it with a stand-in. Where it is, wait for a specific result instead of a fixed number of seconds. Keep those tests in a separate group, so one slow link doesn’t turn the whole run red.
4. Control your test data. Tests that create their own records and clean up afterwards don’t fail because someone changed a record in the sandbox.

Where does Provar fit?

Provar is a test tool built just for Salesforce, and Nekst works with it as a partner. Its main strength is that it reads Salesforce metadata, so its tests break less often when a page changes than generic browser scripts do. That doesn’t make maintenance disappear. Our testers still update tests after bigger screen changes, and integrations still need the care described above. Provar’s own reports don’t always give the business the view it wants, so we often add a short summary per release. The Provar documentation is a good place to see how it works. Other tools can work too. Who keeps the tests in shape matters more than the tool.

What this means for your team

A Salesforce test set doesn’t stay reliable on its own. Someone needs to know which admin changes are coming and run the tests after each one. Someone fixes what breaks and tells the business what the results mean. In many teams that job falls between the admins, the developers and the testers, so it doesn’t happen. A short agreement already helps. Admins post changes in a shared channel, and every change starts the test run.

We’ve done this kind of work on large projects, such as the global Salesforce rollout at IMCD. There we set up test scenarios, ran many test cycles and helped with the data migration. With Test Automation as a Service, we keep your Salesforce regression suite running alongside your team, after every change and every release. That way your admins can keep improving the org without breaking it. Read more on our Salesforce Quality Solutions page.

Frequently asked questions

What are the different types of testing in Salesforce?

The main types are unit tests for Apex code and flow tests for automation. Then come tests of business processes and of links with other systems. Add regression tests after changes and releases, and acceptance tests with the people who use Salesforce every day.

How often should you run Salesforce regression tests?

After every change that touches data, logic or access, and before each of the three yearly releases. If that sounds like a lot, it’s a sign the tests should be automated and run in a pipeline.

Can you automate Salesforce flow testing?

Yes. Salesforce has built-in flow tests for record-triggered and autolaunched flows, and they can run as part of your regression and deployment process. Screen flows still need tests that go through the user interface.

Is Provar the only option for Salesforce test automation?

No. Provar is built for Salesforce and handles its metadata well, but other tools can work too. Choose based on your team’s skills, your integrations and who will maintain the tests.