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.