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.
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.
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.
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.
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:
- 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.
- How many running tests are not using any library modules: This can be a sign of possible duplication and you can identify reusable modules.
- 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.