Planet Test Automation: First Steps Automating Web UI Testing

7 min readOct 16, 2019

This article complements corresponding webinar from the Planet Test Automation series we are running at Inflectra. Once the recording of the webinar is available it will be referenced here.

Many of us plan to test a web application. Some want to automate this process. To help making first steps with automation we’ll make an overview of base concepts and basic work flows. We’ll be using UI Test Automation Playground web site for illustration and demonstration purposes.

First, we need to learn more about the object of testing.

Entering Orbit: Web UI

Web UI from perspective of a manual tester and from perspective of a test automation tool look very different. While a human during testing mostly does image recognition, a test automation tool works with an application as a tree of elements with attributes. This tree is referred to as Document Object Model (DOM). You can see it on the right side of the picture.

Web Application from Test Automation Tool Perspective

DOM Tree

In UI test automation DOM tree is used to find elements, read and write their attributes. Let’s see how a user name field may look in DOM.

<input class=”form-control” type=”text” placeholder=”User Name” name=”UserName” id=”790300dc-eba7–7097–2b17- 729d32977850" autocomplete=”off”>

This is a DOM node. It has a tag (input) and attributes (class, type, placeholder, name, id, autocomplete) with values.

As different application screens look different for a user, they also have different DOM trees and look different for a test automation tool.

Note: Many of the elements in DOM have no visible representation on screen.

Element Identification

To find an element in a DOM tree an automation tool may use different ways. Most frequently used are XPath and CSS selectors. During recording of a test and automation tool builds selectors automatically, but it also possible to build selectors manually.

For example, in manual test specification we say “user name field”. In automated test we say “a DOM element with //input[@name=’UserName’] XPath selector”.

Interaction with Elements

An automation tool may interact with elements on a page by sending browser level DOM events or by emulating hardware keyboard and mouse at OS level. DOM events enable testing using headless browsers and parallel testing (we’ll talk about it a bit later) but they may not always work. OS level keyboard and mouse emulation always works but is not compatible with headless or parallel testing.

On the picture we have an example of an application that does not process DOM level events correctly. Though it seems that Username and Password have values when we press Login button the system complains they are empty. Check out Click and Input Text puzzles for more details.

Synchronization

It is easy for a human to wait until web page is completely loaded or click a button again when there is no response from a page. To act like a human an automation tool can wait for a specific DOM state using fixed time or regularly check for desired object state within a defined timeout. Usually such behavior can not be recorded and should be manually added to an automated test. Synchronization steps may look like this.

Check out Load Delay, AJAX Data and Client Side Delay puzzles to play with synchronization.

Landing: Make a Test

Now we have an idea of how a web application looks like from test automation stand point, how elements are identified and what are the ways of interacting with elements. It’s time to make a test.

An automated test is usually either recorded or scripted.

Recording

During recording an automated tool remembers selectors for UI elements to reuse them at playback time. Also, during recording the tool captures interactions (mouse clicks and keyboard input). As a result, we get something like:

Each element we interacted with during recording is now in the object tree (left top corner), for each such element a selector was automatically generated (XPATH highlighted in the left bottom corner). And we have sequence of steps and data to use in the spreadsheet view (right half of the picture).

Scripting

Another approach is to manually build selectors and put test steps into a script.

Building a Base: Execution of Tests

When tests are ready it is time to execute them. Execution can be headed or headless.

Headed Execution

Headed means that browser UI is displayed on screen when a test is running. It is good for troubleshooting of a test and when OS level events are used to interact with an application.

Headless Execution

Chrome and Firefox provide a headless mode. In this mode UI is not displayed but pages are still rendered. Since there is no UI on screen, we can run tests and continue working on a machine and we can run tests in parallel, they won’t interfere with each other.

Remote Execution

WebDriver protocol and its Selenium implementation allow to run Web tests on remote machines. You just need to specify a URL to Selenium server.

Colonization: Maintenance of Tests

When we have our automated tests ready it is just the beginning of the journey. Then we enter test maintenance phase.

Why Maintenance is Needed?

Developers update applications we test, browser vendors update their browsers, operating system vendors update their operating systems. These changes may break automated tests. And it indeed happens from time to time. If we want to continue running our tests, we need to fix them. It is called maintenance. There are basic mechanisms that help investigating why tests failed and aid with fixes. The main purpose of such mechanisms is to reduce time required for test maintenance.

Flash

Most typical reason of a test failure is when a specific element is not found on screen.

So, first thing to do is to flash the element and check that element selector is still valid or not. May be the problem is that we did not wait long enough for the element to appear on screen.

In this video fragment we select an object in the object tree and try to flash it in the application.

Re-Learn

If selector of an element is no longer valid, we may re-learn it. We can point to an element and let the testing tool to rebuild the selector for it.

Web Application Profile

If we have to fix a selector frequently it may be an indicator that automatic generator of selectors should be better configured. In Rapise, for example, we can create a Web Application Profile and instruct the generator what attributes and class names to use.

If we record a test for the Sample App the selector for User Name field may look like:

//input[@name=’UserName’ and @id=’1b4e7fcd-4d40-a0d4-c952–1af8989d81b2']

If we reload the application and try to flash UserName it won’t work. If we re-learn the selector it will be something like:

//input[@name=’UserName’ and @id=’00898348-ac1c-caa9-b2af-acf56f5caae8']

Obviously, ID of the element is dynamic and it is different every time we load the application. With Web Application Profile we can instruct the recorder to ignore such IDs. So, after recording we’ll get a selector where ID is not used.

//input[@name=’UserName’]

Self-Healing Locator

Another option (available in Rapise) to save time on test maintenance is to enable Self-Healing Locators. When this option is enabled Rapise records not only selectors but all attributes of an element and its ancestors. During playback Rapise tries to find most suitable element when traditional selector returns no result.

Web Spy

And of course, the main tool to explore the DOM tree is Web Spy. Use it to test hypotheses to build a better Web App Profiles and analyze changes in the application you test. With Web Spy you can find an element in the DOM tree, test XPATH or CSS query and even save/load and compare page snapshots.

Wrapping Up

Web applications look differently from perspectives of manual testing and test automation. What is easy for a manual tester may require additional efforts from a test automation engineer. Automated recording of a test does not automatically produce a 100% ready test.

You may need to make a choice between browser and OS level keyboard/mouse events.
You may need to adjust a test to wait for application to become ready for interaction.
You may need to deal with and understand Document Object Model and XPath queries.

When tests are ready you are in front of a choice of how to execute them.