The generic Test Automation Architecture (gTAA) has been presented by the International Software Testing Qualification Board® (ISTQB®) and is part of their Test Automation Engineer (TAE) syllabus. Common Test Automation strategies focus on bottom-up strategies by deciding beforehand which tooling to use in certain environments. This often leads to a `how can we fit our tooling inside the project´ instead of a `which tooling fits best for our project’s requirements´ approach. This can be suitable in well understood and established environments but the implementation from one test project to another can still be difficult to handle even in such circumstances. Established tooling often provides functionality which is only beneficial or usable in certain conditions. Also, such implementations could be difficult to expand, maintain or partially replaced. The gTAA offers an approach to understand well-implemented test automation solutions (TAS) even better or to handle test automation in software projects on a tabula rasa. From my point of view, there is surely more than one way to reach the goal of a well-optimized individual TAS. I achieved great results by briefly following the gTAA approach offered by the mentioned ISTQB® syllabus.
A short overview of the gTAA
Basically, the gTAA separates a test automation architecture into four layers. A test automation framework, according to the gTAA, may consist of the test definition layer, the test execution layer and the test adaption layer. Further, there is the test generation layer which is being seen as separate from the test automation framework. The layers all depend on three applied management layers, namely the test management, project management, and configuration management (see figure 1). For a specific TAS, it should be mentioned that any of these layers could be present or absent. Please refer to the TAE syllabus for further information.![](https://labs.sogeti.com/wp-content/uploads/sites/2/2019/04/Generic-Test-Automation-Framework-.jpg)
Utilization of the gTAA for a top-down approach
Available test automation tools in the market are widespread. Most of them are capable of implementing not only one but several TAA layers at once. The more layers interleave, the more difficult it is to modify a specific layer. Identifying which components of the gTAA are to be implemented into a specific TAA is a great first step to focus on. By choosing a tool and then fitting it into a project, you might take away the opportunity to design your TAA according to needed modules and parts. For example, the tool you choose might have an excellent test logging but provides insufficient test reporting. This could, of course, be compensated by individual development to transform the test reports. With general test automation architectures, as the gTAA, and planning the implementation of a TAA beforehand, the right tooling might have been identified. By identifying the right tools beforehand, the TAA will be more robust. Changes can be implemented easier and maintenance could be understood better by having the opportunity to select and implement the tooling by module based choices.Does such an approach contradict agile?
A common preconceived notion is, that top-down approaches are non-suitable for agile. In the agile manifesto, it says `Responding to change over following a plan´ and ` Individuals and interactions over processes and tools´ (see references). By following a strategy where you stick to certain tooling and necessarily have to fit it in with no other way to go, you are certainly choosing a plan over a response to change. Additionally, you are definitely choosing a tool over the possibility to let the individual of a team decide where to go and what to improve. The TAE syllabus gives some suggestions about how to use a gTAA based approach in a DevOps environment. The ISTQB® recommends applying the Software Development Life Cycle (SDLC) also for test automation solutions. A simple example is demonstrated in figure 2. By applying a gTAA, it is definitely not needed to fully conceptualize the TAA at once. The layer based conception creates a possibility to develop the TAS parallel to the System Under Test (SUT) SDLC.![](https://labs.sogeti.com/wp-content/uploads/sites/2/2019/04/Synchronization-example-of-TAS-and-SUT.jpg)
What is the difference between TAF and TAS?