Best Practices - Web Automation

LEAPWORK makes web application automation an effortless task. However, following best practice 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, we'll present best practices and solutions for tackling some of the challenges inherent to web automation. The best practices address:

• 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 your test cases, but when it comes to web automation, they are also often the most challenging to get right.

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

• Timeout in (sec): 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 instance, 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 afterwards. 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 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, you 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 you can create your own unique and reliable strategies by choosing a Unique Id, CSS, XPATH, Custom Attribute, or Text. If none of these work, you 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 web

LEAPWORK provides multiple building blocks for web automation,  to help handling  a variety  of situations: 

• 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 control dynamically, then use it to click the element.
  
  
• Strategies to be avoided: Avoid having text and image-based strategies in 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

Here are the three most common errors and how to solve 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, where 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 is shown when LEAPWORK is not able to find the browser window with the given criteria in the user's 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. Go here to see how you can fix it easily.
  

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 these 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 you select one of the drop-down options you will see three options that can be used as per your requirement: 

• 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 your page is long and you have an element that is far below and not visible to the user, you 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 best practice, you 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.