Activity: Validate Build Stability








var defaultQueryStr = '?proc={35359DDF-6361-43E5-8B1B-18D204DA8CFF}&path={35359DDF-6361-43E5-8B1B-18D204DA8CFF},{0AE0042B-034C-4296-9FA0-D9DCC61FC7B4}';
var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=null;
contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, false, true, false);










Activity: Validate Build Stability















This activity validates that the build is stable enough for detailed test and evaluation effort to begin.








DescriptionWork Breakdown StructureTeam AllocationWork Product Usage








Relationships



Parent Activities


Test






Description



For each Build this work is focused on the following: Making as assessment of the stability and testability of the Build Gaining an initial understanding-or confirming the expectation-of the development work delivered in the Build Making a decision to accept the Build as suitable for use-guided by the evaluation mission-in further testing, or to conduct further testing against a previous Build. This work is also referred to as a smoke test, build verification test, build regression test, sanity check or acceptance into testing. This work helps to prevent the test resources from being wasted on a futile and fruitless testing effort.



Properties



Event Driven


Multiple Occurrences


Ongoing


Optional


Planned


Repeatable



Staffing



The work is primarily centered around the Tester and Test Analyst roles. The most important skills required for this work include providing timely results, thoroughness and applying reasonable judgment to assessing the usefulness of the Build for further testing. It is appropriate to allocate a subset of the test team to perform this work; the other team members ignore the new build until it is validated as stable, devoting their efforts instead to either additional tests against the build from the previous test cycle, or improving test assets as appropriate.  See: Activity: Improve Test Assets. As a heuristic for relative resource allocation by phase, typical percentages of test resource use for this activity are: Inception - 00%, Elaboration - 05%, Construction - 10% and Transition - 10%. Notice that it is typical for there to be no formal Build in the Inception phase. The sophistication and availability of test automation tools and the necessary prerequisite skills to use them will have an impact on the resourcing of this work. Where automation tools are used, much of this work can be performed fast and efficiently: without automation significantly more effort is required.



Usage



Usage Guidance This work is potentially conducted once per Build-note however that it's typical not to test every Build. Once the Build is determined suitably stable, focus turns to Activity: Test and Evaluate. Where it is determined that the Build is sufficiently unsuitable to conduct further testing against, Test and Evaluation work typically recommences against a previous suitable Build. Although somewhat dependent on the size of the development effort, we recommend that you should plan to automate appropriate aspects of this work. For automated elements of these "smoke" tests, it is typical to have them run unattended in otherwise "dead-time", such as during lunch or over night. Note that in addition to executing automated "smoke" tests, you should also plan to conduct a minimal set of manual tests on new or significantly changed software items.



More Information



Concepts


Levels of Test


Test Automation and Tools








©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.







contentPage.onload();