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 on to learn (1) about Salesforce’s behind-the-scenes operations and why testing is necessary. (2) a comparison of the types of testing available. (3) why Salesforce and Provar are BFFs, and (4) what makes Provar unique.
The reality of testing within large enterprises is that different teams have unique needs, as much as they may like the idea of standardized methods and tools and try to implement them enterprise-wide. 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.
Why do QA teams eventually move past their current tools and choose Provar? The answer starts with understanding Salesforce, showing why enterprises bypass their old testing automation tools and adopt Provar.
What’s so special about Salesforce?
While many things make Salesforce extraordinary (and, in turn, make picking the proper 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 nice CRM” application has grown 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 making small, significant changes is straightforward without documentation, version control, or testing. Just make the change and put it into production. That approach is questionable 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 it was 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 new features, changes to existing functionality, and sometimes (like Lightning) significant 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. , Salesforce regularly changes 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 often break, typically with each major Salesforce release. It’s tough 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 worsens when you think about maintenance, i.e., updating tests to deal with changes from simple customizations (labels, for example) and significant 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 significant changes per year. All this is being tested by other non-technical types, with tools that require technical expertise and that struggle because of how Salesforce is architected. What could 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 you 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!