Tips and tricks Best practice guides, FAQ & more
With Leapwork, automation is designed as flows. In test automation, a flow is a test case and in RPA, a flow is a business process.
Designing automation flows is done in the Flows module of Leapwork Studio accessible from the main menu.
Flows are organized in folders (more about organizing your work here), and you can create a new flow in any location in the tree-view of the 'Flows' menu. Either press 'New' and select 'Flow', or right-click anywhere in the tree-view and select 'New flow':
When a new flow is created we can see the below options:
Flows in Leapwork are designed by connecting visual building blocks each representing and performing one or more operations, like “Click element”, “Start application”, “Find Web Element”, etc.
By default, a newly created flow contains just one building block, the 'Start' block, located on the Design Canvas.
Before diving into the details of the actual design of flows, there are a few essential features related to the Design Canvas that are useful to know:
Clicking this icon allows you to pan the Design Canvas and move the flow in all directions. This can also be done by pressing the Space bar.
Use this functionality for zooming in on individual details or zooming out to gain overview. Either pull the slider or use the scroll wheel on the mouse to zoom.
This function will adjust the zoom to make the automation flow fit within the canvas pane. Seeing the flow in its entirety helps by giving an overview. If one or more building blocks (see later) are selected, then the zoom-to-fit functionality will adjust the zoom with respect to the selected blocks.
The Preview Environment module is covered in depth later in this document.
The purpose and functionality of the building blocks used to create automation flows are each fully documented here: The LEAPWORK building blocks.
In an automation flow, building blocks are put together using Connectors. There are two kinds of Connectors in Leapwork Studio; green and blue.
To add a new building block, simply hover over the green Connector of an existing building block, e.g. the Start block, and then use the mouse to pull the green Connector in any direction. When the mouse is released a library of all the Leapwork building blocks is shown. From this list, you can either use the mouse to select a building block or simply type the name to filter the list:
In the example below, a Start Web Browser building block is added after the Start block, with the green Connector indicating the direction of the flow:
The second Connector type is the blue Connector, which is used for transferring values between building blocks. Blue connectors are not driving, or interfering with, the execution of the flow, so it is possible, and quite common, to have both a green and blue Connector between the same two building blocks.
In the example below, the content of a field in a web page is read by the Get Web Text building block and this value is outputted to the activity log using a Log Message building block. The blue Connector is transferring the value between the building blocks, and the green Connector makes sure the building blocks are executed in the right order:
An important part of designing automation flows is the verification of the flow executed: Did the test case pass? Did the automated process complete all tasks?
Typically, you build verification into the flow using the building blocks, and then add a Pass building block if the verification is successful.
For example, consider a login process to an application: After entering credentials and pressing 'Log in', the verification would consist of finding something in the application that confirms a successful login. It could be the name of the user logged in, the appearance of a given menu element, etc.
If a flow run ends without hitting a Pass block, the flow run is by default considered failed. This could happen if a given element or state is not obtained – like in the case of a failed login. Leapwork comes with a specific Fail building block, but you don’t have to add it to handle all failed scenarios; if a Pass block signifies the end of a successful execution, then all other execution scenarios will by default be logged as failed.
In the example below, a value from a web page is compared to a static value ('test automation'). If the two text values match, the top green Connector is triggered, and the flow is passed. If the values don’t match, the ‘Incorrect’ green Connector is triggered, and because no further building blocks are added, this flow would end in status 'failed':
Flows can be branched to follow different paths depending on what happens during the execution. In the previous section we saw how to use a Compare building block to inspect a value from a web page and drive the flow in different directions depending on the outcome of the comparison.
Another example of how to branch a flow, which illustrates the behavior of many of the building blocks in Leapwork, is to look for a certain image on the screen using a Find Image building block. If the image is found, the top green connector is triggered. If the image is not found within the time specified in the Timeout (sec) property, then the ‘Not found’ green connector is triggered:
Running through a list of values, rows in a table, a list of identical icons etc. is an action commonly performed in an automation flow. With Leapwork's visual flowchart approach, looping is easily done.
The simplest way to loop is to use the Loop building block. It simply runs through a list a numbers, from Minimum to Maximum. For every value (1,2, 3…10), the building block will trigger the top green Connector:
In the example above, the Log Message building block is executed 10 times, each time recording the current number in the activity log. After all iterations are done (1,2…10), the Completed green connector is triggered, and the Pass building block is executed.
Driving automation flows using data from external sources is a powerful and common discipline in automation. This makes the individual automation flow more flexible and capable of covering more scenarios. Furthermore, the flow does not need to be changed to handle another data set; this is handled in the data repository.
The example below shows how to use the Read Excel building block to read data from an Excel sheet on a local drive and use the data directly in the flow. In this case, the data entries are used to set values in a desktop application:
Besides Excel-sheets, the Leapwork Automation Platform comes with data-driven building blocks to handle integrations with:
Once an automation flow has been verified to work as expected and has proven to be robust and stable, it is time to consider if parts of the flow should or could be reused in other flows.
In Leapwork, a reusable part of a flow is called a Sub-flow. A Sub-flow can be reused across automation flows and/or be reused multiple times in the same flow.
The example below contains a Sub-flow named ‘Searching and calculating’ including a couple of input parameters:
To create a Sub-flow, simply select the building blocks that should be reusable, right-click, and select ‘Create a Sub-flow’. Enter a name for the Sub-flow and press OK. All the selected building blocks are now wrapped into one new building block; the Sub-flow.
An important part of making an automation flow robust and reliable is to be able to preview the flow. This gives you a chance to correct issues and to test the robustness of the flow while designing it.
To do a preview run of a flow, simply click on the Run button on the top right corner of the Design Canvas:
This will run the flow on the local machine, allowing for debugging and verification. When the Run button is clicked, Leapwork Studio will minimize and the flow will start running. Once the flow ends – either passed or failed – Leapwork will maximize and regain focus.
After a Preview run, the Preview pane is available. It consists of three elements:
All three elements are correlated and can be inspected simultaneously, so scrubbing the video will make the orange border move between the building blocks on the Design Canvas and will make the highlighted element in the Activity log change accordingly. Selecting an element in the activity log, on the other hand, will move the video to the time where the activity log entry was added:
The combination of the debug view, the video, and the activity log is a very powerful and intuitive tool for finding failure reasons and for handling unexpected behavior in the flows.
To go into edit mode again after a Preview run, click the edit button or simply double click on the grayed out Design Canvas.
An alternative way of doing a preview run is to right-click on a given building block in the flow and select 'Run flow from here'. This will execute the flow from the selected building block just like a normal preview run. This feature allows for a very productive way of designing the flows; add a few building blocks and then just run the newly added building blocks to verify that these works. This saves you a lot of time by not having to rerun the entire flow to verify minor changes.
Right of the Run button is the Preview Environment which allows you to specify which Environment you want to execute the preview run on. An Environment is basically a pointer to a machine or device where the automation flow can be executed:
Leapwork automatically adds a temporary environment for each display (screen) that is defined for the local machine. These are shown as ‘Local (Display #)’. The first display is selected by default which means that the automation flow will run on the local machine with applications and automation starting up on the selected screen. The automation flows do support multi-screen automation, so it’s just an indication for the start of the flow.
All other defined environments are shown in the list of available preview environments following the display entries. By selecting one of the defined environments as target for the preview run, Leapwork Studio is instructed to open a connection using the information for the environment and run the automation flow in that environment.
To be able to see how the flow is executed, Studio will show a live stream from the environment as part of the Design Canvas. This feature is available for all types of environments.
To prevent overriding other users' work, Leapwork will warn users when opening flows or sub-flows if these are being edited by someone else. The warning will contain the name of the user who is currently editing the flow/sub-flow, and the user can choose to override the warning, with the risk involved.
Version control is available for users with Administrator and Contributor roles. Leapwork supports version control of both flows and sub-flows. Every time you click save, a version number is set, and Studio will prompt you to enter a short description of the changes made to the flow:
This description will be available from the version history in Leapwork, giving you both the possibility of reviewing changes made, and to restore and preview earlier versions of the flow.
Right-click on a flow or sub-flow to get access to Version History:
The Version History pane looks like this:
When in this module, you are enabled to take any of the following actions for each version:
By selecting the Preview option in the Version History pane, the previous version in question is opened in preview mode:
When restoring, it is important to understand how Leapwork performs the restore. Leapwork lets you choose between three different restoring approaches:
Only Flow: This option only restores the flow's design in terms of intended steps and actions. However, Locators used in the building blocks are the most recent ones. This means, that if you made an update to a building block, e.g. captured a new element, it is the new element that continues to be used in the restored version.
Full Restore: This option not only restores the flow’s design to its previous version, it also re-apply previously captured Locators of that same version. If the application automated has changed since the creation date of the flow version being restored, this may cause the flow to fail. This is a good example of relevant information to put into the 'Save information' prompt; changes done within specific building blocks.
Full Copy: This will restore the flow’s design and make a copy of all used Locators:
The Delete option in the Version History pane will delete the corresponding version data and remove it from version history: