Overcome Salesforce testing challenges after every release
Every major Salesforce release brings with it improved UI for greater functionality. Brilliant for users, but don't expect the joy to spread to your testers or Salesforce Admins.
As with a lot of these new releases, even the most minor UI changes have the potential to break your tests, perpetuating a never-ending cycle of test maintenance — especially when using an automation tool that instruments into the codebase.
There is another way.
Use a test automation solution that doesn't solely rely on one testing technology over another. By utilizing a solution that can verify the code and validate UI functionality by intelligently understanding what the user sees on the screen, testing Salesforce's thrice-yearly releases is an absolute breeze.
Why some tools struggle with Salesforce testing
Complex applications can be hard to test, particularly when you use Object or DOM tools.
And Salesforce Lightning is complex enough without the headache of regular updates breaking your test scripts.
The main complication here is Salesforce's use of Shadow Document Object Model (Shadow DOM), which wraps up and protects the internal DOM, which is basically the structure and content of a webpage.
By protecting the internal DOM or shadow tree, its web components are prevented from being manipulated by programming languages such as HTML, CSS, and Javascript.
Object or DOM tools struggle at this point because the scripts they use are normally written in Javascript. They also rely on a deep understanding of the underlying object's IDs and attributes. So when a test is run, it will look for those IDs and attributes to continue through each action.
This is fine in theory and used to work years ago when an action, such as "click ok button," was clearly defined. But now, things have evolved; so while Salesforce's UI has improved by adding features, such as iFrames, drop-downs, and pop-up windows, testing it has become more challenging.
The prime reason for this is the fact that Salesforce Lightning uses dynamic IDs, and other attributes have grown in length and become less unique.
The result? Object or DOM tools struggle to identify the changing IDs and ubiquitous attributes, and the test fails. This creates a lot of work and effort just to uncover which part of the DOM has changed. Not to mention the amount of test maintenance needed to merely stand still and keep your existing Salesforce platform running.
If you continue down this path, test automation maintenance never ends. It sucks up an exorbitant amount of resource fixing errors in existing tests and prevents new scripts from being created. This situation might be acceptable if you have an army of testers, but time is too precious for most organizations.
And the final nail in the coffin for Object or DOM tools — they don't measure the user experience because the focus of testing is the codebase. This is ok to confirm that the object is available, but it can't tell you if both internal and external users' interactions with the software are affected.
Imagine a salesperson not being notified about a meeting and cannot sign a multimillion-dollar deal, irrevocably damaging the customer relationship.
Or an employee can't input data into a correct drop-down that produces inaccurate reports and dashboards when management analyzes company performance.
These scenarios can easily happen when updates change functionality and errors aren't picked up when tests fail.
Neither is good for business.
Wake up from DOM-related nightmares and overcome Salesforce testing challenges after every release
Salesforce delivers three releases per year, plus other upgrades and maintenance updates. These changes break automated tests created by Object or DOM tools, requiring many hours for maintenance and fixes.
Instead, it would be best to have a testing solution that doesn't solely rely on Objects and can handle various new features and UI functionality changes from the user's perspective as well.
Throw in a model-based approach, powered by intelligent AI and computer vision, that allows you to use the same script to test different versions of Salesforce across various browsers, devices, and operating systems.
Keysight's Eggplant computer vision AI-assisted test automation solution is the answer.
To put it another way, take a look at the below screenshots –the first is Salesforce Classic, and the second is Salesforce Lightning. As you can see, they both have entirely different underlying code and identifiers.
By using Eggplant, the same test can be used for both Salesforce versions and it will test what the user can see on the screen (“New TS Task” or “New”) and will not break due to the changes in code. Plus, test maintenance is massively reduced.
Or use a tool that can only rely on Objects to verify functionality at the code level, which would require various tests for the different Salesforce versions and code. And then you’ll have to update them when the tests break because they are unable to find the dynamic IDs and complex attributes – not forgetting to continuously maintain every test as well.
You can even use Eggplant's Fusion engine to work with Selenium WebDriver to test on its own or in combination with VNC or RDP connections to combine object-based testing with image-based testing to achieve a hybrid approach.
It should be an easy decision.
Discover how the Eggplant Salesforce Solution can accelerate deployments and reduce testing from months to minutes.