# Why Salesforce Automated Testing Still Leaves You Exposed Before a Major Release

> Salesforce has excellent automated testing tools. Apex tests, Selenium frameworks, Provar, Copado — all valuable. And none of them will catch what a specialist UAT team finds before go-live.

- Published: 2025-04-28
- Category: Salesforce UAT
- Reading time: 7 min read

Canonical page: [https://bugwolf.com/post/salesforce-automated-testing](https://bugwolf.com/post/salesforce-automated-testing)

Salesforce is one of the best-tested enterprise platforms in existence. Apex unit tests are a deployment requirement. The ecosystem of testing tools — Provar, Copado, Selenium-based frameworks, and Salesforce's own testing infrastructure — is mature and capable. Development teams building on Salesforce have more automated testing support than almost any other enterprise platform.

And yet Salesforce releases continue to cause production incidents at enterprise organisations. The pattern is consistent: automated testing passed, something unexpected happened in production.

The explanation isn't that automated testing is bad. It's that automated testing and UAT are solving different problems.

## What automated Salesforce testing actually validates

Apex unit tests verify that code executes correctly against its own logic. They don't test the org — they test the code. When you deploy with 75% code coverage, you've confirmed that three-quarters of your Apex logic runs without erroring. You haven't confirmed that your users can do their jobs.

End-to-end testing tools like Provar and Selenium-based frameworks go further — they can simulate user journeys through the UI. These are valuable. Their limitations are:

- They test the journeys they were programmed to test — and Salesforce orgs at enterprise scale have more permutations than any test suite covers
- They run against a test environment that may not perfectly mirror your production org's configuration, data, and active users
- They can't make judgment calls — if an unexpected result appears, automated testing records it as a pass or fail; a human tester investigates it
- They don't account for the institutional context that shapes how real users interact with your org

## Where Salesforce releases fail in production

After thirteen years of running UAT on enterprise Salesforce implementations, the failure patterns are recognisable. The issues that make it to production are almost never caught by automated testing — they're the ones that require context to find.

### Permission set conflicts across profiles

Salesforce's security model layers profiles, permission sets, and permission set groups. An automated test verifies that a named profile has access to an object. What it doesn't catch: a permission set assigned to a subset of users in that profile that creates a conflict, or a new permission set that silently overrides a restriction that compliance depends on.

UAT catches this because testers log in as users — not as system administrators — and attempt to do their actual jobs. The conflict surfaces when a compliance-sensitive field appears editable to someone who shouldn't be able to touch it.

### Data migration integrity at the record level

Data migration validation in automated testing compares field-level outputs against expected values. It doesn't validate whether the migrated data makes business sense. A contact record with a null phone field passes validation. A contact record associated to the wrong account — because the matching logic handled a naming convention inconsistency incorrectly — passes validation too. Neither is found until a sales rep tries to use it.

### Flow and Process Builder interactions

Complex Salesforce orgs accumulate automation over years. Flows trigger on record changes. Process Builder rules fire on field updates. Apex triggers run on DML operations. These interact with each other in ways that are difficult to anticipate and nearly impossible to fully model in an automated test suite.

The interaction that causes a production incident is usually one where a new flow, introduced in the current release, fires alongside an existing automation and produces an unexpected result — a field that gets overwritten, a notification that fires twice, a record lock that prevents a subsequent update. UAT finds these because testers are running end-to-end scenarios, not isolated component tests.

### Cross-browser and cross-device behaviour in Lightning

Lightning Experience renders differently across browsers, and the difference matters at scale. A custom LWC component that works perfectly in Chrome may render incorrectly in Safari — which is used by a significant portion of most enterprise sales teams. Automated testing against a single browser misses this entirely.

UAT covers the actual browser and device distribution of your user population — because testers are asked to use the environment your users actually work in.

## Complementing automated testing with specialist UAT

The right answer isn't to choose between automated testing and UAT. Both have a place in a Salesforce delivery programme. The question is what each layer is responsible for.

Automated testing covers code correctness, regression safety, and scripted happy-path validation at speed and scale. UAT covers business fitness, user workflow coherence, edge case discovery, and the permission, data, and interaction scenarios that automated tests weren't written to find.

Organisations that invest in specialist Salesforce UAT — testers with genuine platform knowledge and enterprise context — consistently reach go-live with fewer unknowns. The issues that remain are manageable. The ones that would have made it to production don't.

That's the return on specialist UAT. Not a perfect system — no release is without risk. A system where the risks are understood and managed before they become incidents.

## Frequently asked questions

### What do Apex unit tests actually validate in a Salesforce release?

Apex unit tests verify that your code executes correctly against its own logic — they test the code, not the org. Meeting the 75% code coverage deployment requirement confirms that three-quarters of your Apex logic runs without erroring. It does not confirm that your users can complete their actual workflows, that permission sets are configured correctly, or that automation interactions produce the right business outcomes.

### Why does Salesforce automated testing still leave gaps before go-live?

Automated testing tools like Provar and Selenium-based frameworks test the journeys they were programmed to test — and enterprise Salesforce orgs have more permutations than any test suite covers. They run against environments that may not mirror your production org's configuration, data, and active users. They can't make judgment calls about unexpected results, and they don't account for the institutional context that shapes how real users interact with your org.

### What types of issues does Salesforce UAT find that automated testing misses?

Specialist Salesforce UAT consistently surfaces four categories of issues automated testing doesn't catch: permission set conflicts that expose compliance-sensitive fields to the wrong users; data migration integrity failures where records are technically valid but associated to the wrong accounts or missing business-critical values; Flow and Process Builder interactions where new automation fires alongside existing automation and produces unexpected results; and cross-browser rendering issues in Lightning Experience that only appear in the browsers your sales team actually uses.

### When is UAT needed if Salesforce already has strong automated testing tools?

UAT is needed on every significant Salesforce release because automated testing and UAT solve different problems. Automated testing covers code correctness and regression safety. UAT covers business fitness — whether the system supports the way your users actually work, whether migrated data makes business sense, and whether the interaction between new and existing automation produces outcomes your business can operate with. The two layers are complementary, not substitutes.

### How do Flow and Process Builder interactions cause Salesforce production incidents?

Complex Salesforce orgs accumulate automation over years — flows that trigger on record changes, Process Builder rules that fire on field updates, Apex triggers that run on DML operations. A new flow introduced in a release can fire alongside existing automation and produce an unexpected result: a field that gets overwritten, a notification that fires twice, or a record lock that prevents a subsequent update. These interactions are nearly impossible to fully model in automated tests but surface quickly during end-to-end UAT scenarios.

## Related Bugwolf resources

- [Salesforce UAT Services](https://bugwolf.com/platform/salesforce-uat/index.md)
- [Managed UAT Overview](https://bugwolf.com/services/index.md)

## Talk to Bugwolf

### Salesforce release coming up?

Bugwolf's Salesforce UAT specialists validate your CRM before users do. Talk to Ash — 13 years of enterprise UAT, zero failed go-lives.

- [Contact Bugwolf](https://bugwolf.com/contact/index.md): Talk directly with Ash Conway about enterprise UAT