Task: Identify Testability Mechanisms
This task describes how to identify the general mechanisms of the technical solution that are needed to facilitate the test approach, and how to outline the general scope and key characteristics of those mechanisms.
Disciplines: Test
Relationships
Steps
Examine the Software Architecture and its Target Environments
To perform this task within the appropriate context, it is important to have a good understanding of the software being developed, its architecture, and the key mechanisms and features that it will support. Examine the available documentation for the software architecture to gain an initial understanding, and supplement this with interviews or discussions with the software architect as required. Consider the impact that each target deployment environment might have on this information, and note any important findings that you think may be relevant to the test effort.
Identify Candidate Mechanisms for Test

Using your knowledge of the software architecture and its target environments, examine the information provided in the test approach. Consider the key technical aspects of the approach, and assemble a list of candidate mechanisms that will be needed to support it. Here is a partial list of common mechanisms you should consider as candidates; persistence, concurrency, distribution, communication, security, transaction management, recovery, error detection handling and reporting, and process control and synchronization.

These mechanisms often apply to both manual and automated test efforts, although a specific mechanism may have more or less relevance to manual or automated testing. Also, even where the same mechanism is required for both manual and automated test efforts, the characteristics of the implemented solution will usually differ.

Inventory the Existing Test Mechanisms

Examine the available test tools and existing test implementations, and create an inventory of mechanisms that have one or more existing solutions. While this step is more obviously relevant in terms of the automated test effort, there are some equivalent considerations for the manual test effort.

Test automation mechanisms

Start by compiling a list of the tools available to you or that you plan to purchase. Remember that automation tools take many forms, and your list will usually include more than the automated test implementation and execution tools. For each tool, examine the mechanisms provided by the tool. For example, does the scripting tool you plan to use provide its own data persistency mechanism and, if so, is it appropriate for your needs, or will you need to supplement it? Other questions might include: Does the execution tool allow concurrent execution of test scripts on multiple host client machines? Does the execution tool allow distribution of scripts from a central master machine to multiple host client machines?

Where existing test automation implementations are available, there will be additional mechanisms to inventory. Some aspects of these implementations will extend or supplement the basic mechanisms provided by the tools to make them more useful. Other aspects will offer implementations for additional mechanisms not provided in the base tool.

Manual test mechanisms

At a basic level, this will involve reviewing the test guidelines that exist for test implementation and execution. You should look for existing process solutions for issues such as concurrency (how testers can share data sets, especially existing data beds, without adversely affecting each other) and distribution (if the test team is distributed, what solutions are available to coordinate the separate test efforts).

Define the Test Mechanisms You Will Use

Now that you have decided on the test mechanisms required, you need to communicate your choices to the test team and other stakeholders in the test effort. Document the decisions about the test mechanisms required for automation as part of the the Test Automation Architecture documentation, and those that relate to manual testing as part of the Test Guidelines.

As an alternative to formal documentation, you might choose to simply record this information as a set of informal architecture and process notes, accompanied by some explanatory diagrams, possibly retained on a white-board. During test implementation and execution, individual testers will make use of this information to make tactical decisions.

Where you have identified the potential requirement for special test interfaces that will need to be built into the software being developed, you should consider recording this requirement by creating one or more outlined Test Interface Specifications; this outline should provide a name and brief description, and enumerate the main test interface requirements or features. Avoid spending a lot of time on these outlines: the list of requirements and features will be subsequently detailed in Task: Define 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.