At Provar, we value thought leadership in the testing space, and when it comes to Salesforce, some of our favorite conversations happen with SalesforceBen. We recently partnered with the SFBen team for a webinar called “The Ultimate Guide to Testing in Salesforce,” and it proved to be a hot topic with over 400 registrants and 30+ questions asked.

The webinar, hosted by Provar’s Chief Strategy Officer Richard Clark and SFBen’s Lucy Mazalon, covered all things testing and quality assurance for Salesforce. It took a deep dive into various topics to help attendees navigate the complexities of Salesforce testing and development, including:

  • Why test?
  • Quality beyond testing
  • Types of testing and approaches
  • Why testing on Salesforce is hard(er)
  • Integrating testing into DevOps
  • Provar solutions for quality
  • Impact of AI on Salesforce development and testing

It was a lively, interactive discussion with excellent insights gained! To get a feel for the topics discussed, here are some choice quotes from Richard.

“When people talk about testing, it’s important to understand why people need to test in the first place. For many customers, the biggest reason is often compliance. If you’re in a regulated industry such as financial services, life sciences, or government, it’s not an option to test. You have to test, and you have to have evidence that you have tested. For everyone else, we have regulations such as GDPR to prove that you’ve tested. And we have requirements from our users. So we must always try. It might be manual, but you have to test.”

“When we think about performance, performance isn’t just something we do once. If you’re implementing Salesforce and the save button on opportunity takes 8 seconds, you’ve probably got a performance problem somewhere to look at. It’s probably not a good user experience for your sales team when trying to close a deal. We want to be able to look at things like that and measure the quality, and we measure quality through testing.”

[Who will find this webinar of interest?] “Business analysts often have to justify why they’re testing. If you have a quality manager, you’ll be owning not just the test that is doing the testing but also the response to the quality of what’s in production, often measured by the number of bugs in production. But ultimately, stakeholders as well. What they want to get out of Salesforce is the features that give their business a competitive advantage. Everyone should be involved in some way to understand testing because you can measure the quality of your org through testing.”

“IBM did a study that said if a bug hits production, it will cost you 100x more to fix it in production than it would if you found it at the design stage.”

“[When tests break after a Salesforce update], the problem isn’t Salesforce. It’s the tools people are using.”

Q&A Session

The questions rolled in during the Q&A session, with topics ranging from Provar’s cloud solutions to best practices for testing. Here are some of the highlights featuring answers Richard.

Q: “Tests are more fragile than customizations…” That’s interesting. Does that mean we expect to see more false defects, i.e., not actual defects, when there’s a new release, but instead, our tests break, so we have to spend time fixing the tests themselves?

A: That’s the biggest problem with coded and robot frameworks that generate code. You have to fix it yourself.

(This is why Provar Automation is so resilient, as we build tests using the information found within Salesforce’s metadata, which is much less likely to change during regular updates and app customizations!)

Q: Does Provar support Classic and Lightning in automating Salesforce testing?

A: 100%, and the same test case can be used for both, as Provar understands the execution context and adjusts at runtime for the UI theme.

Q: Will Provar have a cloud solution?

A: Provar Manager is the start of that cloud solution. You can expect to see Test Builder integrated very soon, but we’ll always have some local development tools for advanced testing scenarios.

Q: Can you explain more about issue verification?

A: Let’s say you have a defect. You can use Provar to help execute the steps to repeat that issue and then re-run the same test with different data values to check other scenarios simultaneously. After deploying your fix, you can re-run those tests to smoke test the issue has been resolved in the target environment and include it in your regression test plan to guard against it re-appearing later.

Q: What is the correct process for building the regression suite? Should it start with uploading/creating test cases in Provar Manager and then automating the test cases using Provar Automation to track the percentage of regression tests automated, or is there a better way?

A: Great question. That is one option, and it is something new customers often do. Where people have existing test scripts, they may choose instead to focus on starting with Provar Automation first, as they have a burning platform, and then use Provar Manager to measure the performance over time. Like the DevOps Infinity symbol – you can start at either end and work your way around.

Q: I would love to dive deeper into how Provar protects against brittle tests. I heard the term “declarative.” Can we discuss some examples? I have seen Xpaths change, which breaks the test scripts.

A: Most Provar locators, such as Account, will use the metadata locator.City where it’s available. We use some XPaths where unavailable. These are relative locators based on our implicit knowledge of robust Salesforce testing. Users can override our suggested locators. They can use CSS, JavaScript, ID, Name, or Label locators if preferred.

Did you miss the live webinar? We’ve got you covered! Check out the replay on our YouTube channel.

Be sure to join us for future webinars covering testing, Salesforce, and Provar’s many quality solutions! Sign up for our newsletter to stay in the loop.