Artifact: Test Interface Specification |
This artifact specifies the provision of a set of behaviors (operations) by a classifier (specifically, a Class, Subsystem, or Component) for the purposes of test access (testability).
Domains: Test
Purpose
To provide a means of documenting the special requirements of the test effort that will place constraints or additional requirements on the design of the software.
Relationships
Roles | Responsible: Test Designer | Modified By: Test Designer
Tasks | Input To: Define Testability Elements Identify Testability Mechanisms Structure the Test Implementation | Output From: Define Testability Elements Identify Testability Mechanisms
Description
Main Description | Test Interface Specifications are used in situations where aspects of the system that do not normally have visibility must be observed, or where control of the software is required in a way not normally available through the standard interface. Each test Interface should provide a unique and well-defined group of services.
Brief Outline | Each Test Interface Specification should consider various aspects of testing, including the following: What is the nature of the interface? For example, does it allow dynamic two-way communication, does it provide individual real-time status feedback or, once activated, does it simply log information passively? Under what circumstances will the interface be used? Be sure to consider concurrency and access methods. What ability is needed to activate and deactivate the interface? What control is required to raise or lower the level of detail of the output from the operations provided by the interface?
Tailoring
Impact of not having | If there is a need for testability for different components under development, not capturing this information might lead to: Delays in testing some aspects of the system, as there is not enough test access to the associated subsystems. Communications problems between the development and the test teams, as the testability needs are not properly expressed. Potential for schedule overruns.
Reasons for not needing | This is an optional artifact. On many projects, there is either sufficient accessibility for test in the visible operations on classes, user interfaces and so on. Common reasons to create test interface specifications include UI extensions to allow GUI test tools to interact with the tool and diagnostic message logging routines, especially for batch processes.
Representation Options | UML Representation: Interface See the Interface related guidance for ideas on iunterfaces that can be applied to tailoring the Test Interface Specification. Optionally enclosed in the other design or requirements related artifacts.
© Copyright IBM Corp. 1987, 2009. All Rights Reserved. © Copyright ABC Corp. 2009. All Rights Reserved. Includes materials licensed from IBM and Eclipse. See IBM copyright and Eclipse copyright .