91³Ô¹ÏÍø

Most Salesforce teams have some form of testing in place. Few have an actual strategy behind it. Testing suites tend to get built up piecemeal, one incident at a time, rather than planned as a cohesive whole.

That gap gets more expensive as your org grows, especially as AI accelerates how much code and configuration moves through it. This guide breaks down the types of Salesforce testing and shows how automating them is the route to keeping pace with your growing release volume, rather than falling behind it.

What is Salesforce test automation?

Test automation for Salesforce is a core part of modern Salesforce DevOps. It helps improve code quality and sets you up for rapid, reliable deployments. As Salesforce orgs grow more complex, automated testing is a baseline expectation for any team shipping changes regularly.

Rather than manually re-checking your org every time you release, test automation lets you configure a test once and have it run automatically, every time, against every change. Tests can flag anything from a broken integration to a failing trigger, well before an issue reaches the end user. And because it’s automated, it scales in a way manual checking never can — freeing up time for your team to focus on higher value tasks.

What types of testing are there in Salesforce?

Because of the complexity of the Salesforce platform, there are a variety of tests you need to consider and carry out to ensure your changes are ready to be shipped. It can be useful to think about testing in Salesforce in two different ways: what you’re testing, and when/why you’re testing it in the release cycle. Most teams only formalize the first, but mature governance means thinking about both.

Test types: what you’re testing

These are tests that require specific technical knowledge of what component or layer is being evaluated.

Unit testing: Down at code level, unit testing checks whether individual Apex components are working in isolation. Salesforce requires 75% Apex code coverage across the org before you can deploy to production, which is why unit testing is usually the first type of automated testing teams put in place. But coverage isn’t the same as quality. You could have 100% coverage and all tests could pass, but it won’t tell you about how your Apex components behave in production alongside Flows, validation rules or other automation, meaning bugs can still be missed.

Static code analysis: This isn’t a test in the traditional sense because no code runs. Instead, static analysis scans your codebase for governance and quality issues: hardcoded IDs, missing error handling, insecure SOQL, deprecated API usage. Catch these before deployment, and you get fewer surprises in code review and fewer preventable issues reaching production.

Functional testing: Functional testing checks whether your org behaves the way it’s meant to — feeding in inputs and checking the outputs against your functional requirements, rather than examining one specific layer of code.

Integration testing: This checks that your code and the other systems in your tech stack still work together once everything’s connected or if something is going to break the second you deploy.

API testing: Salesforce orgs rarely operate in isolation. Most enterprise implementations expose or consume APIs to connect with the rest of the tech stack. API testing checks that those endpoints return the right data, handle errors correctly, and hold up under the request volume your integrations actually generate.

UI testing: User interface (UI) testing checks how the application behaves when a user actually interacts with it, such as clicking buttons, filling in fields, and navigating Flows. It’s the layer closest to what your end users experience. And it’s also the layer most teams still test manually, because UI test scripts have traditionally required specialist skills to write and need significant, ongoing time investment in maintenance and upkeep when Salesforce releases break locators.

Test stages: when you’re testing

This is about timing: at what point in your release cycle does a check happen (these can utilize any of the technical tools from the category above).

Regression testing: Every release, you’re not just testing what’s new — you’re re-testing everything that was already working, to confirm it still is. A regression is something that used to work and doesn’t anymore, and regression testing is how you catch it before your users do.

UAT/acceptance testing: User acceptance testing is a final stage where real users check that a change meets their needs. Not just whether it technically works, but whether it works the way they expect.

Deployment validations: Before you deploy for real, a validation-only deployment tells you whether the deployment would succeed, without actually making the change. It’s your last checkpoint before code and config hit an environment — and a far cheaper place to catch a failure than after go-live.

Smoke testing: Once a deployment lands, smoke testing runs a small set of high-priority checks to confirm nothing’s obviously broken. It’s the equivalent of turning the key and checking the engine starts before you drive off. It’s fast by design. It’s not there to catch everything, just to catch the deployment-ending stuff quickly.

Specialist testing: performance and security

These test a quality attribute rather than a component (non-functional testing), and can run at multiple stages depending on what you’re trying to catch.

Load and performance testing: Load testing measures how your Salesforce org holds up against the expected demand from users and under increased traffic. This matters most ahead of predictable spikes — a product launch, a seasonal peak, a new integration going live — where discovering your org’s limits in production isn’t an option.

Pentesting: Penetration testing of your customizations (not the core Salesforce platform, which Salesforce itself secures) simulates an attacker probing your org for vulnerabilities in custom code, exposed endpoints, and misconfigured sharing rules. For enterprise teams under compliance pressure, this isn’t optional. It’s part of proving your custom build is as secure as the platform it sits on.

Advantages of Salesforce test automation

Continuous testing not only strengthens the state of your existing environments, but it also creates a foundation to deploy successfully too. There are many benefits of using automated Salesforce testing:

• Keeping pace with AI-driven change: AI tools are helping teams generate Salesforce code and configuration faster than ever, which means more changes moving through your org, more often. Automated testing is what lets that increased throughput scale safely. Without it, you’re shipping faster with less visibility into what might break.

• Avoid dropping test coverage: Unit tests determine your Apex code coverage, which Salesforce requires to sit above 75% before deployment. Automating them to run daily and alert you when coverage drops means you fix the gap early, before it blocks a release.

• Early bug detection: Shifting left will set you up to find and fix bugs and code errors early in your development process. Catching these early decreases the likelihood of finding a severe issue later on down the pipeline, where it’s more expensive and time-consuming to fix.

• Reliable deployments: Testing and validating deployments before they’re released to production makes for a smoother release day, meaning you can deliver to users on the expected timeline and build business trust.

• Time and cost savings: It requires a lot of effort to manually check every corner of the Salesforce application, the integrations, and all of your code and configuration. Having quick, repeatable and reliable ways to test frees up the team to focus on designing and building changes that add value for end users, rather than sinking time into avoidable rework. This translates to huge ROI for the wider business, as testing becomes more efficient and team members are able to focus on adding value elsewhere.

• Reduced human errors: Taking away the human element from manual and repetitive tasks means there’s less chance of human errors creeping into the org.

Challenges of Salesforce test automation

Salesforce is constantly expanding and improving functionality. But these enhancements can also increase complexity, meaning your automated tests can hit challenges along the way:

• Test scripts require time and effort: The original scripts can take a lot of time, patience and expertise to get right, so being methodical and making sure they’re accurate can save you a lot of time in the long run. They also require maintenance, which is a time commitment most teams don’t realise they need to plan for.

• Dynamic elements: Each environment is unique, with different fields, objects, and integrations. The elements you’re testing against can easily shift out from under you. A Salesforce release moves a locator, a component sits behind shadow DOM your script can’t reach, or the same button lands in a different place depending on the user’s profile. Each of these mean automated tests end up needing regular maintenance or even rebuilding from scratch.

• Frequent updates: Salesforce is constantly rolling out upgrades and new features which can throw your tests into a spin more frequently than you’d like. To make testing work well for you, it’s worth investing time into a tried and tested method to keep on top of repairing and improving the test scripts. To complicate matters, many Salesforce tests are run using a snapshot of the org, which means that the data can already be out of date when you see the results.

• Team lacking experience: The Salesforce ‘clicks not code’ style of development is accessible to admins and developers alike, but this doesn’t necessarily transfer into the testing side of things. Scripts will need to be written by team members with a certain skill set. There are a number of test automation tools out there, but choosing the right one and successfully implementing it requires some knowledge of testing best practices.

Is manual testing still necessary?

AAfter reading the benefits of automated testing, you might think the answer to this question is ‘no’ – but there’s still a time and place for manual testing. Though manual testing doesn’t work at scale, this doesn’t mean you should write off the need for human intervention entirely. For example, UAT is reliant on how your user feels when using your application. And because it’s subjective and dependent on human interaction and emotion, these tests will always have a better outcome with a human tester.

As AI increases how much code and configuration moves through your org, the only way to reliably test the volume of changes being made is with test automation. But this doesn’t completely remove the need for human oversight and input.

How 91³Ô¹ÏÍø supports Salesforce test automation

Knowing the types and stages of testing is one thing, building the infrastructure to run them consistently, at scale, is another. 91³Ô¹ÏÍø’s testing solutions span across your release cycle, including what happens after code ships.

Unit testing: 91³Ô¹ÏÍø runs your Apex unit tests automatically, on a schedule you set, tracking pass/fail results and code coverage over time. You can select your minimum coverage threshold and get notified the moment your coverage drops, rather than finding out on release day when you can’t deploy critical changes.

UI testing: 91³Ô¹ÏÍø’s Automated Testing doesn’t need any scripts. You can build a test by clicking through a workflow on screen while 91³Ô¹ÏÍø records it, or describing what you need in plain language and let the 91³Ô¹ÏÍø Agent generate the test. Tests run as real users, with real profiles and permissions, so you’re validating actual user journeys that your business depends on.

Code reviews: Where unit and UI tests check that things work, Code Reviews checks that they’re built well. It scans your entire Salesforce configuration — covering Apex, Flows, Lightning components, permission sets, and metadata — against a configurable ruleset, with autofixes for common issues and quality gates that stop non-compliant changes before they reach production.

Observability: Testing tells you a change is safe before it ships. Observability tells you what’s actually happening once it’s live. 91³Ô¹ÏÍø monitors Flow and Apex errors in production, as well as org limits, and alerts your team when something breaks while connecting failures back to the deployment that caused them. That means root cause analysis takes minutes, not a support ticket and a guessing game. It’s the piece that closes the loop: testing reduces the likelihood of breaking changes, observability catches what gets through anyway.

Reliable test automation for Salesforce

A testing and test automation strategy is only as good as the platform running it. Bringing unit testing, UI testing, code reviews, and observability together, rather than having separate tools, is what lets your org and your release volume scale without compromising quality, security or governance.

Ready to see how 91³Ô¹ÏÍø saves your team time while enabling faster throughput of quality changes? Start a , or book a demo to walk through it with the team.