Starting typically in Elaboration, this work is generally performed multiple times during an iteration, once per test
cycle based on the availability of a series of Builds that warrant independent testing.
As noted, this work is typically performed multiple times during an iteration; the actual number of times often
equating to once per Build. Note however that it's typical not to test every Build. Note also that the Build schedule
will often result in this work increasing in frequency during the course of the iteration. The need for additional
cycles is governed by assessing when appropriate breadth and depth of testing is achieved within a test cycle, which is
the focus of the Activity: Achieve Acceptable Mission.
For iterations prior to and including those early in the Construction phase, additional effort is usually required to
address tactical problems encountered for the first time during test implementation and execution. These issues often
detract from the number of actual tests successfully implemented and executed and limit either the breadth or depth of
the testing.
The sophistication and availability of test automation tools and the necessary prerequisite skills to use them
effectively will have an impact on the resourcing of this work. It may be appropriate to strategically deploy
specialized contract resource for some part of this work to improve the likelihood of success. It may also be more
economical to lease the automation tools and contract appropriately skilled people to use the tools, especially to help
mitigate the risks in getting started. You need to balance the benefits of this approach with the necessity to develop
in-house skills to maintain automation assets into the future.
|
