In this article, we will share about building reusable, reliable and loosely coupled test automation modules to enable a scalable approach. 

Quality at Speed is the main focus for evolving product teams. The need to accelerate software releases while maintaining quality is a key output of the World Quality Report 2020-2021.

Not only QA teams need to secure their testing responsibilities, but they should also provide a scalable solution to the whole team. In fact, they need to become an enabler.

But automation is complex, and when done wrong, it leads to worst-case situations. Quoting Bill Gates  “Automation applied to an inefficient operation will magnify the inefficiency.”. So how to deliver a scalable Test Automation?

Define the scope and requirements of your test library

First, we define the scope of our project based on our main business problems and test strategy:

• Which area should we focus on? (Front-end, Back-end, which functional area?)
• Which applications are in scope of the identified area?
• Which technical layers should we consider in our modules?

Next, we can identify the requirements of the selected scope. They will depend on your particular context, however, we share some good practices:

• Test structure is aligned on business use-cases and language
• We can describe the test without having a “and” for the intent or verification
• They are fast to execute for rapid feedback and easy to use by the team
• They are reliable, keeping confidence and its use over time

In our case, we will verify that the main user functionalities of Cerberus Testing are working fine.

Identify the different modules to be build

At this stage, we are ready to list the possible test modules. This is a crucial step to secure the foundations of a scalable approach.

We can apply different test identification techniques such as Boundary Value Analysis or Equivalence Partitioning. In our case, we want to perform mainly web testing simulating user actions. So we will apply the Use Case Testing technique.

As an example, we discover the following customer journeys and main use-cases on Cerberus Testing:

• Open the homepage
• Be able to login (variant with valid or invalid password)
• Navigate to the main pages
• Create a Test case
• Execute a Test Case
• Access a Test Case

Implement your test cases by adding modules incrementally 

We now have a clear view of the scope. But we need to start the implementation at some point.

In the case of User Experience testing, we will compose over-time scenarios based on customer journeys. Therefore, the most pragmatic approach is to take them by order of product usage.

• As a user, I want to access the homepage and verify its main elements
• As a user, I want to access to login and verify my dashboard information
• As a user, I want to access an existing test case to read its actions and controls
• As a user, I want to execute an existing test case to verify an application status

As a result, the first test modules are emerging. Note that we delay the cases with complexity for later on, focusing on simple use-cases.

Refactor your modules based on your first iteration

We could implement the remaining test modules of our list. However, as in software development, technical debt is already there. 

This is normal as we confront our ideal test cases with the reality of implementing them. Hence, we strongly recommend at that stage a refactoring session.

The main patterns to evolve are usually linked to coupling or duplication between our modules. For instance, externalize common locators or test data to ensure a good evolutivity of the tests.

Incrementally implement the remaining modules, with refactoring

We can now add different variations of use cases from more stable test modules.

In our case it could be:

• Based on Homepage and Login test modules:
  • As a user, I want to login with invalid credentials and verify this is not possible
• Based on the Homepage, Login and Execution test modules:
  • As a user, I want to execute a web application test
  • As a user, I want to execute a mobile application test
  • As a user, I want to execute an API application test

We should perform a refactoring at that stage because we will discover new behaviour to optimize, duplication and coupling. Once done, you can start the next group of test modules.

We can implement more complex use-cases still based on the core modules:

• As a user, I want to create a web test case and verify its creation
• As a user, I want to create a web test case, execute and verify its result (*)

(*) Be careful here! We are breaking the principle of modularity by having too many functionalities and constraints in a single test. The best approach is to break down this test into separate test modules and test cases: One to create, one to execute and one to verify its result. 

Share your library and scale your approach!

Finally, after some iterations, your test modules will be ready with all the robust modules you made available!

Following the principle of having them with a common business language and a data-driven testing approach, you could allow your Product Owners to create their own tests by themselves.

I hope this article helps you in your test automation journey. The feature of Test library is natively available in Cerberus Testing, with readily available actions and controls you can leverage for fast test automation. 

You can also access our regression testing guide here. Happy Testing!