Best Practices - Web Automation

Leapwork makes web application automation an effortless task. However, following best practices is essential to avoid challenges when testing with multiple platforms and browser configurations. This article covers some of the basics of working with web automation.

In the following article, we'll present best practices and solutions for tackling some key challenges inherent to web automation. Some of the best practices that will be addressed in this article are listed below:

• How to handle synchronization
• How to tackle dynamically changing web elements
• What to avoid while automating web
• Handling common errors
• Handling scroll on web pages
• How to perform parallel/distributed testing

How to handle synchronization?

Synchronization and timeouts govern the stability of our test cases but when it comes to web automation, they are also often the most challenging to get it right.

Leapwork has in-built features to handle synchronization and timeout challenges in any type of web test case scenario. The below fields are accessible via relevant building blocks in the Leapwork studio:

• Timeout in (secs): The maximum time spent searching for the web element before giving up and triggering “Not found”. This is an implicit timeout.
• Await DOM Change: The number of seconds the DOM must have had without changes before proceeding.
• Await Request: Delay the search for the web element until there have been no active XHR requests for a specific period – For e.g.: 3 seconds.

How to tackle dynamically changing web elements?

Leapwork allows the user to capture web elements manually or with a recorder. While capturing a single web element, Leapwork's smart algorithm intelligently generates multiple strategies for the same element, and by default picks the best-suited strategy for the task at hand.

In some cases, it’s been observed that the selected strategy works the first time, but stops working later on. This is a classic example of a dynamic element with a changing element property in the application's back-end.

Let's take the example below:

Leapwork picked a cart element by Id (in this case, the Id equals sq3r4t3422444adsesa) but that Id is dynamic in nature (i.e. the Id changes after release/deployment), so the next time the Id becomes sq974t67856785adsesa.

To handle such scenarios, Leapwork has a strategy editor that suggests all other locators in the left-hand-side panel. As the user, we can pick one of the most static strategies to make sure that the element is captured correctly every time.

The strategy editor also has its own editor interface (seen below on the right-hand-side), where we can create our own unique and reliable strategies by choosing a Unique Id, CSS, XPATH, Custom Attribute, or Text. If none of these work, we can use multiple DOM elements in a parent-child relationship.

For more information about how to use Leapwork's strategy editor, please follow the links below:

• Working with web editor- I
• Working with web editor- II

What to avoid while automating the web?

Leapwork provides multiple building blocks for web automation,  to help to handle a variety  of situations: 

The following best practices must be followed while automating the web:

• Avoid using the ‘Wait’ block: The Wait block will force a test to stop for a specific time. The Wait block also usually slows the test and increases the time of execution, so it’s advisable to avoid using this particular functionality in test automation.

• Avoid using the 'Positions' block: Avoid using static positions while using the 'Click position' method, as it will fail for different resolutions and browsers. Instead, use the relative position or get the position of the control dynamically, then use it to click the element.
  
  
• Strategies to be avoided: Avoid having text and image-based strategies on the web, as text-based strategies might fail if the language in the application is changed (e.g. English to Danish). Similarly, web tests are responsive in nature, which means the images and applications are subject to change with the resolution.

Handling Common Errors

Below are the four most common errors and how to resolve them:

• Web element was found but isn't clickable: There can be various reasons for this issue. The first one is usually a timing issue. The user has to apply proper waits so that the application is loaded to receive the click. Try using Leapwork's 'Awaits' block feature to handle this issue. A second reason could be that there is another component on top of the control that receives the click instead of the target web element. To resolve this type of issue please check this article.
  
  
• No browser window detected: This message appears when Leapwork is not able to find the browser window with the given criteria in the Use Browser Window building block. Try using other search criteria to fix it.
  
  
  
  
• Could not open Chrome: This error message is shown when Leapwork can’t find the Chrome.exe file in its default location. In a 64-bit Windows operating system, the location is usually 'C:\Program Files (x86)\Google\Chrome\Application\Chrome.exe'. In 32-bit Windows operating system it is 'C:\Program Files\Google\Chrome\Application\Chrome.exe'. Click here for more information.
  
  
• Web Element not found in 10 seconds: If this error message appears, it could be due to a synchronization handling issue. Click here to look for steps to resolve this issue.
  

Handling scroll on web pages

By default, "Click Web Element" & "Type Web Text" automatically scroll to the element where it needs to perform click or type operations. However, there can be many scenarios where the user needs to perform a scroll without the need to click or type. In that kind of scenario, the user can choose one of two methods:

• Scroll to Find
• Scroll into View

Scroll to find:

The Scroll to Find option can be found in all input blocks as a drop-down (see the picture below) and can be used to scroll up or down. This can be useful when searching in long-form content such as web pages where elements are loaded asynchronously, e.g. using infinity scroll. Once we select one of the drop-down options, we will see three options that can be used as per our requirements: 

• Max repeats: The maximum number of times to perform a scroll before giving up searching for the web element
• Amount: The amount of scrolling that will be performed on each scroll
• Delay (sec): The delay in seconds between each of the scroll amounts

Scroll into View:

If our page is long and we have an element that is far below and not visible to the user, we can use the Scroll into View option in the Find Web Element block. When users select this checkbox, any found web element is automatically scrolled into view.

With a combination of the above two methods the user can easily handle all scroll up/down and scroll into view operations. 

How to perform parallel or distributed testing

Leapwork supports the execution of automation flows on remote computers. This allows for flows to run uninterrupted and provides the possibility to run the same flow in different configurations in parallel or pairwise. Running a test in parallel helps to:

• Reduce the time of execution thereby reducing time to market
• Provide faster feedback, which means finding and fixing bugs quickly
• Test on multiple configurations simultaneously to get maximum coverage

As a best practice, we should always try to run a test in parallel. Here is an article that explains how to configure Leapwork for parallel and pairwise testing.

If you have any questions, please contact our Priority Support.