In this post, I’ll review some of the common challenges with testing Salesforce applications and integrations, how other frameworks and vendor tools attempt to solve these challenges, and finally, how Testim does it better.
Why Test Salesforce?
Before we start talking about testing Salesforce, it’s essential to understand why you should examine your Salesforce implementation.
You might be wondering if Salesforce is a commercial application that my organization pays to use, why do I have to test it? Shouldn’t they QA their application? Well, of course, they do. At the same time, Salesforce is also highly customizable, and every implementation can be slightly different. Your dev team might also create custom objects to extend Salesforce to fit your team’s needs. Additionally, teams integrate it with many applications in your environment, making it essential to how you do marketing, sales, order fulfillment, customer service, and billing.
Net, it’s complex and woven into your organization, so it’s indispensable. When your Salesforce flows aren’t working, your team loses productivity, and your customer interactions suffer.
Salesforce testing challenges
Let’s review some of the characteristics of Salesforce that make UI testing with traditional tools somewhat challenging. Some of these challenges stem from how Salesforce develops its applications, and others derive from how organizations choose to implement it.
Dynamic pages – Classic and Lightning web pages and object properties are fluid and change based on context. Tabs are iFrames, and the content is dependent on selections outside the frame.
Styled Components – Class names and indexes can frequently change with random tags rendering them unreliable as locators.
Shadow DOM – Salesforce places objects behind a Shadow DOM. This effectively hides some of the objects’ attributes that many automation tools would use for identification.
Highly customizable – Organizations and users can change views, layouts, and reports to suit their needs. Developers can add custom objects that some tools won’t recognize. The combinations are nearly endless, making testing every scenario nearly impossible.
Role-based – Salesforce users can have different experiences based on their roles. While this may not add any new challenges, it does increase the variability of potential user flows and the need for additional testing.
Integrations – Many 3rd party apps integrate with Salesforce. You might have a marketing automation tool like HubSpot capture contact information and pass that to Salesforce. You may want to verify that the correct information is correctly passed to and rendered in Salesforce.
This was not an exhaustive list of problems, but it does touch on some of the most challenging items. Of course, your mileage will vary depending on the Salesforce apps you are using and how you have configured and customized your environment.
What to test? / What not to test?
When you build your test automation strategy, it’s crucial to think about where risk may exist. Risk is more likely to show up in your custom objects, APEX code, and bespoke integrations. In addition, consider where bugs or downtime will have the most significant impact.
Do test:
- Custom objects
- APEX code
- Non-standard integrations
- Custom configurations
- Business-critical processes
You don’t need to test everything in Salesforce. First of all, Salesforce has already tested its application thoroughly. Salesforce can’t test every possible scenario, but it does validate the expected flows and default objects. In addition, Salesforce has over 150,000 customers using their application and reporting problems when they occur.
Don’t test:
- Default objects
- Standard integrations with market-leading vendors
- Routine business processes which have less impact if they are down
Unfortunately, many vendors market their Salesforce expertise based on testing default Salesforce objects and standard test cases (the things you probably don’t need to test). The true fitness test is how well they help you test the customizations and non-standard integrations that pose the most significant risks.
Problems with many automation tools
The above testing challenges make test automation in traditional tools both harder to write and harder to maintain. We’ll now explain how traditional automation frameworks and tools try to approach these challenges in more detail.
Tabs and frames
Salesforce pages are dynamic and include tabs that shift the context of embedded frames and objects. Coded test automation frameworks like Selenium, Puppeteer, and Cypress require multiple scripting or modeling paths to switch frames to find things manually. Testim looks at the structure of the DOM and understands relationships between objects and frames automatically. Simply record the user flow you need, and Testim remembers how to find the correct elements.
Single locators
Frameworks like Selenium and tools that rely on them use single locators to identify elements and objects. These locators can frequently change from Salesforce updates and break your tests, requiring more maintenance time to fix. Some vendor tools have a better approach.
Custom objects
Salesforce includes the ability to create custom objects that should be part of your tests. Many tools can test default objects well, but let’s be honest, that’s not where the risk lies. Custom objects strain these tools requiring Selenium or scripting knowledge, extending authoring time, and increasing maintenance.
Shadow DOM
While some traditional tools can use scripts to pierce the Shadow DOM, it requires a particular tool or language knowledge, additional time scripting, and manual locator selection that lead to test flakiness. Testim natively handles the Shadow DOM and uses AI-powered locators, rather than single selectors, to identify objects, making them incredibly stable.
Dynamic CSS
Many tools rely on CSS selectors like class names, indexes, IDs that change frequently and break tests. Testim’s smart locators automatically filter and map dynamic attributes to keep your tests stable.
Repetitive authoring
Creating tests for similar objects that repeat within a page like table rows, contacts, or opportunities can require multiple tests with manual locator selection at each step of a similar object. Testim simplifies object sharing across tests so you can easily create tests for different roles by reusing flows that apply to additional roles.
Testim’s modern platform
To sum up, Testim uses AI-powered smart locators to build a deep understanding of the Salesforce application and automatically handle changes that challenge most other tools.
Testim recognizes and switches between tabs and frames, automatically creates multi-attribute smart locators, pierces the Shadow DOM, simplifies custom object handling to speed authoring and minimize maintenance.
Hundreds of customers, including Salesforce, use Testim to test their Salesforce applications and integrations today. They run over a million tests every month, helping Testim train its algorithms better and keep tests stable.
Finally, we launched a new product, Tricentis Test Automation for Salesforce built on the Testim platform that includes all of the capabilities mentioned above plus additional features for simplifying Salesforce testing.
