Task: Define Testability Elements |
This task describes how to identify the elements that will support and enable testing.
Disciplines: Test
Purpose
The purpose of this task is to: Identify the elements needed to support the target test items Identify the physical elements of the test implementation infrastructure required to enable testing under each Test Environment Configuration Define the software design requirements that will need to be met to enable the software to be physically testable
Relationships
Roles | Primary Performer: Test Designer | Additional Performers:
Inputs | Mandatory: Test Strategy [Technical Design] Design | Optional: Test Automation Architecture Test Case Test Data Test Design Test Interface Specification [Technical Implementation] Code Analysis Guidelines Developer Test Implementation
Outputs | Test Automation Architecture Test Design Test Interface Specification
Steps
For Each Required Target Test Item, Identify Relationships with Test Mechanisms
For each target test item, review the list of test mechanisms, and identify the ones that could provide support. Analyze how closely the selected test mechanisms provide a complete test solution, and how they can be adapted to become a better fit. If no candidates are found (or the adaptation effort is significant), define new test mechanisms, and try to find a balance between specificity and reusability.
Identify Dynamic Elements and Events of the System
Using the available software requirements and design information, identify the dynamic elements and events of the system. Using the use-case, design, implementation, and deployment models, you can identify relevant items such as control classes, processes, threads, and events. Places to begin your research include classes stereotyped as <<control>>, use-case realizations, and elements described in the process architectural view or the implementation model stereotyped as <<process>> or <<thread>>. In relation to the constraints imposed by the test environment, define the physical requirements.
Identify System Boundaries and Interfaces
Another useful group of elements to examine are the Interfaces of the system, most importantly those that relate to actors external to the boundaries of the system. Using the Design and Implementation models, look for elements defined with the stereotype <<interface>>. Also examine the models for the existence of classes stereotyped as <<boundary>>. As a tester, it is useful to explore past these system boundaries to gain an understanding of the expectations of the related systems (both client and service providers). This will give you a more thorough understanding of what is needed (both in terms of validation of the interfaces, and in terms of the test infrastructure required to test and possibly simulate these interfaces).
Identify Test Infrastructure Elements
For an iterative test effort to be successful, it is important to identify and maintain an appropriate infrastructure. Without an infrastructure to help maintain it, the test effort can quickly become unmaintainable and unusable. While more obviously relevant to the automated test effort, test infrastructure is also an important concern for the manual test effort. Consider the dynamic elements and events in the system: what dependencies will these place on the implementation of individual tests? Look for opportunities to uncouple the dependencies between individual tests, and manage them through common points of control that provide a layer of indirection. Common areas to explore for dependencies include test navigation, test data use, and system state changes. Using the information that you have gathered, consider what requirements will govern the test infrastructure, and what facilities it will need to provide to enable a successful test approach. For more details, see the Identify Test Infrastructure Elements section in Guideline: Defining Testability Elements.
Identify Test-Specific Design Needs
Especially where test automation is concerned, it is likely that the test implementation and assessment needs will place some constraints on both the way the development team enacts the software engineering process, and on the architecture and design of the software. It is important both that the software development team is not unduly hampered in their core development work, and that the test team has the ability to perform the necessary testing. Using the information that you have gathered, consider what requirements the test effort will place on the development effort. For more details, see the Identify Test-Specific Needs section in Guideline: Defining Testability Elements.
Define Software Testability Requirements
Using the previous work performed on the task, define the test-specific requirements and constraints that should be considered in the software design and implementation. For more details, see the Define Software Testability Requirements section in Guideline: Defining Testability Elements.
Define Test Infrastructure
Using the previous work performed on the task, define the test infrastructure that is required to support test implementation and execution. Remember that you are defining the implementation features of the infrastructure; your main objective is to define the various parts of the solution that will implement that infrastructure. For more details, see the Identify Test Infrastructure Elements section in Guideline: Defining Testability Elements.
Evaluate and Verify Your Results
You should evaluate whether your work is of appropriate quality, and that it is complete enough to be useful to those team members who will make subsequent use of it as input to their work. Where possible, use checklists to verify that quality and completeness are good enough. Have the people who perform the downstream tasks that rely on your work as input review your interim work. Do this while you still have time available to take action to address their concerns. You should also evaluate your work against the key input work products to make sure that you have represented them accurately and sufficiently. It may be useful to have the author of the input work product review your work on this basis.
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.