Best Practices - Organizing Daily Work in LEAPWORK

LEAPWORK's user interface has always been all about speed, ease of use, and productivity. Users can create and organize folders, flows, sub-flows, and the underlying elements in multiple ways, as these are logically separated and can be structured as per user needs. Users can create a hierarchical folder structure, and perform drag and drop on the flows/sub-flows to organize them into the folders. This unique attribute of LEAPWORK's design and user experience makes it easier for all kinds of stakeholders in any size of team to manage testing efforts efficiently, for great success.

There are some generally recommended models that help in organizing projects to increase productivity and lower maintenance while ensuring consistent scalability. These models are:

• The Project/Feature-based Model
• The Page Object Model
• The Hybrid Model

We will discuss each one of these in detail and give examples to help you out with best practices for each model.

Project/ Feature-based Model

About the structure

In this design, the user should structure their test flows according to the project/program and features. This means that the top-level folder will always be a folder that has the project name, and that project will be segregated into multiple folders with feature names where each feature folder contains one or more test flow(s). Each flow will have the corresponding assets, e.g. elements, images, data files, etc.

Best practices when implementing in LEAPWORK:

Folder Structure, Flows, Sub-Flows, and Assets:

Most of the structural aspects can be achieved with the right folder structure.

• Create a top-level folder with the name of the project
• The project is usually divided into features/epics/user stories etc. Keep the same structure and divide the project into epics, user stories, and/or logical features, then create them as a corresponding folder(s).
• Some agile-based implementations use the sprint in order to segregate the test flows. So, sprint-based categorization is recommended for such implementations

A feature might have multiple flows and hence all the corresponding test flow(s) should be kept inside these feature folders. Some of the flows might have common functionality which should be converted into a reusable sub-flow so that all flows use that common sub-flow, thereby making it reusable, easy to maintain, and straightforward to scale.

• Keep the test flow(s) inside the feature folders
• Add feature specific sub-flows in the same feature folder for easy access. For easy identification, sub-flows can further be grouped in a sub-flow folder inside the same feature folder.
• The sub-flow that can be used across features should be placed in a global or common sub-flow folder so that it is easy to identify and reuse.

Each flow contains all the captured elements, images, data files, etc. These assets are recommended to be kept inside the flow itself.

Below shows two ways to use the above model:

Example: Project and Feature-Based	Example: Project/Feature with AGILE Sprints

Page Object Model

About the structure

Page Object Model is a popular design in test automation where you can create an object repository for UI elements separately. The advantage of the model is that it reduces element duplication and improves test maintenance. This model is most applicable for the applications that contain multiple pages, and where each of these pages has fields that can be uniquely referenced with respect to the page.

Best Practices to implement in LEAPWORK:

Folder Structure, Flows, Sub-Flows, and Assets:

The structural aspects can be achieved by choosing the right folder hierarchy:

• Create a top-level folder with the name of the project
• The project is divided into two folders, e.g. 'Object Repository' and 'Flow Repository'.
• The object repository folder has the feature folders where feature specific objects (assets) i.e. captured elements, images, and data files are stored
• The corresponding feature folders are created inside the flow repository where feature specific flows are placed
• The feature-specific sub-flows are placed in the same feature folder for easy access. For easy identification, sub-flows can further be grouped in a sub-flow folder inside the same feature folder
• A common sub-flow folder is also created inside the flow repository folder to keep the commonly used sub-flows so that it is easy to identify and reuse
• Few agile-based implementations use the sprint in order to segregate the test flows. So, the sprint-based categorization is recommended for such implementations

 Below is an example that explains a way to use the above model:

Example: Page Object Model with Feature Flows

Hybrid Model

About the structure

The hybrid model is the combination of two or more primary (traditional) models, which can be modified as per the business requirements. This is a flexible yet controlled model that can be manipulated based on your automation requirements and methodologies. We recommend using the hybrid model whenever the user wants to obtain the features of two models in a single model. This model is good to use when your teams are following mixed developmental (scrum, kanban, waterfall) or release strategies (daily, weekly, quarterly releases) with multiple environments.

In this structure you can create test flows focused on the current release without following any specific structure. The focus is on the organization of the test flows, rather than features or assets/objects.

Best practices for implemention in LEAPWORK:

Folder Structure and Flows:

Most of the structural aspects can be achieved with the right folder structure.

• Create a top-level folder with the name of the project.
• The project can further be divided into:
  • Features
  • Epics and user stories
  • Releases
  • Regression cycles
  • Environments
  • Sprints, etc. 
• Each of these folders can go be further categorized based upon requirements, so a similar structure can be followed.

Sub-Flows, and Assets:

Since the model is hybrid, the focus is not on organizing sub-flows of the assets. So each flow may contain all the assets, for example the reusable sub-flows, the captured elements, images, data files, etc. However, based upon specific requirements, the recommendations from the above two models can also be incorporated and sub-flows and assets can be organized.

Below are some examples of how to use the above model:

Example: Feature with AGILE Sprints	Example: Environment based Features

Example: Features with User Stories	Example: User-specific Segregation

General Recommendations:

Apart from choosing the right model, there are few more aspects that should be taken care of in each of the recommended models. These include giving proper names to the objects and removing the unused objects, etc. Here are two vital considerations:

Naming convention:

This is one of the important rules that should always be kept in mind while creating test automation in order to achieve good readability. Always give a logical name to each asset within a test flow (e.g. the flow, sub-flow, element, image, data file, etc).

Clean up:

When you start creating a test flow, you capture different elements and later discard a few. If you forget to  remove unused resources from your project, it can make the flow heavy and more unmanageable.

LEAPWORK provides an easy way to do this cleanup process, where QA teams doesn't need to check the usage of each and every element in order to delete the unused elements. In LEAPWORK, simply right-click on the project folder and click on 'Remove Unused Elements'.

For any clarification, please contact our Priority Support.