Webinar Recap: The Ultimate Guide to Testing in Salesforce with Provar and SalesforceBen

“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.”

[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.”

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

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.