Automation insights and productivity tips from LEAPWORK.

All Posts

Can You Automate Salesforce Tests Using Selenium?

In the search for the best automation tool to automate Salesforce, many choose Selenium as their go-to 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.

Consider for example the following scenarios.

Using Selenium to automate Salesforce: 3 scenarios

Scenario 1

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

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 amongst 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

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.

Why many give up on using Selenium to automate Salesforce

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?

If you want ease-of-use combined with powerful, secure automation but not programming and lots of maintenance, then LEAPWORK’s no-code automation platform might be the solution for you.

Learn more about LEAPWORK and how it compares to Selenium for Salesforce automation in our complete comparison, or sign up for our webinar to learn more about LEAPWORK and see the tool in action.

New call-to-action

Maria Homann
Maria Homann
Content Marketing Manager

Related Posts

Why Choose a No-code Automation Tool for Regression Testing?

Two of the major challenges in automating regression tests are setup and maintenance. This is because many test automation tools require coding, which requires time and capabilities that not all testing teams have.

How Frequently Should You Run Your Regression Tests?

Deciding how often to perform regression tests can be a challenge. Particularly when you've automated your regression suite, and are more free to decide the frequency.

Building Automated Regression Tests: What to Include

Over time, as your application grows or changes, your regression test suite will grow as well, numbering into perhaps hundreds or thousands of regression test cases. This is why automation will inevitably become part of your testing process at some point.