This is the first 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 special.
The reality of testing within large enterprises is that, as much as they may like the idea of standardized methods and tools and try to implement them enterprise-wide, different teams have very unique needs. One size does not fit all.
To that point, here’s a little-known fact about Provar: Many of our happiest customers were already using tools in other areas of their business when they began looking for Salesforce test automation solutions. And, even though we call out Selenium, businesses are choosing Provar over all kinds of alternatives — manual testing, home-grown solutions, and low-code ERP testing tools with Salesforce-added features like Tricentis.
What’s the reason QA teams eventually move past their current tools and choose Provar? The answer starts with understanding a bit about Salesforce, which will show why enterprises are bypassing their old testing automation tools and adopting Provar.
What’s so special about Salesforce?
While there are many things that make Salesforce special (and in turn, make picking the right testing solution a must), I’m going to pick the five that are most relevant to this conversation:
1. BIG and enterprise critical
What started years ago as “just a really nice CRM” application has grown way, way beyond its origins. Salesforce has evolved into a massive, customer-facing, revenue-enabling, touching-everything (from CRM to CPQ to fulfillment to billing and more) strategic application development platform. It’s typically heavily integrated with accounting, ERP, ecommerce, and beyond. It is the 900-pound gorilla in the room. If a Salesforce application fails, it’s usually a direct hit on revenue-generating capability and (depending on what fails) potentially an event that causes damage to customer and partner relationships.
2. Easy to customize and easy to break
One of the great things about Salesforce is how easy it is to customize. Need a new field on a lead form? Just add it. Need to change a label, update an approval process, a price, or quote terms? Simple. That’s the good news. The bad news is that it’s really easy to make little and big changes without any documentation, any version control, or any testing. Just make the change and put it into production. That is a questionable approach if you’re working with a small CRM application, and it’s inviting disaster if you’re managing enterprise critical applications driven by Salesforce.
3. Not historically predisposed to software development methodology
In some ways Salesforce has been ahead of classic software development, enabling no code development before it was even a thing. In other ways, Salesforce has been behind: empowering all those citizen developers and testers did not always include central IT control and DevOps processes. (That was kind of the point, but problematic for business critical applications.) While many organizations are adding DevOps, integrated testing, and IT governance to their Salesforce projects, there is still a lot of “wild west” in Salesforce application development.
4. Major updates three times a year
Salesforce delivers three main releases each year, typically including a bundle of new features, changes to existing functionality, and sometimes (like Lightning), major shifts in how Salesforce is used. Customers cannot opt out; they must adopt the release and deal with any issues the updates present.
5. Architected to confound traditional browser test automation
Along with being enterprise critical, complex, and constantly evolving, Salesforce is built with technologies — dynamic forms, shadow DOM, and flexipages to name a few — that cause traditional record-and-play approaches and typical field locator strategies (XPath, CSS, Javascript, etc.) to break down and cry. And, Salesforce regularly makes changes to how a page is rendered, directly affecting the HTML, CSS, Javascript, and DOM that most test automation tools rely on to build tests — so they break often, typically with each major Salesforce release. It’s really hard with these tools to meet the goal of highly resilient, reusable tests that can be built by non-technical testers (i.e., non-coder business analyst types). The problem gets worse when you think about maintenance, i.e., updating tests to deal with changes from simple customizations (labels, for example) as well as major Salesforce updates.
It’s a Perfect Storm
Let’s sum up: You have an enterprise critical platform that’s big, complex, and super easy to change, often managed by non-technical types, without the rigor of traditional software development, with at least three major changes per year. All this is being tested by other non-technical types, with tools that require technical expertise and that struggle because of the way Salesforce is architected. What could possibly go wrong?
→ Stay tuned for our second blog in the series, “A Sea of Testing Options,” for a continuation on this topic!
Can’t wait for the next blog post in the series, and are already itching to set up a demo? Let’s talk. Connect with us, tell us about your testing needs, and we’ll get back to you to chat further!
