Artifacts > Test Artifact Set > {More Test Artifacts} > Test Software Design > 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:
Examples:  
Reports:  
More Information:  

Input to Activities:    Output from Activities:   

Purpose To top of page

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 To top of page

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

Properties To top of page

Property Name

Brief Description

UML Representation

Introduction A textual description that serves as a brief introduction to the model. Tagged value, of type "short text".
Packages The Packages used for organizational grouping purposes, usually representing a hierarchy. Owned via the association "represents", or recursively via the aggregation "owns".
Interfaces The interfaces in the model, owned by the packages. Owned recursively via the aggregation "owns".
Key Events and Signals The relevant Events and Signals in the model, owned by the Packages. Owned recursively via the aggregation "owns".
Key Test Suites and Test Scripts. The relevant Test Suites and Test Scripts in the model, owned by the Packages. Owned recursively via the aggregation "owns".
Key Relationships The relevant relationships in the model, owned by the Packages. Owned recursively via the aggregation "owns".
Key Diagrams The key diagrams in the model, owned by the Packages. There are various UML diagram representations.
Key Use-Case Realizations The relevant Use-Case Realizations in the model, owned by the Packages. Interaction and Class Diagrams supplemented with textual documents.

Timing To top of page

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 To top of page

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 To top of page

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


Display Rational Unified Process using frames

Rational Unified Process