Artifact: Test
Automation Architecture
|
A composition of various test automation design and implementation elements and their specifications that embody the fundamental characteristics of the test automation software system. |
|---|---|
| Role: | Test Designer |
| Optionality/Occurrence: | This artifact is particularly useful when the automated execution of software tests must be maintained and extended through multiple test cycles. This artifact is most useful as single artifact per project. |
| Templates and Reports: |
|
| Examples: | |
| UML Representation: | Some aspects of the Test Automation Architecture can optionally be described using a UML model, stereotyped as <<test automation architecture>>. |
| More Information: |
| Input to Activities: | Output from Activities: |
Purpose 
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. It 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
| 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
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.
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.
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.
