Artifact: Test Automation Architecture

Test Automation Architecture	A composition of various test automation elements and their specifications that embody the fundamental characteristics of the test automation software system. The Test Automation Architecture provides a comprehensive architectural overview of the test automation system, using a number of different architectural views to depict different aspects of the system.
UML Representation:	Some aspects of the Test Automation Architecture can optionally be described using a UML model, stereotyped as «test automation architecture».
Role:	Test Designer
Optionality/ Occurrence:	Often informal. Where maintained, this artifact is most useful as single artifact per project. This artifact is particularly useful when the automated execution of software tests must be maintained and extended through multiple test cycles.
Enclosed in:	Optionally the Test Automation Architecture can be enclosed within the Software Architecture Document, either described in its own section or as a set of concerns detailed throughout.
Templates:	Others
Examples:
Reports:
More Information:
Purpose Brief Outline Properties Timing Responsibility Tailoring

Input to Activities:  Implement Test Implement Test Suite Agree Mission Obtain Testability Commitment Develop Test Guidelines Structure the Test Implementation Define Test Approach Define Test Environment Configurations Identify Testability Mechanisms Define Testability Elements

Output from Activities:  Define Test Approach Define Test Environment Configurations Identify Testability Mechanisms Define Testability Elements

Purpose

The Test Automation Architecture serves as a means of reasoning about, managing and communicating the fundamental characteristics and features of the test automation software system. It provides a governing focus for the test automation software that enables the required system to be realized in respect to key aspects such as: maintainability, extensibility, reliability, concurrency, distribution, security and recovery.

Brief Outline

See the Artifact: Software Architecture Document for an example outline of the areas that should be covered by the Test Automation Architecture.

Properties

Timing

The Test Automation Architecture should be outlined as early as practical, preferably by the end of the Inception phase. By the end of the Elaboration phase, the Test Automation Architecture should be well-formed, proven, evaluated, and baselined.

Responsibility

The Test Designer role is primarily responsible for this artifact. Those responsibilities include:

• Approving all changes to architecturally significant elements, such as major Interfaces, common-code libraries, and the like.
• Ensuring that changes are implemented, validated, and communicated to affected roles.
• Resolving issues that arise from conflicts between the test automation tools and the planned Test Approach.

Tailoring

Where available, you may be able to make use of some part of the existing Test Automation Architectures with little need to tailor them. However, usually each project requires some variation in approach, techniques, and tools, which ultimately affects the Test Automation Architecture itself. In many cases, tailoring or creating an appropriate Test Automation Architecture will occur during the Elaboration phase, and will be fine-tuned and extended with each subsequent iteration in both the Construction and Transition phases.

For the definition of Test Automation Architecture, we recommend using a single source that maintains an outline description of the main characteristics of the architecture. Note: you should avoid excessive and unnecessary detail in the architectural description.

As an alternative to formal documentation, you might choose to simply record this information as a set of informal architectural notes accompanied by a minimal set of explanatory diagrams, possibly maintained on a white-board readily visible to the test team.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process