Selecting a Selenium Grid infrastructure in an enterprise
Test automation is integral to achieving high quality and fast feedback cycles in an organization. It is also one of the main pillars for moving your organization to a CI/CD/DevOps and Shift Left approach.
In June 2018, Selenium has become the W3C standard for automated web testing. Running Selenium tests on different browsers and mobile devices and in parallel enables an organization to achieve high test coverage and fast feedback cycles.
Selenium Grid is the common approach for a Selenium cross browser testing infrastructure. Selenium Grid allows to run tests on multiple browser / OS combinations in parallel and helps reduce test suite execution times significantly.
There are three main options for setting up a Selenium Grid infrastructure:
- On-premises homegrown
- SaaS / Cloud
- On-premises vendor managed
This white paper is intended to give guidance for determining a suitable Selenium Grid Infrastructure solution for your enterprise organization. We will look at the currently available Selenium Grid solutions in the market and compare pros and cons.
According to the Gartner Magic Quadrant for software test automation (Gartner, December 2015), Selenium will become the de-facto standard by 2020 for test automation. In June 2018 the WebDriver protocol has become a W3C standard and with that Selenium (and Appium) already is the standard for automating web and mobile applications.
One of the main advantages of Selenium is the ability to run the same test script against multiple Browser / Operating System combinations.
There are two main components to a Selenium setup.
- Client side
This is where the test framework resides, where tests are authored and where tests are run from (i.e. developer workstation, CI system).
- Browser execution infrastructure
The test execution infrastructure (Selenium Grid) receives the Selenium commands and translates them into browser specific actions. This white paper focuses on the browser execution infrastructure which is typically resembled by a Selenium Grid.
A stable, easy to maintain, secure and scalable test execution infrastructure is essential to an enterprise. In an enterprise there are typically many sources of tests with different tools in play. In the Web / Mobile field most of those tools converge to use Selenium / Appium as the base protocol to control the browsers and mobiles.
In a typical enterprise tests are coming from the following sources:
- Developers using Selenium language bindings (i.e. Java, JS, C#)
- Protractor for Angular Applications
- Cucumber / BDD Frameworks
- Frameworks like TestCafe
- Commercial tools like Tricentis Tosca, Ranorex etc.
Selenium Grid mainly serves the purpose of providing the correct browser / Selenium / driver combination when a test is being executed on the infrastructure. Besides that it also
- Load balances and routes tests coming from the client side (i.e. CI system, developer workstation, commercial tools)
- Resource management of the browsers
- Reliability and browser crash recovery
When teams start out, tests are typically executed on the same machine where they are authored. For example a developer creating test scripts on his/her machine and then executing the scripts on the same machine. This approach has some fundamental drawbacks:
- The machine is occupied for the duration of the test run
- Only the browsers which are installed on that machine are available for test
- Tests can only be executed in sequence or with low scalability ( -> long test execution times)
- If you want to run the tests from a CI system, the browsers need to be installed and maintained on the CI system as well.
With Selenium Grid, the test authoring side gets decoupled from the test infrastructure side. Selenium Grid acts as the central test execution infrastructure where all those different sources connect to and execute their tests.
Building and maintaining such an enterprise grade infrastructure is a large effort and can easily keep an entire team of developers and system admins busy.
There different approaches for getting a Selenium Grid infrastructure up and running in your enterprise. In this paper we will focus on the following 3 main approaches:
- On-premises, homegrown and self-maintained (homegrown*)
- Cloud / SaaS (cloud*)
- On-premises vendor managed (Selenium Box*)
* term used for this white paper
The first question, enterprises need to answer is to whether to use an on-premises or a cloud solution. There are numerous players in the Cloud / Saas such as Saucelabs and Browserstack and many others. For many organizations using a cloud service is a good approach as these providers offer a large range of browser / OS combinations and there is no maintenance required on the infrastructure side.
Many organizations have heavy restrictions and regulations when it comes to test data (i.e. they are using production data for test purposes). For these organizations it is mostly impossible to use cloud services. When using a cloud service you are
- sending your test / test data to the provider
- the provider needs access into your infrastructure
- the test is executed in the provider browser infrastructure
- the provider typically retains logs, screenshots, videos of your tests
Keep in mind how Selenium works: every command requires a http roundtrip from the client to the server side and back.
Most enterprises have their CI system, source code repository and test infrastructure close together. Adding a Selenium Grid which is outside of this environment typically adds latencies and can dramatically increase test execution times.
Depending on the above considerations you should have come to a first conclusion whether you can go to a SaaS provider or whether you need to run Selenium Grid infrastructure on premises.
This option is the starting point for many organizations. Selenium Grid is integrated into the open source distribution of Selenium. It is fairly simple to get a first demo up and running.
After the initial demo and evaluation, many organizations continue to use their engineering staff to build up the enterprise Selenium Grid environment. Building and maintaining an enterprise grade Selenium Grid requires much more effort than a proof of concept.
Deep Selenium know-how, infrastructure, virtualization and system admin skills are required for developing a secure, scalable, consistently up-to-date and cost efficient Selenium Grid infrastructure. This know-how is often outside a company’s core competencies and internal resources could be more efficiently used for core IT purposes.
One of the major obstacles with a homegrown solution is maintaining and scaling the infrastructure to growing needs. Such an effort is usually complex and resource intense.
Another major challenge is the maintenance of the various OS / browser combinations. With the frequent releases of new browser versions and the further development of Selenium and drivers, a team of engineers is necessary to keep the Selenium Grid up and running. Even a small mismatch between browser / driver / Selenium can lead to unpredictable functionality of the browser – leading to false positive or negative tests.
Setting up an in-house Selenium Grid on your own is complex and usually lies outside of the core competencies of most company’s IT departments
There are several vendors offering Selenium Grid as a SaaS solution. When using such a cloud service, the provider takes care of all the time consuming development and maintenance of the Selenium Grid infrastructure. Cloud providers boast a large range of browser / OS / combinations and in some cases support mobile testing.
Depending on the industry that you’re in, cloud providers can be a great fit. They offer various packages from entry level pricing to enterprise packages.
However, the larger the organization grows, the more difficult the use of a cloud provider becomes – first and foremost because of security reasons.
The use of a cloud service requires external access to your enterprise’s infrastructure. You need to access the cloud provider’s infrastructure and their browsers running in the provider’s infrastructure need to access your application under test.
Large organization as well as enterprises in the banking, insurance and medical field often have strong limitations in giving external access to their systems – making it impossible in many cases to use cloud providers.
Also with cloud based solutions, operations and maintenance lie outside of the organization, resulting in a lack of control over how infrastructure is built, security, performance aspects, resource sharing, monitoring options, etc.
In many cases, cloud providers have a central data center. Depending on the location of the cloud provider’s infrastructure and the distance to the customer’s environment (CI, application under test), network latency can have an impact on the performance of tests. Each Selenium command requires a full roundtrip from the client to the server and back. If the customer infrastructure and the servers of the cloud provider are geographically far apart the network latency can drastically increase the test execution time.
The price for cloud solutions often scale linear with the number of tests and the concurrency of tests. Enterprise subscriptions are also offered. However even with enterprise licenses, cloud based solutions often have limitations with regards to scalability and parallel / concurrent test runs.
These limitations should be taken into account and clarified with the vendors, as they can impact the overall goal for fast feedback cycles.
Up until fairly recently, organizations could choose either the homegrown or the cloud path. In 2016, Element34 Solutions released an on-premises enterprise Selenium Grid infrastructure solution . This solution is fully managed and overcomes all the shortcomings of a homegrown self-maintained solution.
Let’s look at the various aspects of an on-premises Selenium Grid solution to understand why the combination of an on-premises and fully managed solution is in many cases exactly what a large and security sensitive enterprises requires.
For organizations in the financial, medical and the security sensitive field Selenium Box is the most secure option. No external access is required and no data leaves your network.
Selenium Box guarantees security and eliminates privacy risks that are associated with cloud based solutions.
Due to running in the same network / infrastructure, the setup and integration of vendor managed solution is straight forward. As a result, connecting with the CI, reporting and monitoring systems and the application under test is simple.
A solution like Selenium Box is fully managed and we as vendor ensure that the OS / browser / driver / Selenium combinations are compatible with each other. Customers can be sure that the browsers which are released to the system are fully functioning and do not lead to unreliable tests. No further maintenance is required and the customer can focus their engineering staff on the core competencies of the business.
The proximity of the different systems in a CI pipeline to each other is key to fast and reliable tests. A vendor managed Selenium Grid solution eliminates the latency issues of cloud solutions. In many cases the execution times of a test suite are 3-5 times faster with an on-premises solution compared to a Selenium Grid in the cloud.
As more and more tests are run within your organization, the need for scaling becomes increasingly important. Selenium Box allows customers to scale to their needs while being in full control of the cost. With Selenium Box, customers can simply add more CPU / RAM to the system and with that allow for more tests to be run in parallel.
Compared to a homegrown solution, a vendor managed solution comes with enterprise level support and SLAs for issue resolution. Homegrown solutions in many cases are managed “on the side” by development teams and cannot ensure uptime, reliability and consistency.
A vendor managed solution comes with many value add features like live view, video recording, monitoring & logging capabilities, access control and error recovery. Homegrown solutions lack value added features since they typically use the out-of-the-box open source Selenium Grid. Therefore, teams are usually stuck with a barebones Selenium Grid that does not allow for easy troubleshooting, debugging and reporting. The use of a homegrown Selenium Grid creates the risk of a lower adoption of automated testing than with a feature-rich managed Selenium Grid solution.
Cost is an important factor in the selection process of a Selenium Grid solution. Let’s be clear: even though Selenium is open source and does not incur any license fees, it still requires an investment to use Selenium.
Building a homegrown Selenium Grid solution typically takes several person years. Also the ongoing maintenance of such a solution usually requires a handful of expert engineers / operations staff.
Cloud solutions do not require in-house staff but incur license fees. For a larger enterprise, fees usually run in the 6-digit (USD) space. As well, the integration of the cloud service into the enterprise infrastructure (if possible at all) can be a significant cost factor.
Selenium Box also incurs a license fee plus the hardware / infrastructure cost for running the system.
Engineering resources are scarce these days and enterprises need to focus their staff activities on their core business. Building and maintaining a homegrown solution can be compared with rebuilding Microsoft Office. While it *could* be done, it adds no value to the enterprise especially since there are commercial solutions in the market.
With a managed solution (cloud or vendor managed), teams can fully focus on the task of writing meaningful tests rather than building and maintaining test infrastructure and / or having to working with hard to use and unstable solutions.
To implement and maintain a homegrown Selenium Grid a group of experts is required. In case of a change within the team (i.e. reorganization, attrition), it can be difficult to fill these position in a timely manner – potentially slowing down or stopping your test automation and CI/CD efforts all together.
A secure, reliable and scalable Selenium Grid cross browser infrastructure is crucial for a successful CI/CD and DevOps setup. Setting up and maintaining a mature enterprise grade Selenium Grid infrastructure requires a significant investment and is a complex undertaking.
While a homegrown solution can be a good starting point, for most enterprises they quickly become unmanageable. Homegrown solutions require a big up-front investment in terms of engineering resources as well as deep Selenium Grid know-how. Maintenance for a homegrown Selenium Grid is time consuming and prone to error due to frequent new release of browsers and the Selenium ecosystem.
Homegrown solutions also lack any comfort functions for easy debugging and troubleshooting.
When moving away from homegrown solutions, there are two choices:
- Cloud / SaaS
- On-premise vendor managed (i.e. Selenium Box)
While a cloud solution may be a good fit for some organizations, experience shows that with larger enterprises (especially in the financial field), security becomes increasingly important. In many cases, large enterprises cannot use a cloud service. An on-premise solution is often the best option.
Vendor managed solutions like the Selenium Box provide maintenance and worry free operation of the Selenium Grid and unlimited scalability options.
A vendor managed on-premises solution is therefore the best solution for all security sensitive organizations or for those who have high scaling needs.
Element34 Solutions GmbH
Contact & information: firstname.lastname@example.org
© 2018 Element34 Solutions GmbH. All rights reserved. This document contains information that is proprietary to Element34 Solutions GmbH. Selenium Box is intellectual property of Element34 Solutions GmbH. Other product mentioned herein may be the trademarks of their respective owners.