Salesforce CPQ is a popular CPQ solution. But for an application with so many large-scale implementations, why is Salesforce CPQ so new to test automation? Read on to learn the primary challenges facing Salesforce CPQ testing and some examples of how Provar has tackled them.
What is Salesforce CPQ?
Salesforce CPQ (formerly Steelbrick) is a Configure-Price-Quote solution built on Salesforce Lightning. Salesforce CPQ streamlines configuration & ensures pricing & quoting accuracy, speeding opportunity, quoting and proposals, while removing errors from workflow. It is immensely popular in the marketplace, as evidenced from its AppExchange reviews.
Salesforce CPQ testing approaches
Many organizations who use Salesforce CPQ don’t do any automated testing, preferring to test each release manually. At Provar, we encounter a variety of approaches, some businesses being new to automation and others who are familiar with traditional solutions and are looking for something more maintainable.
What’s interesting about Salesforce CPQ testing is there seem to be fewer organizations who already have automation in place. At Provar we’ve met many Salesforce CPQ customers who come to us without an existing solution, preferring to manually test each release. So what’s holding them back?
We’ve discovered three main testing challenges in our work on Salesforce CPQ testing.
Challenge #1: Salesforce CPQ field locators
In our product development, we’ve found that Salesforce CPQ testing is particularly difficult with traditional automation methods such as Selenium.
Salesforce CPQ pages make heavy use of Shadow DOM, which can currently only be accessed using CCS locators, not Field IDs or XPaths. The standards for doing this are still being agreed.
One thing is well known, however: CSS locators don’t allow you to match on text. This makes it especially difficult to locate certain Shadow DOM elements.
Here’s an example of a Salesforce CPQ page which uses Shadow DOM:
A CSS locator for the Subscription Term field looks like this:
And here’s what happened when we tried to use that locator in a test:
Provar Solution #1: Specialized CPQ locators
Provar has specialized CPQ locators which give reliable results, even on Shadow DOM pages. In Provar, the user just maps the field as usual using the Test Builder, and the Salesforce CPQ locator type will be offered automatically:
This helps to reduce user error and ensures a future-proof locator.
Challenge #2: Salesforce CPQ tabs and tables
Another complexity of Salesforce CPQ testing is when pages contain internal tabs which control the table and fields visible under the tab.
These can be difficult to control with Selenium because awareness of the ‘active tab’ is crucial. If the wrong tab is selected, the right fields won’t be found, leading to test failures.
Provar Solution #2: Inbuilt Tab and Table Mapping
Provar maps Salesforce CPQ tabs and tables automatically, removing the risk of error. When a field is mapped for the first time, Provar will create a new Page Object for the tab or table, if they are new, or it will add a field to an existing Page Object if the tab or table has been used before.
Tab switching is handled automatically, so no input from the user is needed when interacting with fields on a different tab.
The process for mapping tabs and tables in Salesforce CPQ testing is also very similar to the process for mapping standard Salesforce tabs and tables, for example in a Service Cloud Console. This makes it easy for new users to learn.
Challenge #3: Quote Line Editor Drawers
As of Salesforce CPQ 28.0, Quote Line Editor Drawers can be used in the quote line editor to better handle a large field set.
Certain fields can be placed in a collapsible drawer below each line item, accessible by clicking the arrow at the end of a quote line:
Much like tables and tabs, these can be difficult to handle because the arrow must be at the ‘expand’ setting in order to be able to access the fields underneath. This can lead to failures if the arrow is not correctly handled.
Provar Solution #3: Automatic Drawer Handling
In Provar, these drawers are handled automatically by Provar and do not need to be mapped by the user:
All that’s needed is mapping the field as usual, and Provar’s metadata integration will handle the arrow setting. This reduces failures by ensuring the right field can always be found during the test.