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. 
  |