This is Part 5 of our automation series. Read Part 1 to understand of how to get started with automation, part 2 for insight into reducing the flakiness of your automated tests, part 3 to learn about CI for automation testing and part 4 where we cover the different levels of automation.

In modern times, web automation testing has become so common that “Selenium” is literally synonymous with it and fairly straightforward to use. However scaling selenium or web automation tests is more art than science. When we covered API testing in our previous post we mentioned about the intricacies of the new levels of testing. Web automation lies on multiple levels, in some products/projects they only have web apps hence web automation testing becomes the final level for their testing, in some other products/projects they use webview and web components in mobile applications and for them the web automation testing acts like an integration level testing.

At whichever level the web automation testing is done, there are two major aspects of web automation tests, one is maintenance of test scripts and the second is browser infrastructure.

For those looking to improve or fix their maintenance issues, our previous post related to reducing flakiness would provide a basic guide for you. For those looking to start or maintain their browser infrastructure the techniques mentioned in this post would definitely help you!

Cluster of Browsers

There are multiple ways of getting your browser infrastructure, you can package your tests inside a docker image along with a browser, however then you would be bound to only that specific browser for your tests. You can also try to bundle all possible combinations of browsers in the docker image with your tests, however then your docker container would be one of the heaviest. Selenium also provides browser based images for different browsers however then there is no unified view of your infrastructure.

One of the amazing tools out there is “Selenoid Configuration Manager”which you can use as shown in the diagram, it isolates your tests from the browser versions and at the same time helps you setup a cluster of browsers which can support a variety of browser/version combinations.

For example, if your tests need to be run on Chrome browser’s version 84, you can start Configuration Manager with those parameters and your tests instantly get access to the browser to run.

Web automation testing helps Paypay catch bugs on standalone web apps and also on webview and on web components. We are always looking to work with people with ideas and experience, feel free to join us as a full-stack tester. The next level of testing will be covered in the next month’s post.