Workflow Detail: Validate Build Stability
|
The purpose of this workflow detail is to validate that the build is stable enough for detailed test and evaluation effort to begin. 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 being wasted on a futile and fruitless testing effort. |
|
|
|
Description
For each Build to be tested, this work is focused on:
- 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.
Related Information
This section provides links to additional information related to this workflow detail.
Timing
Typically addressed once per test cycle based on the availability of new software builds.
Optionality
Should be performed once for each build that will be subjected to an extensive test effort.
How to Staff
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: Workflow Detail: Improve Test Assets.
As a heuristic for relative resource allocation by phase, typical percentages of test resource use for this workflow detail 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.
Work Guidelines
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 Workflow Detail: 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.
See the Related Information section for additional guidance that will help you in performing this work.
