This activity starts early in each iteration, as soon as sufficient agreement is reached on the mission for the
iteration, and continues as needed throughout the iteration. More frequently addressed in the earlier phases of
Inception, Elaboration and early Construction, typically tapering off in late Construction and Transition.
This activity is considered optional when the test approach is well known, and its applicability in the current context
is well established.
This work is somewhat independent of the test cycles, often involving the verification of techniques that will not be
used until subsequent Iterations. This work normally begins after the evaluation mission has been defined for the
current Iteration, although it can begin earlier. In some cases, finding the best implementation approach to a
technique may take multiple Iterations.
The test implementation and execution activities that form a part of this work are performed for the purpose of
obtaining demonstrable proof that the techniques being verified can actually work. As such, you should limit your
selection of tests to a small, representative subset; typically focusing on areas with substantial quality risk. You
should try to include a selection of tests that you expect to fail to confirm that the technique will successfully
detect these failures.
While failures with the target test items will be identified and these incidents logged accordingly, this focus of this
work is not directly on attempting to identify failures in the target test items as it's main objective. Again, the
objective is to verify that the approach is appropriate (it produces results that complement the Iteration objectives),
is achievable (it can be implemented with given resource constraints), and that it will work.
For this work to produce timely results, it is often necessary to make use of incomplete, "unofficial" Builds, or to
perform this work outside of a recognized Test Environment Configuration. Although these are appropriate compromises,
be aware of the constraints, assumptions and risks involved in verifying your approach in under these conditions.
As the lifecycle progresses through its Phases, the focus of the test effort typically changes. Potentially this
requires new or additional approaches, often requiring the introduction of new types of tests or new techniques to
support the test effort.
In situations where the combination of domain, the test environment and other critical aspects of the strategy are
unprecedented, you should allow more time and effort to complete this work. In some cases-especially where automation
is a requirement-it may be more economic to obtain the use of resources with specialized skills that have proven
experience in the unprecedented aspects of the strategy for a limited period of time (such as on contract) to define
and verify the key technical needs of the test strategy.
|