Test automation architecture (TAA) based on a generic test automation architecture (gTAA) according to ISTQB in practice

Automated testing does not completely replace manual testing. Both methods complement each other. An overview of the test automation architecture, based on the ISTQB's generic test automation architecture (gTAA) model, helps to establish this connection in a structured way. It is worth taking a look at both test management on the right-hand side and configuration management on the left-hand side, especially from an architectural point of view.

In this blog post, we highlight the perspective from test management and the interaction with DevOps. The focus is on making the interfaces within the architecture comprehensible – for example, via feedback from automated tests to Xray. Integration with project management tools such as Jira and Confluence is also taken into account.

A holistic view of quality

Quality is more than just avoiding errors. It is much more about identifying causes and addressing them in a targeted manner. This requires a common understanding among the roles involved. These include:

• Test automation engineers,
• Test analysts,
• Test managers,
• Business domain testers,
• Testers, and
• Test automation architects.

The German Testing Board's ‘Testing Job Profile’ shows how important knowledge of the domain, processes and technology is for all disciplines. The weighting varies depending on the role and the project – but in any case, a broad understanding is always required.

A structured test environment not only makes everyday work easier, but also helps with handover and training. It forms the basis for reliable and maintainable test automation.

Equally important is collaboration with related disciplines such as requirements engineering, development and operations. Good requirements not only facilitate the development of components, but also test design. At the same time, structured tests help to provide early feedback on possible deviations. All disciplines work together to enable easily maintainable software components.

The GTAA according to ISTQB – expanded with practical experience and tools

The ISTQB's GTAA broadly distinguishes between five levels:

• 1. Component: Test scripts, for example with Cypress/Playwright/Selenium for UI tests or Postman for API checks.
• 2. Control: GitLab CI pipelines that trigger different types of tests. Security checks such as dependency or container scanning also run here.
• 3. Execution: Containerised environments (e.g. via Docker or Kubernetes). Reports such as junit.xml from Cypress are collated here.
• 4. Interface to test objects: Access to APIs (e.g. REST, GraphQL), simulated via mocks or tested directly with Postman.
• 5. Interface to test data: JSON files for input and status test data, prepared databases or generated data with Faker.js. Liquibase helps to provide database states in a targeted and versioned manner, for example for automated tests.

Xray brings additional building blocks into play: The issue type ‘Test’ maps the specification, while ‘Test Execution’ documents the execution. Cypress reports in junit format can be linked to this. This means that manual and automated test executions are stored in a central location, allowing you to easily keep track of the timeliness and criticality of a test. If someone new joins the project, they can quickly gain a good overview of the test coverage and structure, regardless of their technical background. This is aided by structuring using a nested test repository in Xray and the option of structuring test sets according to technical focus, intensity (such as smoke tests, mandatory tests prior to delivery, or error night tests and regression tests). In addition, Xray provides interfaces for automatically evaluating automated tests and creating test reports independently.

This structure allows the tools to be clearly classified in the overall context – supported by a supplementary graphic.

Supplementary assignment of all gTAA components based on the graphic

In addition to the five main areas, the gTAA contains further components. These can also be applied in practice:

• Test case specification: For example, manually in Xray or via code in Cypress and Postman.
• Test case scripting: Implementation in TypeScript (Cypress), JSON (Postman) or YAML (GitLab CI).
• Test data generation: Faker.js for synthetic data, Liquibase for database initialisation.
• Logging and logging: For example, Cypress Traces, GitLab log outputs.
• Reports and evaluation: junit.xml in Xray, Lighthouse reports and Cypress axe reports for accessibility.
• Error management: Jira tickets directly from failed tests.
• Test environments: Containers in Kubernetes for regression tests.
• Configuration management: Repositories and pipelines in Git.
• Monitoring: Grafana dashboards with metrics from CI/CD.
• Security checks: Automated via GitLab integrations.

This mapping clearly shows how theory and practice are perfectly interlinked.

Practical example: On-premise setup with real toolchain

An example from an adesso project without a cloud connection:

Jira and Confluence were used for project and requirements management, Xray for test management, GitLab with integrated security checks, Kubernetes for deployments, and Cypress and Postman for automated testing. In addition, Grafana, Sorry Cypress, and Lighthouse CI provided important insights into quality and performance.

Each tool could be assigned to the appropriate layer of the GTAA, thus contributing to a coherent overall picture. Configuration management and test management were added here as examples.

The arrows marked in red are interesting here. They use a simple example to show the tool chain from the manual area and automation:

A test specification (test) is created or linked in XRay from a Jira task. This triggers a manual test execution. This finds an error, which is recorded as a Jira bug.

At the same time, it is also possible to run a Cypress test via the CI/CD pipeline and see the result directly as a test execution in the corresponding XRay test. This is possible via the Cypress-Xray plugin from Qytera. Thanks to the test case description in XRay, even employees without programming knowledge can quickly understand the test steps. In the Jira task, you can also see the coverage status directly in the board (if the display is configured) and in the ticket itself. In addition, the status of the last test execution with the respective configuration is displayed in

• Green = OK,
• Yellow = Test specification exists but has not yet been executed,
• Red = Error in the last test

including the respective version number tested.

Testing as a Service at adesso

With ‘Testing as a Service’, adesso offers flexible solutions for testing tasks – whether you need selective support in individual test stages or areas, or even complete takeover. The model allows capacities to be scaled quickly. Expertise from various areas flows into the projects – across locations, structured and well-coordinated.

Thanks to our SmartShore approach, we can also draw on our experts in Budapest, Bucharest, Istanbul, Sofia, Barcelona and Kochi/Kerala for projects. The experts at our SmartShore locations speak German and English, among many other languages, and are familiar with our German customers and the culture of other countries. The nearshore locations themselves are only a few hours' flight from Germany, which makes it easier to hold team meetings or exchanges on site.

The ISTQB CTFL certificate is an integral part of the internal qualification path to becoming an adesso certified public developer and demonstrates the importance of quality assurance at adesso. Currently, over 1,015 adessi employees are ISTQB certified. These include over 475 specialist testers, over 275 technical testers and 150 test managers.

Conclusion

Test automation works best when it is embedded in an architecture that also takes configuration, management and processes into account. gTAA provides a solid foundation for this, but should be supplemented with an overview of the left and right sides.

With the right tools, coordinated processes and the right setup, you can create a system that is maintainable, traceable and transferable.

This is exactly where adesso provides support – methodically, technologically and flexibly.