Tips and tricks Best practice guides, FAQ & more
Websites and web applications are crucial to how businesses acquire customers, and a growing number of traditional front and back-office applications are migrated from desktops to web-based interfaces. As web technologies come with their own challenges, being able to test them is highly critical.
IT landscapes across organizations are becoming increasingly simplified as more applications and services are migrated into a single technology (web-based), but it also comes with some risks:
To deliver a great end-user experience, web applications and websites must work across multiple browsers, browser versions, operating systems, and devices, including mobile.
With all the possible combinations, the number of usage scenarios to be tested increases exponentially. One provider of hosted environments for automated web testing, Sauce Labs, have identified more than 2,000 devices and more than 800 browser-OS combinations – and those are just the most commonly used.
From a testing perspective, a major challenge presents itself: Is it necessary for your organization to host all the possible combinations of browsers, operating systems, and devices in your own infrastructure to support automated web testing?
This would come with additional costs and a massive administrative burden negatively impacting the business case for test automation.
Fortunately, there are several options available for offloading or outsourcing the hosting of test environments.
Whether you need to test your application in a specific version of a browser, do cross-browser testing of a website, or run automated tests on mobile devices, you can utilize one of several cloud-based providers of web automation environments.
Examples of providers include:
The main differences between these vendors are their pricing model and to what extent they rely on real devices versus emulators.
What follows is a walk-through of how to use hosted environments for web automation. Besides access to a provider of hosted environments such as setup only requires a few things: A suite of automated test cases ready to be executed and a service running the test cases. In the following, the test runner service is called the Controller.
Here’s how the setup works:
With this setup, a test team does not have to worry about preparing and maintaining the machines and devices on which the test cases are executed. For example, it is not necessary to purchase, maintain, and charging a bunch of different mobile devices.
FIGURE 1: Executing web automation with hosted environments
All automation taking place in the hosted environments as described above is based on the open-source framework for automated web testing, Selenium. This means that any test case created with Selenium can be executed in the hosted environments.
Selenium-based test cases can be created either by hand-coding them, or—much more efficiently and scalable—by generating them with an automation tool that uses the Selenium framework as its web automation engine “under the hood”. This is the case with the Leapwork Automation Platform.
Once an automated test case is running, the Controller feeds Selenium-based commands to the hosted environment in which a browser will perform a test of a website or web application. This is illustrated in Figure 1.
Before running an automated test case, the Controller needs to instruct the environment provider to set up the required environment. As mentioned earlier, the combinations of variables for defining the environment are practically endless. Consider the following equation:
Test environment n =
Device a × OS b × OS version c × Browser x × Browser version y × Screen resolution z × …
The Controller will convey to the provider all information about the variables that define the environment.
If the system under test, e.g. a website, is accessible in the cloud or somewhere else outside a company’s firewall, then it usually requires little or no additional configuration for a browser in the hosted environment to access the website.
FIGURE 2: Direct vs. Proxy-Based Access in Web Automation
However, if you need to test an internal website placed behind a corporate firewall and if Security does not allow opening ports in the firewall, then browsers in hosted environments won’t be able to directly access the website under test.
In this case you need to do a bit more configuration of your setup. The additional work required is minimal, so this shouldn’t discourage you.
The solution, which is offered by most providers of hosted environments, is for the Controller to serve as a proxy between the internal website and the browser performing the automation commands.
In practice, this means that the Controller will open a connection to the hosted environment, and then all traffic from the browser in the hosted environment is sent through the Controller to the internal website and back again. The "Direct Access" and “Proxy-Based Access” setups are illustrated in Figure 2.
Hosting all the possible combinations of browsers, operating systems, and devices in your own infrastructure to support automated web testing would be very costly and time-consuming.
You can utilize cloud-based providers of web automation environments to offload or outsource the burden of hosting.
Ready to get started with web testing across browsers and devices? Then start your Leapwork trial today.