Back to Resources


Posted October 8, 2020

How to Optimize a Test and Make It 560% Faster

Deep in the implementation of every automated UI test lives the potential to turn something simple into something slow and unreliable—simply by adding extra Selenium commands. The data clearly show that longer tests are less likely to pass. In this case study, I will show you how to optimize a test and make it 560% faster. We will do this by tackling inefficient use of Selenium commands.


Before optimizations

Too many Selenium commands in a test can lead to tests that are dramatically slower and less reliable. Every Selenium command carries the potential for an invalid element locator or a synchronization issue. 

Below we have a table that shows an automated test that was designed to click two radio buttons. V1 test is making 157 Selenium commands and takes 95 seconds to execute. After optimizations, the same exact test executes 9 Selenium commands and runs in 17 seconds (5X faster).

Total test run time V1

Number of web requests before optimizations (V1)

What was the purpose of this test?

The purpose of this test was to simply click two radio buttons on this URL

Identifying the inefficiencies

The major contributor to the slow test time of such a simple test was the large number of unnecessary web requests.

Attempting to click first radio button

After loading the URL, the test takes ~60 seconds searching for random elements without taking a single action.

Unnecessary commands start at the 15-second mark and continue until 1:19, at which point the element is finally located and clicked.

Potential Waste: 60 seconds on 1 element

Attempting to click second radio button

At 1:23, the test starts looking for the Female radio button.

And finally clicks it at 1:28:

...but not before making 16 more Selenium commands to check whether the element is displayed or selected.

Potential waste: 3 seconds for every

Post-click() Selenium commands

Finally, there is an interesting pattern of wasted web requests that happens after every element click(). We can see that below:

It’s understandable that these are being performed to validate that the element is in the correct state after the execution of a click(). However, these actions are wasteful because Selenium would throw an error if the action wasn’t successful. Furthermore, the next action would fail with an exception if it depended on the state of the previous element.

Potential waste: 2 seconds per

The refactor using cleaner practices

The refactoring of this test was extremely simple and required only a few minutes after understanding the root cause of the problem. Furthermore, we saw that the final outcome of the refactoring created a test that was 560% faster and drastically more stable because it had fewer Selenium commands.

Here’s the code after we finished refactoring:

This is the test execution result and below is the screenshot.

Lessons learned

Bloated tests in the industry are infamously common and it’s something that I tackle on a weekly basis. They typically come with a framework that we use for our automation. I’ve seen this with both OSS frameworks and especially homegrown ones. The key is to consider the impact of extra Selenium commands on the overall automation program. In this use case, the test suite execution time will be five times longer for the entire organization. This obviously decreases the feedback cycle time and also makes the automation less reliable.


Nikolay Advolodkin
Principal Developer Advocate at Sauce Labs
Oct 8, 2020
Share this post
Copy Share Link
© 2023 Sauce Labs Inc., all rights reserved. SAUCE and SAUCE LABS are registered trademarks owned by Sauce Labs Inc. in the United States, EU, and may be registered in other jurisdictions.