TEST AUTOMATION ARCHITECTURE BASICS
Table of contents
Integration into software systems
Introduction
The test automation discipline has evolved a lot in the past decades, and actually became kind of a craze somewhere around 2015: companies started realizing that without automation, they won't succeed in the long run. But it also backfired in many organizations, as they targeted 100% test automation coverage - whatever that meant for them.
Two things that did not change within this discipline: test automation is still software development and it is still a testing activity.
That said, it is important that we properly design what we will build, and without development and testing skills, it becomes a great challenge.
Obviously, I won't be able to magically turn you into a superb test automation engineer, but I can help you improve by providing some basic knowledge about test automation architecture, which is the 'backbone' of all the implementation work we do.
Expectations from a framework
Typically, when people talk about test automation frameworks, they have many opinions on what a framework is and what it should achieve.
Let me give you some examples:
-
Automated testing
-
Detailed logging
-
Generated reports
-
CI/CD integration
-
Easy to use
-
Low maintenance
-
Modularity
-
Scalability
-
etc.
Ultimately, the most important aspects of a test automation framework is being able to execute the tests in an automated fashion, and that it provides value for the testing team. If you do not achieve those two, there's no sense in doing automation in your project or not in the way you planned to do it.
Using the right terms
Many times I hear people confusing architecture to framework to solution. Let me describe these expressions, to make sure that everybody is on the same page and speaks the same language, when it comes to test automation.
Test Automation Architecture (TAA)
-
High-level architecture design of the solution
-
The blueprint of what will be implemented
-
Indicates the components and how they are connected
Test Automation Solution (TAS)
-
The realization of the architecture
-
Includes the framework
-
Integrated CI/CD pipelines
-
Integrated Test & Project Management tools
Test Automation Framework (TAF)
-
Base of the solution
-
Framework layers
-
Test harness, test libraries, test data
-
Test scripts & suites
Framework layers
Layers define distinct borders of classes that have similar purposes.
Many people tend to overuse layers.
Typically they define the following ones:
-
Test Cases
-
BDD features
-
Reporting-Logging
-
Encryption
-
Runner
-
Etc.
I sometimes hear people brag about having 6-7 or even more layers in their framework. But to be frank, those layers could be easily combined and explained as 2 or maximum 3 layers, anything more than that is unnecessary over complication of your framework design. I will publish an article on that as the 'Tri-Layer Testing Framework' where I'll prove my statement.
Integration into software systems
Simple frameworks tend to have only one SUT (Software/System Under Test).
However, E2E testing may involve validation of multiple SUT's with different types of testing on multiple levels such as UI, API, Database, Performance, Security, Analytics etc.
Test automation solutions sometimes include multiple frameworks that are specifically built for one purpose each (e.g. separate UI and API framework).
Table of contents
Integration into software systems
References:
Page object models - Selenium Dev
UML State Machine Diagrams - UML Diagrams org
UML state machine diagram wiki page
Facade Design pattern - blackwasp
Originally published on 2022. May ??.