This is the fourth article in a four-part series, “Why Selenium Users Pick Provar for Salesforce Test Automation.” Don’t just take our word for it. Read on as we cover the following topics:

What makes Provar unique? Be sure to read Part 3: Community and Culture Matter, on our blog.

We need to understand the behind-the-scenes reality of using Salesforce and why testing is necessary.

A comparison of the types of testing available.

Why Salesforce and Provar are BFFs.

Salesforce implementations are important and complex enough to warrant a specialized test automation solution instead of adjusting a generic web application testing tool to fit. Salesforce web pages and most web test tools have a fundamental mismatch in their creation and functionality.

Traditional web application tools map page elements and build tests based on information about the rendered page – the HTML, CSS, Javascript, and DOM. This is a problem for two key reasons:

  1. Developers don’t control how the source is rendered for a Salesforce page. Salesforce manages and evolves That.
  2. Salesforce regularly changes how it renders pages, which directly affects the information traditional tools use to build tests. This is why tests built on rendered web page sources are more prone to breaking with Salesforce updates.

Provar was designed specifically for Salesforce. It makes tests virtually unbreakable, polymorphic (usable in multiple contexts), and intuitive (usable by the citizen tester). Instead of using the rendered web page source, Provar builds tests using information from the Salesforce metadata model. Provar incorporates metadata, including customizations, from the tested org.

Salesforce uses metadata to describe its page layouts, objects, and field definitions. Provar uses Salesforce metadata APIs to obtain information from the organization it is testing. It then uses this metadata to build tests.

The beauty of Provar’s strategy is that the metadata tied to fields and layouts changes much less often than the rendered web page source. Provar is built to work with this metadata, and how our technology uses the metadata to drive Salesforce test automation is Provar’s secret source. This approach delivers some extraordinary benefits:

  • As a result, tests are much more resilient to change, which reduces maintenance. Furthermore, test building is simplified, with a single click to add a step, automatic and detailed test step configuration, and a more intuitive process overall.
  • In addition, abstraction is minimized since test building occurs directly in Salesforce rather than in a separate testing application.
  • This approach ensures that test builders only need to know the process and the application, thereby narrowing the communication gap between developers, testers, and users.
  • Moreover, it becomes easier to create tests that work in various contexts, such as across different orgs, languages, and user profiles.
  • Finally, Provar handles all the code required to map Salesforce page elements, predict interactions, and understand page layouts. It automatically generates and executes tests, ensuring that customer tests remain compatible with each new Salesforce release.
  • Locators work across any Salesforce page layout, org type, and Salesforce application (i.e., Classic, Lightning, Flexipages, Dynamic Forms)

As mentioned in the first blog in this series, many of our happiest customers use other test automation tools besides Provar because they understand that Salesforce is unique in business applications, and it warrants a unique and specialized approach to testing automation. If you’d like to read about their experiences firsthand, head over to our customer success stories and learn how Provar delivers exciting results.

Thanks for joining us for this special 4-part blog series! Interested in learning more? Connect with us, tell us about your testing needs, and we’ll get back to you to chat further!