English | EN 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.
Figure 1: The Generic Test Automation Framework according to the ISTQB® (see references)
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.
Figure 2: Synchronization example of TAS and SUT development processes given by ISQTB® (see references)
We, at Sogeti, experienced great success applying conceptions based on a gTAA on one of our pilot projects. By focusing not only on test case automation but also by further development of the TAS, we achieve great results in staying future ready for upcoming SUT releases. We implemented our own internal project inside of our pilot where we keep track of TAS related user stories, features, improvements and bugs. We track those tickets as on any normal software project and are planning team capacities to resolve such tickets, similar to the example shown in figure 2. By this, we continuously improve project capabilities, especially the capabilities of the TAS. The usage of the gTAA constantly delivers a good overview which technologies and implementations have to be implemented in which spot in or inter between the TAA layers.
What is the difference between TAF and TAS?