Automating Web Applications

Automated Execution of Web Applications, when used as part of a Test Strategy is known as Web Test Automation. The two most commonly used programmatic libraries are WebDriver and Playwright. This section provides an overview of automating and resources to help.

How do we automate Web Applications?

The two most common ways of automating web applications are:

  • automating a browser and simulating a user
  • automating the sending of HTTP requests as though they were sent by a browser

As Web Applications have become more complex, with more functionality implemented through the browser interface, the most common way to automate browser applications is to use tools that automate the browser.

These tools typically use browser interaces e.g. the Chrome DevTools Protocol or the WebDriver Bidi Protocol.

Other approaches inject JavaScript into the running browser page and automate through JavaScript commands. This was the approach taken by early versions of Selenium, and tools like Cypress use a more advanced version of this approach.

Most Web Automation requires programming skills to write short methods which are run by an automated execution framework like JUnit, pyTest, Jest, etc. Although there are some frameworks which are designed to be ‘codeless’ and used by people without programming skills.

A fully rounded Test Strategy would also incorporate Unit Testing of the Web Application, prior to using any Browser Automation tooling. This Unit Testing would automate Web components in isolation, functional domain and object testing, APIs without server deployment. By splitting the coverage responsibility across the technology stack teams can avoid having to write ‘all’ their tests as End to End Browser Tests which require a server deployment. This will reduce run time of the automated execution and make the automated coverage easier to maintain as the application evolves.

What Tool Should Be Used for Web Automation?

There are so many tools available for Automating Web Applications that it can be very hard to choose.

The main considerations will be:

  • Does your team have the necessary programming skills?
    • If not, are you prepared to train them?

If not then you are excluding any tool that requires programming ability. These are often the most popular and free tools e.g.

  • Playwright
  • Selenium WebDriver
  • Cypress

You would then be looking for a ‘codeless automation’ tool. You should undertake a comprehensive comparative evaluation and be very careful because you will find it much harder to migrate from a codeless automation tool to another tool. There will be very little re-usable content and vendor lock in should factor into your evaluation.

You should also consider if you can defer the automated execution activity until you have the appropriate skills sets. An alternative strategy of boosting the Automated Unit Coverage and building the Automated Execution Coverage alongside the production code, as a programming responsibility, and then adding Exploratory Testing into the test process might be appropriate.

If you do use a tool that requires programming ability then it is important to remember that writing code for Automated Execution requires good programming skills in order to create code that is robust and maintainable. There are too many case studies of ‘flaky automation’ and ’expensive to maintain test suites’ which are used to justify not automating, and using a ‘codeless’ tool. The actually reality is that automating is a skill, and people skilled in Automated Execution will create robust and easy to maintain coverage.


Selenium WebDriver

Overview of Selenium WebDriver