This Is How To Build An Awesome Test Automation Library

Being lazy can be a good thing.

You don’t want to lose valuable time in test automation for coding repetitive steps. For example, authentication or browsing for products is always using the same elements. In addition to duplication, it is then painful to maintain them when elements change.

Relying on test modules is a technique known as modular testing. You can use it to support various test automation cases such as customer journey or API testing. In the end, you are looking to implement reusable modules.

Test design is a fundamental activity of test automation like in software engineering. An investment in building reusable modules creates a valuable library in your test automation effort. You can support your software team to meet the Quality at Speed.

This article shares how you can build an awesome test automation library using Cerberus Testing, the open-source test automation platform. You will be able to build your own library without specific coding skills.

Your goal: build a library that is valuable, simple, decoupled, scalable and maintainable.

First things first, you need to identify the reusable components.

Identify the core components of your library

Test engineering requires a good design similarly to software engineering. Your first step is to define which possible modules could be defined. Then, you need to assess the reusability cost/benefit to optimize your effort.

The first criteria to identify candidates is the repetition of a particular module such as the login. You can base your effort on test identification techniques such as use-case matrix, boundary value analysis, decision-table matrix. Then comes the question of whether to proceed or not with the implementation.

Figure 1: Using Decision Tables for Clear, Well-Designed Testing, Stickyminds.

You have 3 choices to make: to automate now, later or never. The “now” category is the mostly used, reusable and critical modules. The “later” list would need a prioritization to address in a second step, while the “never” ones are not in the scope of a module’s implementation. A fundamental guideline is to keep things simple, accepting sometimes a bit of duplication.

Your goal is to create valuable modules over sole technical considerations.

Design awesome valuable library modules

Let’s take the case of account creation for a digital experience. We could want to build specific modules for each use-case and possible paths. The matrix would look good on the paper. But in reality, you would end up with more modules than actual automated tests. 

The best practice is to rely on an incremental approach similar to the TDD one: build one test, make it pass, refactor it and assess the need for a module, then repeat. You can start adding more tests with a systematic end-to-end verification. These feedback loops enable you to adapt rapidly your tests.

Figure 2: Model-Driven Software Development meets Test-Driven Development, Itemis.

Following this sequence for each test keeping a strict execution of your test suite will guarantee you the effectiveness and maintainability of your test library. At the same time, your modules can start being used by other members of the team, showing their value and potential for improvements.

Doing them right the first step will help you limit rework. Start with simplicity.

Design awesome simple library modules

Your library value resides in the usefulness for the rest of the team and at the end, for the users. You are helping them deliver Quality at Speed when the modules enable to quickly implement new tests that are easy to understand and evolve, containing the complexity.

The KISS principle – “Keep it Simple, Stupid” – coming from the army in 1960 is also effective in test automation. You can keep tests simple by using simple locators, self-describing variables, and a logic structure. You may need to ask your developers to implement a stable locator, or to avoid coding complex loops. That’s the tradeoff of simplicity.

We could argue to follow the principle of DRY (“Don’t repeat yourself”), trying to remove any duplication. But is this extreme approach the real solution?

In reality, this is only a choice of how to manage the complexity. Let’s take the page object pattern for the account creation page. For an international website, is it better to have a single page or one for all possible languages? The best approach is probably to have one structure for the common elements of name etc, and a variation per localization with very specific fields. 

You can rely on the key decision criteria for decoupling your automated tests.

Design awesome decoupled library modules

The balance of mutualization versus duplication leads us to the notion of test decoupling. 

In the previous example, you can gauge the decoupling by assessing how many tests should be changed if we update one module. The more impacts we have, the less decoupling you have. You need to apply this strict rule to the other elements of your test automation. A good practice of decoupling is to decouple actions and data to achieve data-driven testing.

Figure 3: Cerberus Testing natively decouples the actions and data property, medium.

Your automated tests therefore need to have actions purely focusing on the execution with a reference to the data used. On another side, you need to implement the data properties without focusing on the actions. The complexity of accessing the data should be contained at that level.

This decoupling is also fundamental to reach scalability.

Design awesome scalable library modules

Scalability is a generic word. In our context of test automation, it means that you must be fast to implement, adapt and execute. The speed of delivery is achieved by following the previous guidelines. For the speed of execution, good design is also fundamental.

Achieving a fast execution time already starts by looking at the big picture. If you start to chain various tests together, your total execution time is the sum of all the tests. You can reduce your total execution time by first limiting the number of dependent tests. The strict rule is to only embed the minimal test of your library within your tests. You should avoid chaining tests together. This coupling can probably be removed by design.

Figure 4: You can natively access your test execution and stability in Cerberus Testing, GetApp.

You can then move to the optimization of your individual tests. The key limiting factor of tests is one of the costly ones of the Lean paradigm: waiting time. The tests can quickly accumulate a lot of “wait” instructions, added one by one to solve short-term issues. You also need a strict guideline here: no fixed waits in your tests, only conditional waits with short timeouts. That also means you need to ensure your application is responsive enough in your test environment.

With these fundamentals, you are ready to support your software delivery with rapid feedback loops on software changes.

Design awesome maintainable library modules

Building a test automation library is not a one-shot effort. Like in software, 80% of the costs will come from maintenance. Your upfront investment in design will pay off with minimal continuous improvement. The better your design, the less maintenance effort you will face.

“Less is more” is a very helpful principle in the continuous management of your library. This is essential to containing the entropy over time. You can gauge the usefulness of your library by asking the following questions in a weekly review:

  1. Are the library modules used in running tests: If specific modules are not used, you need to assess their removal if they are really not necessary. 
  2. How many running tests are not using any library modules: This can be a sign of possible duplication and you can identify reusable modules.
  3. How many times the library modules are used: A specific module overly used in the tests can mean that a library module would be better split to limit coupling.

Stability in your test is the next element of maintainability. Your team will stop using tests that are slow to execute, irregular in their timings or their results. You need to help them build confidence in their software changes with rapid and stable tests

The flakiness ratio and execution time are your best bet. You need to define an alert based on a threshold for each metric. Flakiness should aim for 0 unstable tests while your execution time should be optimized with no waiting time and the most rapid execution.

Closing that loop, you have now an awesome test library.

A test automation library is an investment with recurring benefits

Your test automation library can be a game-changer in the way to deliver software. The team can gain a significant advantage by having the confidence to go fast with small changes. Like in running, you can go fast the day of the race with proper preparation.

The initial investment in design is critical to building the right things right in the first place. Additionally, the step-by-step approach allows you to minimize the effort to reach a useful state to the team. And your rework costs are contained by being done early on.

The first step to reach your test automation library is to be of value, simple, maintainable and scalable. Then, your continuous management process will enable you to contain entropy over time. Supporting the team in delivering Quality at Speed is your goal.

Your software team is the one who will demonstrate if your test library is “awesome” 🙂

Stop coding, starting testing now.

Leave a comment

Your email address will not be published. Required fields are marked *

Cerberus-Testing Terms Of Service


Website Terms and Conditions of Use

1. Terms

By accessing this Website, accessible from http://vgeouyk.cluster030.hosting.ovh.net, you are agreeing to be bound by these Website Terms and Conditions of Use and agree that you are responsible for the agreement with any applicable local laws. If you disagree with any of these terms, you are prohibited from accessing this site. The materials contained in this Website are protected by copyright and trade mark law. These Terms of Service has been created with the help of the Terms of Service Generator and the Privacy Policy Template.

2. Use License

Permission is granted to temporarily download one copy of the materials on Cerberus Testing's Website for personal, non-commercial transitory viewing only. This is the grant of a license, not a transfer of title, and under this license you may not:

  • modify or copy the materials;
  • use the materials for any commercial purpose or for any public display;
  • attempt to reverse engineer any software contained on Cerberus Testing's Website;
  • remove any copyright or other proprietary notations from the materials; or
  • transferring the materials to another person or "mirror" the materials on any other server.

This will let Cerberus Testing to terminate upon violations of any of these restrictions. Upon termination, your viewing right will also be terminated and you should destroy any downloaded materials in your possession whether it is printed or electronic format.

3. Disclaimer

All the materials on Cerberus Testing’s Website are provided "as is". Cerberus Testing makes no warranties, may it be expressed or implied, therefore negates all other warranties. Furthermore, Cerberus Testing does not make any representations concerning the accuracy or reliability of the use of the materials on its Website or otherwise relating to such materials or any sites linked to this Website.

4. Limitations

Cerberus Testing or its suppliers will not be hold accountable for any damages that will arise with the use or inability to use the materials on Cerberus Testing’s Website, even if Cerberus Testing or an authorize representative of this Website has been notified, orally or written, of the possibility of such damage. Some jurisdiction does not allow limitations on implied warranties or limitations of liability for incidental damages, these limitations may not apply to you.

5. Revisions and Errata

The materials appearing on Cerberus Testing’s Website may include technical, typographical, or photographic errors. Cerberus Testing will not promise that any of the materials in this Website are accurate, complete, or current. Cerberus Testing may change the materials contained on its Website at any time without notice. Cerberus Testing does not make any commitment to update the materials.

6. Links

Cerberus Testing has not reviewed all of the sites linked to its Website and is not responsible for the contents of any such linked site. The presence of any link does not imply endorsement by Cerberus Testing of the site. The use of any linked website is at the user’s own risk.

7. Site Terms of Use Modifications

Cerberus Testing may revise these Terms of Use for its Website at any time without prior notice. By using this Website, you are agreeing to be bound by the current version of these Terms and Conditions of Use.

8. Your Privacy

Please read our Privacy Policy.

9. Governing Law

Any claim related to Cerberus Testing's Website shall be governed by the laws of fr without regards to its conflict of law provisions.

Thank you for your interest in cerberus,

In order to proceed with your SaaS we need some in order to confirm your instances accesses.

Please provide accurate contacts to secure the process.

You can cancel any time the subscription, please read Terms of Use.