Avoiding common pitfalls when working with capture/replay

It’s the easiest way to start with test automation. For everyone. Click the ‘Record’ button, perform some mouse and keyboard actions, stop the recording, and finally replay all the recorded steps again to see how automation works. Sounds simple. But is it? When talking about capture replay with experienced test automation engineers, you almost always receive  the following advice: “Don’t touch it!” But what is reason for this?

Let me mention only a few points, which cause testers to think negatively about capture replay:

• Replay won’t work on different resolutions or window sizes because of coordinates captured within a script.
• Difficulty to maintain generated scripts.
• Impossibility to reuse recorded tests.

In short: Over the last 15 years Capture&Replay became discredited, because of not being able to maintain generated scripts after creation.

When looking at the Ranorex tools in general, it wouldn’t be necessary to provide users with Ranorex Studio around the Ranorex automation library, if the Ranorex Recorder is the all-in-one tool suitable for every automation purpose.

But how does Ranorex Recorder try to solve those issues?

The most important approach is the total separation of identification attributes and values from the automation part allow it to maintain existing recordings, without the need of editing the generated script behind. Additionally, the automatically generated code can be directly reused in hand-written test scripts (if the user wants to).

In the following section, I’d like to suggest how to best create, clean up and modify recordings, their repositories included. As an example, I’ve recorded some actions performed on the Ranorex web page.

Thinking about what should be recorded

Before starting a recording session it could be beneficial to think about what exactly has to be recorded. That helps to minimize the clean-up work afterwards. On the Ranorex web page we do the following:

• Open the menu item ‘Product’ | ‘Features’
• Validate the caption text of a picture
• Check the search feature
• Fill out the download  form
• Check the ‘Release Notes’
• Go back to ‘Home’

Here is a screen shot of the newly generated  and unmodified recording.

Cleaning up recorded actions

After finishing the recording, it is advisable to look at each recorded action item in detail. The recorder offers some editing features to clean up the sequence, for example, merging key sequence actions.

In default case the recorder records the mouse click location performed by the user relative to a button or a text field. It’s possible to turn that off in advance within the Recorder’s configuration dialog. Alternatively, you can also change the click location afterwards within the properties dialog.

The more recorded actions you have after finishing a recording, the less clear each single action becomes. Use the comment field to describe at least some of the important actions. That makes the recording easier to understand. These comments will then also be added as code comments, helping you to structure the test script.

Cleaning up the generated repository

The repository stores all the UI elements used within the recording and can be seen as some sort of mapping file. Each recorded action is connected to a single repository item. Each item refers to one RanoreXPath expression necessary to identify the object. The names used for the items and folders of the repository are generated automatically. It is recommended to rename them if necessary. In addition to that, the structure of the repository is generated automatically as well. The idea is to reduce redundancies in order to ease maintenance when the AUT modified.

Use logical folders to create additional structure. Use a logical folder to group single pages, menu items, or a log on form with user name and password text boxes. Also, already existing rooted folders can be used for grouping as well.

Both pictures above show how to prepare RanoreXPath expressions for a more robust test automation sequence. Optimizing the path of a rooted folder could be useful when changing RanoreXPath expressions on a child item level. The ‘Abbreviate Item Path’ feature can be used to shorten the RanoreXPath. This helps to minimize replay failures, caused by changes within the UI structure of the application under test.

After cleaning up the recorder actions table and the related repository, it  looks like that:

Most of the cleanup time has to be spent within the recording’s repository. But after changing names, folders and RanoreXPath expressions the repository is more logical, and can be used for new recordings as well. Save the repository to an external location in order to reuse it for new recordings based on the same UI.

As you can see, it is possible to get more out of recordings. But it’s necessary to be aware what was recorded and how are the elments of the UI are identified.

In my opinion, powerful UI mapping is the main requirement for robust test automation, regardless whether automation is based on simple actions listed in a recording or pure automation code.