Best Practices - Reusability, Maintainability and Scalability

Automation yields the best benefits if it is reusable, maintainable, and scalable. In today’s fast-paced world where there is a constant need to build software effectively, all disciplines are on the look-out to maximize their productivity and minimize re-work. Automation helps by doing repetitive tasks efficiently. However, sometimes while trying to script for the immediate test scenario, it is easy to lose sight of the bigger picture and requirements: Reusability, maintainability, and scalability.

Let's explore how easily the user can create reusable, maintainable, and scalable tests with Leapwork.

Reusability

Reusability in test and process automation is about wrapping parts of an automation flow into a component that can be reused across test suites and teams. In the Leapwork Automation Platform, these components are called sub-flows. Here is a detailed article about how to create a sub-flow and here is the video tutorial for a practical example.

In order to make successful use of sub-flows, users should follow the best practices mentioned below.

• Naming Convention
  Within the project or team, we should agree on naming conventions for sub-flows. For example, name them based on the feature or function. It is important to give meaningful names to the sub-flows so that it's easy to identify, manage, and reuse them in other main flows. If a sub-flow is not created properly then our peers may end up creating another sub-flow for the same functionality with a different name, thereby duplicating the building blocks and increasing maintenance. With a naming convention in place, it will be easier to find, understand, and collaborate.

• Single Responsibility
  A sub-flow is responsible for handling one task only. In other words, it should not perform multiple tasks. For example, to login to an application, a user should create a "Login to the app" sub-flow responsible for the login only. Validation, or any other action, shouldn't form part of the same Login sub-flow.

• Easy to understand and implement: When the sub-flow only does "one thing", its interface usually has a small number of blocks that are fairly self-explanatory.

  • It is easy to reuse: If a sub-flow has multiple responsibilities, and only one of those is needed in another area of the flow, then the other additional responsibilities hinder reusability. Having a single responsibility sub-flow means the sub-flow should be reusable without modification.
  • Make it easy to maintain: Changes are isolated, reducing the chance of breaking other unrelated areas of the main flow where we are going to use it.

• Short sub-flows
  Large sub-flows are hard to read, debug, and maintain. For this reason, we should try to ensure sub-flows are short and easy to understand.

• Parameterization
  Data-Driven is a flow execution strategy that runs a test case automatically and multiple times with different sets of data. To be able to pass multiple data to the sub-flow at runtime, we need to pass data by parameterizing sub-flows with dynamic values.

As a best practice, we should never hard code any data in the flow or sub-flow. Rather, all data should be sent as an input to the flow via variables or parameters.

Test data should always be sent as an input to a sub-flow through parameters. At the same time, we should not make a sub-flow complex by adding too many parameters. Simplify and rationalize the sub-flow to the least common denominator for the parameters being passed. If our flow has more than 10 parameters then we should try to look at building small sub-flows with fewer parameters. Sub-flows can also be nested when required.

Variables play an important role in making test flows configurable and reusable, and one should use variables to simplify the complexity in the flows/sub-flows. Here are a few best practices for variable usage:

• How to use variables in Leapwork

  • Using variables and numbers

• Speculative Generality
  Sometimes we create sub-flows believing that we will use this feature someday. These types of sub-flows are hard to understand, maintain, and can create unnecessary confusion in teams. It's hard to judge the usage of these sub-flows. So ensure not to create sub-flows, blocks, assets, or elements for future hanging scenarios unless there's a defined scope.

Maintainability

One of the major challenges with automation is how to create test cases that are easy to maintain, and how to ensure it is straightforward to maintain existing test cases. The other dimension is to identify and improve flaky tests that sometimes work but fail on other occasions. Here are some tips for making maintainable test cases:

• Test Design: While designing test cases, consider the below points and design our flows and sub-flows accordingly.

• When the program’s user interface changes, how much work would I have to do again?

  • When there is a change in configuration/language (such as English to Danish), how hard is it to recreate the flows?

• Create reusable functions as sub-flows:  When using sub-flows, ensure that we are maintaining specific sub-flows in one place. The biggest benefit of having one sub-flow in many test cases is if there is a change in one sub-flow, it automatically updates in all flows using it, thereby making maintenance very easy.

• Do not hard code test data: Test data in sub-flows (or flows) must not be hardcoded, since hard-coded sub-flows are difficult to maintain and reuse. One of the important things while creating sub-flows is that we should always pass data to a sub-flow from the main flow via parameters and/or variables. This will ensure better data visibility and maintainability.

• Parameterize: if the sub-flow is performing the same operation with different data then we should parametrize the sub-flow to achieve easy maintenance.

• Keep it simple: We should always try to keep flows/sub-flows simple in order to ensure that they serve single responsibilities and fail for one reason. This will make the test easier to understand, debug, and maintain.

Scalability

Scalable automation enables us to handle a growing amount of work by adding flows/sub-flows/building blocks as well as configurations for multiple environments, platforms, and browsers. Leapwork is built for enterprises where scaling is one of the critical requirements. Let's learn the best practices to achieve easy scaling with Leapwork:

• Structure: It is important to check our project structure and follow the best practice suited to us. Having a good project structure makes it easy to understand and scale alongside the growth of the team. Here is an article that explains best practices when structuring our projects in Leapwork.
• Atomic flows: The flows should be atomic in nature. This means flows should not be dependent on other flows to perform their task. If there is a dependency, this should be handled by the run list's pre and post-conditions.
• Sub-flows with a single responsibility: Sub-flows that are designed to handle one functionality is easier to scale than the one with multiple implementations. Hence we recommend users create single responsibility sub-flows, this makes it easier to scale sub-flows when the feature under test extends its functionality.
• Using Variables: Using variables properly in the flows enables users to scale test automation from multiple environments, platforms, and browsers. It is therefore recommended to make use of the 'Call type' variable that is available in Leapwork. Click to find out how to use variables in cross-browser and cross-environment testing.

If we create our flows/sub-flows and keep the above points in mind, we will be able to achieve the following:

• Increased productivity
• Lower maintenance and better consistency
• Hide complexity
• Scale easily

For any clarification, please contact our Priority Support.