Solid Testing Strategies for Salesforce Releases

As software engineers, we live in a dependency-driven world. Whether they are libraries, open-source code, or frameworks, these dependencies often provide the boilerplate functionality, integrations with other platforms, and tooling that make our jobs a little easier.

But of course, one of the burdens of this dependency-driven world is that we are now at the mercy of our dependencies’ updates and schedules. Especially when we’ve added our own customizations and integrations on top.

One common dependency that I (and likely you) have crossed paths with is Salesforce. If Salesforce is part of your ecosystem, you’ve likely added a few of those customizations and integrations. And you’ve likely faced the problem of managing your customizations and integrations when Salesforce issues updates.

In this article, I want to look at how you can help ensure that Salesforce updates don’t lead to downtime in your app.

About Salesforce Seasonal Releases

Salesforce issues updates on an established schedule. Currently, Salesforce targets spring (February), summer (June), and winter (October) releases. 

Along with these seasonal updates, of course, comes teams scrambling to update their own applications and tests in time for the releases. Which can introduce significant risk.

Potential Areas of Risk

Let’s look in detail at three potential areas of risk:

• User interface (UI) updates

• Applications built on top of Salesforce

• Deprecated APIs

User interface (UI) updates

At first glance, teams might downplay the impact of UI updates. However, these changes can become an issue when published instructions are no longer valid or (even worse) functional. In my experience, I have seen challenges from trivial UI changes such as reordering of a menu structure. 

Applications built on top of Salesforce

If you’ve built your solution on top of Salesforce, you’re also at risk. You’re at the mercy of the platform and have no seat at the decision-making table for updates that could break the consuming functionality. 

An example is when the Apex programming code is used to extend the value of the Salesforce platform. As the language matures, there is always the potential for breaking changes to be introduced.

Deprecated APIs

When a team uses Salesforce APIs, they are required to adopt a specific version of the API which often defaults to the most recent version. Over time, that choice remains static and does not update with the seasonal releases, which is actually by design. However, eventually those versions become deprecated and are subsequently removed. 

Imagine being woken up due to an incident because the API version you are using is no longer available.

Failure to perform pre-release validation can lead to latency concerns (if not high-severity incidents) which not only impacts organizations in the short term, but in the long term too. Each of the three issues above has the potential to put enterprises in an unfavorable position.

Tips to Mitigate Areas of Risk

Now let’s look at some tips on how to mitigate the above areas of risk:

• Automated testing, including end-to-end tests

• Stay in line with Salesforce best practices

• Full suite of test coverage

• Use of isolated test data

Automated testing, including end-to-end tests

Teams should make sure to spend the necessary time to automate the testing process. Taking this approach removes the toil associated with trying to remember to run the tests and makes testing part of the development lifecycle. This automation should include some form of regression or end-to-end tests which are executed at least one time before attempting a production release.

While it is possible to introduce a process to copy production data into a test environment (obfuscating sensitive data), this isn’t typically the best approach. A better approach is to identify scenarios that should be validated and create those situations exclusively for the tests. Taking this approach allows teams to be 100% in control of their data so that only the pre-release code is getting tested.

Stay in line with Salesforce best practices

When an organization adopts Salesforce, this should be viewed as an “all-in” mission for the enterprise. After all, Salesforce is now one of that organization’s key business partners. Subsequently, the organization should not only be in tune with Salesforce’s roadmap, but they should also make sure feature teams are always implementing the best practices published by Salesforce. Salesforce Trailhead is an interactive example, complete with a built-in test interface.

Full suite of test coverage

Teams should be of the mindset that test coverage is equally important as the production code that will be deployed. While Salesforce requires 75% code coverage (for Apex code) to deploy code to production instances, teams should instead strive for 100% coverage across the board.

Any gaps increase the chance that something will impact your customers. It’s important to remember that the tests should be easy to maintain and focused on the smallest grain of functionality possible. The suite of tests should cover any customizations made to the platform, especially UI changes.

Use of isolated test data

Finally, while test data can often be mocked (or included in the tests themselves), this is not always an option for end-to-end tests. One challenge teams face is trying to figure out “what” data should be used. 

By adopting these tips, teams will find themselves in a far better position for a successful seasonal release to the Salesforce platform.

AI-Powered Salesforce Testing

So far, I’ve identified risks that can surface from a lack of pre-release validation. I’ve also provided tips to mitigate those risks. But what I haven’t provided is a description of “how” this mitigation can actually happen.

In 2024, I published the “Why You Need to Shift Left With Mobile Testing” article which focused on the Tosca product by Tricentis. Since I wasn’t quite sure how to do all of this myself, I thought I would check to see what options are available from Tricentis for Salesforce test automation. 

That’s when I noticed the Testim Salesforce product, which provides the ability to mitigate the risks associated with leveraging the Salesforce platform:

• Offers a no-code approach to testing your Salesforce implementation, but also allows for Apex and JavaScript code to be used as needed.

• Designed for a wide realm of consuming actors and designed for software engineers.

• Architected using a scalable-first approach, growing to match your implementation's test expectations.

• Includes pre-built test steps to foster creation of test suites. When needed, the no-code approach allows actors to record their tests by using their applications.

• The Testim Salesforce product embraces AI as part of its base product. Under the hood are locators that go beyond basic Apex-based unit tests and use Salesforce metadata to provide improved stability for both Salesforce releases as well as dynamic Lightning pages.

• Most importantly, this solution can facilitate testing not only across environments and branches, but can take into account different personas and stakeholders within the Salesforce implementation.

Testim Salesforce in Action

Let’s see this in action. First, we need to install Testim. Let’s set it up as a Chrome extension.

You can install Testim directly from the Chrome Web Store.

After the Chrome extension is installed, you can connect your Salesforce environment to Testim and the extension will orchestrate tests in a separate Chrome instance.

Start a new test

Now we can use the included Salesforce demo project to see how it works.

In the Testim dashboard, click New Test. You can use the no‑code wizard and pre‑built steps, but you can also record a series of actions in your browser that then automatically create test steps. Additionally, you can also drop in custom Apex or JavaScript code.

For an existing test, press the play button to execute it against your Salesforce instance.

Testim has a set of pre-existing Salesforce tests that can be used out of the box or as a basis for customizing your own testing.

A test is a series of test steps, such as opening the login screen, entering credentials, and verifying that your browser navigates to the correct screen after logging in.

Record user actions for test creation

Testim has a feature that allows a test creator to record their actions in their browser and use that data to generate a new test. With recording enabled, navigate to the Sales tab, click New Lead, fill in the First Name, Last Name, and Email fields, then click Create. Next, click Convert. You’ll see in the test editor that each of these steps is now recorded in a new test. 

An example of a recorded test is below. You can click on any test step and modify its requirements, including success criteria and UI timeouts.

In the above example of editing a test step, you could change the target element that is selected, what is considered “passing” for this step, and when this step runs in the test sequence.

Insert additional test steps manually

Now click the + button at the end of the test sequences to manually add an additional test step. There are various built-in test steps that can be added without needing to re-record your steps in the browser. This is useful for adding additional checks into a larger test sequence without having to re-record it completely.

Review and maintain stability.

Finally, after execution, use the results dashboard to identify passed and failed steps. Testim flags unstable locators and suggests replacements.

Conclusion

In the introduction of this article, I noted that we live in a dependency-driven world. For me, I don’t think that is a bad thing at all. We just need to make sure we understand the reason for the dependency and take time to validate if the relationship still makes sense.

My readers may recall my personal mission statement, which I feel can apply to any IT professional:

“Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.”

— J. Vester

In this article, I’ve noted that organizations should treat Salesforce as a close business partner. I’ve also noted how pre-release validation testing is vital for avoiding service interruptions. We’ve discovered that implementation of Testim Salesforce provides an avenue teams can use to mitigate risks that are often exposed by the seasonal updates to the Salesforce platform. 

Testim Salesforce fully adheres to my personal mission statement. It utilizes a no-code solution which eases the pain of providing an acceptable level of test coverage, which is often faster to implement than options that require manual coding. Their use of AI provides deeper validation that creates stability and requires less maintenance over time. Most importantly, the solution can be an automated part of the software development lifecycle (SDLC).

Have a really great day!