Selenium Alternative

If someone asks you to name a few of the most popular test automation tools on the market, chances are Selenium will be among the first ones to come to mind. Since its first introduction in 2004, it has become widely known and adopted by many companies around the world. But how does it stand against competition and should you be still using it in 2022? Let’s compare Selenium to testRigor, so that you can see for yourself and choose the right tool. So first:

Why compare Selenium and testRigor?

They’re both test automation tools which are used for functional and regression testing. The biggest difference between the two is in the approach to how tests are created. In Selenium Webdriver, it’s automation QA engineers/SDETs who create those. The downside is that there’s usually not enough visibility of how good the tests actually are (and if they’re converted from manual tests, then how well they are converted). It often results in tests being not very effective or deterministic, which is rarely tracked and inefficient tests are rarely being removed.

In testRigor on the other side, tests are being created in plain English, with the mindset of an end-user. Everyone on the team including manual QA testers, and even product managers are able to contribute. We’re talking about both creating and updating tests. You don’t need to focus on the technical implications anymore, and instead can focus on the tests themselves - which leads to better visibility within the team and more efficient tests.

Selenium’s advantages and limitations

First, let’s dive deeper into Selenium. At the time of its introduction, Selenium Webdriver was the first cross-platform testing framework that could configure and control browsers on the OS level. Being open source certainly played its role in increasing adoption. Selenium supports all of the main languages - JavaScript, Java, Python, Ruby, Kotlin, and C#. The user community is very strong, and you can quickly find an answer to almost any question. The reasons above led to Selenium dominating the market for many years, and companies have built millions of tests with it. But does that mean it’s a perfect tool fit for the job?

Some of the biggest disadvantages that anyone working with Selenium knows are:

  • Painful initial setup
  • Tests are extremely challenging to write the right way, but easy to copy (and as a result very soon test maintenance becomes a very grim daily task)
  • Tests are executed in the process outside of the browser we’re testing. Sleep times need to be added throughout, which is not efficient and often causes the next point:
  • Test flakiness (typically due to latency, timing, or other asynchronicity issues), which for some reason is perceived as the norm in the community

testRigor’s advantages and limitations

Now let’s look into testRigor. First of all, it’s not just a Web testing tool like Selenium, but rather a powerhouse also capable of testing APIs, mobile browsers, and mobile applications. Despite being introduced a few years ago, it has already gained significant traction with over 51+ million tests ran on the platform. All of the technical aspects which you have to manually take care of in Selenium - such as setup, finding element selectors, adding wait times, re-running the test in case your browser or server under test crashes - are handled by testRigor’s sophisticated AI system. Documentation is straightforward, and in case that’s not enough - there’s also slack-based support for all paid users which is quite quick to respond.

The only disadvantage that can come to mind when comparing testRigor to Selenium is price, but that quickly turns the other way around once you factor in higher salaries for senior automation QA engineers, infrastructure costs, as well as time spent on maintaining flaky tests in Selenium.

but that quickly turns the other way around once you factor in higher salaries for senior automation QA engineers, infrastructure costs, as well as time spent on maintaining flaky tests in Selenium.

Let’s now take a look at a test example below. The goal of the test is to select an element in a dynamic table:


using Automation.Example.Page.PageObject;
using FluentAssertions;
using NUnit.Framework;
using OpenQA.Selenium;

namespace Automation.Example.Test.Ui
    public class TableTest : Automation.Framework.Base.BaseTest
        public class GridComponent : BaseGrid<GridLocator>
            private const string COLUMN_NAME_ACTIONS = "Actions";

            private IWebElement GetCellElement(int rowIndex, int columnIndex)
                var cellElement = GetGridContainer()
                return cellElement;

            public int GetRowIndexByMatchingText(string columnName, string cellValue)
                IList<string> cellValues = GetAllCellValues(columnName);
                var index = cellValues.IndexOf(cellValue);
                return index;

            public void ClickActionsEditLink(int rowIndex)
                var columnIndex = GetColumnIndexByName(COLUMN_NAME_ACTIONS);
                var cellElement = GetCellElement(rowIndex, columnIndex);
                WaitUtils.WaitForAndClick(() => cellElement.FindElement(Locator.EditLink));

            public void ClickActionsDeleteLink(int rowIndex)
                var columnIndex = GetColumnIndexByName(COLUMN_NAME_ACTIONS);
                var cellElement = GetCellElement(rowIndex, columnIndex);
                WaitUtils.WaitForAndClick(() => cellElement.FindElement(Locator.DeleteLink));

        public LoginPage LoginPage { get; set; }
        public GridComponent Grid { get; set; }

        public void TestGrid()
            var columnName = "Id";
            var testCellValue = "spk2";


            // Test
            var rowIndex = Grid.GetRowIndexByMatchingText(columnName, testCellValue);

            // Assert
            Grid.GetRowIndexByMatchingText(columnName, testCellValue).Should().Be(-1, "Item should be deleted from the table");


click on the second button within the context of table at row containing "spk2" and column "Actions"

Let’s sum up everything we’ve just discussed in the table below.

Selenium testRigor
Requires programming language knowledge (Java, Python, Javascript, etc) Tests are written in plain English (not Gherkin), no coding skills are needed
Complicated initial setup Setup is as easy as it gets
Only supports automation for web browser applications Supports testing for web browser applications, native and hybrid mobile apps, mobile browsers, and APIs
A fair share of QA engineer’s day is dedicated to test maintenance On average, testRigor’s users spend 99.5% less time on maintenance
Tests are never perfectly stable due to latency and asynchronicity issues Tests are very stable. Even if there is a browser or server crash during execution, testRigor will silently catch that and span a new instance
Moving project to a different development framework (ex: Angular to Vue) will break existing tests Labels are auto associated with inputs, so tests won’t break if UI stays the same
Reporting and dashboards are not built-in and need to be configured separately Built-in reporting with automatic screenshots for every test step and a dashboard for the test suite

Wrapping up

We hope it becomes clear in this article that testRigor drastically changes the way automation tests are built - and saves the tech teams time, money, and eliminates a lot of frustration. You’re very welcome to start with a free public tier to explore testRigor and make a decision for yourself.

Fill out this form and we’ll be in touch

  • Your request was sent.