How to scale your tests with Selenium

Akansha Aggarwal
July 6, 2020

Introduction

Imagine everything is manual which is just a massive time sink, spending all of your time
upgrading browsers, upgrading the OS, restoring things when they get slow and you end up
in the situations like hung tests and crashed server which is totally unsustainable.

As challenges are always overcome by inventing something new. Primitive testing methods,
which the folks say, manual testing is the physical execution of test cases against various
applications to detect bugs and errors but the major disadvantages of this mode of web
application testing is that one can’t regressively test the functioning as well as the model is
more agile i.e. codes are churned and the development cycle is continuous in this method of
testing.

Today, automation is the new trend as it helps in speedy execution of test cases with
minimal human errors and it gives the advantage of re-testing. So, earlier, Licensed tools
such as RFT and QPT were the useful tools to provide regression test automation for various
platforms.

Selenium is an open source automated testing tool used to test web applications across
various browsers like Chrome, Firefox, Safari and operating systems like Mac, Windows,
Linux. It provides a playback tool for formulating tests without learning a test script
language. It contains a suite of tools namely; Selenium Integrated Development
Environment (IDE), Selenium RC, Selenium WebDriver and Selenium Grid.

If you want parallel execution of test cases or to scale by distributing and running tests on
several machines and manage multiple environments from a central point, making it easy to
run the tests against a vast combination of browsers/OS, then Selenium Grid is the solution.
It saves a lot of time.

Hub-Node Concept

It is the concept in which the test is run on a single machine (parent PC) i.e. the hub, but the
execution will be done by various machines i.e. the nodes (child systems).
The selenium has two versions ; Grid 1 and Grid 2. Grid 1 has been evacuated by the
selenium team, so, Grid 2 is being used these days. Grid 2 doesn’t need apache ant
installation, supports both Selenium RC and Webdriver scripts and up to 5 browsers can be
automated.

How to set up a selenium grid?

Here, I will explain the method to set up Selenium grid using Command Line.
Let’s take two machines where first one will be used as a hub and the second one will be the
node. You have to make sure that the IP addresses of the machines is noted. Following steps
will help in configuring the grid.
1. Download the selenium server.
2. Place the selenium.jar file in the C drive of both the machines. After doing this,
selenium grid is successfully installed.
3. Now, for launching hub, go to the first machine and navigate to the root of first
machine’s C drive (directory where selenium server is installed) by the help of
command prompt. Type java-jar selenium-server-standalone-2.30.0.jar-role hub on
the command prompt.
4. To verify whether the hub the running, simply open up a browser and go to
http://localhost:(first_machine’s_port)/grid/console.
5. For launching node, go to the second machine and launch a command prompt there.
6. Navigate to the root of drive C and type the code as follows:

java -Dwebdriver.gecko.driver=”c:\geckodrive.exe"-jar selenium-server-standalone-

3.4.0jar-role webdriver -hub http://Ip_address_of_second_machine/grid/register-
port xxyy

7. Go to the selenium grid interface and refresh the page.

Ways to Scale Selenium

To stay away from mechanization delay (slowing down of Selenium tests with time), tests
are run in parallel. There are five general classes of scaling:
1. Setup & Structure
2. Process
3. Architecture
4. Parallelism
5. Enterprise Support

Setup and Structure

a. Automated Build and Provisioning
Most IT groups produces a “build”, that may even run some unit tests.
Provisioning implies making an actual test server for any build. In some cases,
you may want to make and load a test database. This should be possible through
a command line tool.
b. Test Account Management
It may be conceivable to make a different confined record on each test run and
make information that solitary that account can see. The other option, re-
utilizing test accounts on the similar database, may “miss” things like one-time
occasions in the account arrangement process that quit working. Having the
information secluded may improve test information board. Rather than having
to re-make the whole database on demand, software engineers simply load a
standard arrangement of data to this record.
c. Tests Structured in suites, Tagged by Purpose
 In the event that the advancement bunch is sorted out in "groups of groups," at
that point the least unit, the individual group, likely has a particular element or
set of highlights it is liable for. A change to an element is probably going to break
numerous tests, which should be amended before the test suite can run. Rather
than registering the code into a master branch to perceive what fails, run it
locally, in any event against the tests that are connected. To do this, you will
want to “tag” tests and run tests with that tags. With a complex tagging
structure, it might be conceivable to run all the tests for a given feature on a
given browser, or on a particular platform, for example, the iPad. In the end, if
the architecture changes so you can deploy by feature, having these tags will
help “break the monolith.” Checking them by group will permit prior,
increasingly relevant testing.
d. Service Virtualization
Now and then the test infrastructure is too huge to even consider stimulating.
There are such a large number of APIs, an excessive number of conditions.
Rather than making a “test world” that incorporates test versions of the
considerable number of subsystems, provision a solitary subsystem, the false or
stub out the dependencies. More on this in the Infrastructure segment.

Process
a. Run different tests by team
Prior, I referenced organising the tests with tags. This is tied in with organising
the work so each team has a lot of tests that they can keep up. In a perfect, when
the tests run, the team will have the option send their own code to their own
convey point. This may require changes in infrastructure.
b. Focus on the whole Pyramid
At the point when the application resembles a black-box, and the role division
among test and writing programs is wide, it very well may be enticing to begin by
testing the GUI. That is where Selenium lives: at the top of the test tooling
pyramid. In any case, GUI tests are likewise the most fragile tests, the ones with
the largest delay and that are the hardest to debug. Not having low-levels tests
mean the software will fail more frequently (which means more automated tests
to cover, increasing the automation delay problem I referenced before). Teams
will need to utilize good code practices and lower-level tests to ensure that not
many problems are caught at the GUI level. To do that, teams should quantify
first time quality.
c. Measure and Improve first time quality
Take a Look at the number of failures that code changes create, particularly in
features outside the team. That is, a change in feature A, kept up by team Alpha,
breaks the code in feature F, maintained by team Foxtrot. Track them, and
accomplish the spade work with reviews to improve first time quality.
d. Mind the maintenance gap
Track how much time is spent “fixing” tests that are just “broken” in light of the
fact that the software changed, in this way the old desires for conduct are not, at
this point substantial. Discover the root causes and decrease them when the
situation allows.
Architecture
a. Build the total pipeline first, at that point include tests
It’s enticing to show progress by making tests first, and doing all the procedure
and architecture work later. Machine Delay, all things. considered, will take a
long time to get up to speed, and administrators like to watch screens that
mysteriously click on their own. Rather, go the other way: Start with one single
test, that runs end-to-end, unattended. That is, a build process that makes a
genuine test server and runs one simple test, either in the cloud or at least on a
build machine.
b. Isolate parts
If the event that the whole application is characterized as a monolith and the
build is slow, at that point testing should be thorough, which will mean additional
time and more tests. Notwithstanding, if each team has one or more deploy
points that can deploy in isolation, at that point just one feature can break in
turn. Sorting out the tests around these features implies a smaller test set to run.
These segments can compare to single web pages, APIs, or administrations like
login, tagging, search, making a profile, etc. Designing a mobile application as
isolated components can be particularly challenging, yet the tools to do this are
rising.
c. Extend tests with a broader tool
It is enticing to construct a test framework completely out of open-source tools.
All the things considered, Selenium and Jenkins are free, and the build scripts are
basic elements of the development process. When you include service
virtualization, components, tagging, provisioning, and reporting, the
infrastructure is essentially a software engineering project of its own. Planning,
running, and reporting tests, alongside “including” tests, turning them on and off
and coordinating the reporting alongside the human test effort, is considerably
more than a conventional continuous integration server was intended for.

Parallelism
a. Consider running the matrix in a public cloud
In the event the production code is as of now utilising a private cloud (e.g., with
something like Kubernetes or OpenStack), it might be possible to re-utilise that
tooling to organize an internal grid. And, after this all said and done, running on
multiple browsers and operating systems could be challenging. It may be simpler
to re-utilise an existing public cloud or cloud offering. Indeed, even that can
introduce security challenges; build a proof of concept before focussing to a
solution.
b. Create a test runner
This is a tool that takes a tag (or combination of them), may be a branch or
build, and a platform (browser, operating system) and runs the tests, reporting
to a single reporting source. Each trial may require a unique ID to report back to.
That reporting source could be a database. It is likely the runner and reporting
system are part of the larger tool written under the Architecture section.
c. Consider multiple test web servers
 The greater part of the discussion about running tests in parallel is tied in with
running the tests against a single server. Sometimes, it will be difficult to isolate
those tests. One alternative is to make different test servers, test databases, and
test API systems.

Enterprise Support
a. Visualize and scale reporting and analysis
With a venture like undertaking Selenium, executives will pose new inquiries. For
instance, they might want to know how long the tests are taking to run, what
number of are failing, how the failing is changing after sometime, are the failures
a similar issue again and again or new issues? It is safe to say we are “missing”
tests or do we have too much? Dashboards with test runs after sometime,
separated by tag, joined with the capacity to penetrate in, can assist the board
with settling choices on what to put resources. They can likewise help with
troubleshooting, fixing, recognising issues and taking corrective action.
b. Purchase commercial support or training
Figuring out how to scale Selenium is more than figuring out how to use a code
library; it is learning to incorporate that code library, alongside the examples that
make it scalable. At the very least, create internal expertise and roll out tooling
gradually, hoping to either fund a new testing role, or for development to slow as
the team figures out how to use a new tool.