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 along as we look at (1) the behind-the-scenes reality of using Salesforce and why testing is needed in the first place, (2) a comparison of the types of testing available, (3) why Salesforce and Provar are BFFs, and (4) what makes Provar so unique. Be sure to read Part 3: Community and Culture Matter, on our blog.

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. And, there’s a fundamental mismatch in how Salesforce web pages are created and how most web test tools work.

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. That’s managed and evolved by Salesforce.
  2. Salesforce regularly changes how the page is rendered, directly affecting the information that traditional tools rely on to build tests. This is why tests built on rendered web page sources are more prone to breaking with Salesforce updates.

Provar was explicitly engineered for Salesforce to make 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 the information in the Salesforce metadata model, combined with metadata (including customizations) from the org being tested.

Salesforce uses metadata to describe its page layouts, objects, and field definitions. Provar uses Salesforce metadata APIs to collect metadata from the org being tested and uses it 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:

  • Tests are much more resilient to change, reducing maintenance.
  • Test building is much simpler (single click to add a step to a test), test step configuration is automatic and detailed, and the test building process is more intuitive.
  • Abstraction is very low. Test building happens in Salesforce vs. in the testing application.
  • Test builders only need to know the process and the application, lessening the developer/tester/user communication gap.
  • It’s easier to build tests that will work in multiple contexts (across different orgs, different languages, different user profiles, etc.)
  • Provar maintains all the code to map Salesforce page elements, predict interactions, understand page layouts, and automatically generate and execute tests. This is how Provar ensures customer tests are 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!