In the search for the best automation tool to automate Salesforce, many choose Selenium as their go-to tool. If you too are considering Selenium for testing Salesforce, read on to make sure you make an informed decision, and know the challenges that may lie ahead.
Selenium is a popular web-testing tool. Why? Firstly, because it’s free and open-sourced, and therefore an obvious starting point for someone wanting to see how automation can contribute to productivity.
Second, Selenium allows you to drive tests and automate any processes that go on in a browser. Since Salesforce runs in the browser, Selenium is an obvious choice.
As many come to realize, however, Selenium requires coding, and therefore isn’t always the best option for teams with limited or no coding capabilities. Even those who have excellent coders on team will find that a lot of time goes into setting up and maintaining Selenium tests – time that could have been spent better elsewhere.
Using Selenium to automate Salesforce: 3 scenarios
Below are three scenarios that each explain typical challenges that testers eventually face when trying to use Selenium to test Salesforce.
Scenario 1: The myriad of programming languages
A team consisting of one developer (let’s call him Dan), one tester with strong coding skills (Tina), and three testers with little to no coding skills (Teresa, Tom and Tiffany) choose to shift from manual to automated testing and select Selenium as their tool.
First, Dan and Tina are given the task of writing the scripts for their Selenium automated tests. Dan prefers to write his tests with Python, whereas Tina prefers C#.
Time passes, and new projects emerge. Being the most experienced programmer on the team, Dan’s time is reallocated to other projects, where his coding skills are needed. Tina stays on the testing team, and is asked to take over Dan’s scripts.
This is where the first challenge emerges. Tina doesn’t know Python, and therefore is forced to discard Dan’s unfinished tests and write them over in C#. Time is thrown out the window, and Tina is faced with the tedious task, which could have been avoided if they had chosen a no-code tool from the beginning.
Scenario 2: The endless search for broken code
Tina, Teresa, Tom and Tiffany are all testing with Tina’s scripted Selenium tests. It works well, until one day, a test breaks.
Tina tries to troubleshoot the test by searching through all the code. It isn’t easy though; there’s a lot of code to go through, and finding a small issue among lines and lines of code can be tedious and very time-consuming.
Meanwhile, Tom wants to update another test, as there has been an update in Salesforce causing one of the elements in the test to be invalid. He also must spend a significant amount of time searching through the script – longer than Tina, because he isn’t as experienced with the code.
Once again, a lot of time goes into troubleshooting and maintenance.
Scenario 3: The maintenance monster
Dan, Tina, Teresa, Tom and Tiffany are all given the task of setting up a new series of tests with Selenium.
This time, they all contribute to the creation of tests: Dan and Tina write their own (in their preferred languages), while Teresa, Tom and Tiffany use Selenium’s documentation combined with simple Google searches to put together their tests.
Over time, tests are built up, contributing to an overall test architecture.
Unfortunately, due to the complexity of the combined tests, the testing architecture becomes quite chaotic and a bit of a monster to maintain.
The team’s manager, Marie, concludes that the time it takes to maintain and rebuild automation scripts supersedes the time saved on automation, and she decides it isn’t worth it anymore.
She wants to find a new, more time efficient solution that will give a better return on investment over time.
If not Selenium for Salesforce, then what?
Although Selenium checks quite a few boxes up front for teams wanting to automate their Salesforce tests, many find that it requires more of a time investment than initially expected – both in terms of setup and in terms of maintenance.
There is a high risk of ‘testing bottlenecks’ when using Selenium to test web-based technologies such as Salesforce, which is the main reason why many opt for more user-friendly, code-free tools.
When the intention of automating Salesforce tests is also to ensure stable functionality of business critical processes, such as ensuring that customer details are updated and stored correctly, or that integrations between product websites and Salesforce are verified, it’s critical that tests are always running smoothly, and that testing teams can easily manage, maintain and troubleshoot any failed tests.
It’s important to remember that Selenium is a simple tool that only makes a browser perform certain tasks. It doesn’t offer a whole lot more than that. For larger businesses and enterprises, where there are a big number of tests, teams with excellent business understanding but low coding skills, and functions like security and collaboration are highly critical, Selenium won’t suffice.
So what’s the alternative?
Download our whitepaper on Selenium automation below to learn more about what Selenium can and cannot do, and to learn more about Salesforce test automation tools.