"The most fundamental part of the daily build is the 'daily' part. . . . Treat the daily build as the heartbeat of the project. If there's no heartbeat, the project is dead."
- James McCarthy

Compile and Smoke Test Frequently

Large software systems often contain thousands of individual components. Similar to a military operation, all units need to work smoothly together if the overall operation is going to be successful. Taking this analogy one step further, a commander who wants to bring new weapons systems or new elements into the fighting force would shy away from making massive changes before an important operation. Rather, the desired strategy would be to integrate new capabilities slowly, minimizing the change in each expansion.

Similarly, it is advisable in a software system to bring new "fighting forces" or modules into the "fight" at a very measured rate, exercising them in the context of the overall system before going further. The desired strategy would be to bring each unit in one at a time, perform an extensive regression test, correct any defects and then proceed to the next unit.

While this sequential strategy facilitates fault isolation, it is simply impractical. With thousands of units to integrate and sometimes days required to perform extensive testing, the desired approach soon becomes an anchor that will sink the entire project.

"Smoke testing" is an effective compromise in this situation and is gaining increased acceptance in the software industry. In this approach, units are integrated at a measured pace. As soon as a small number of units are added, a test version is generated and "smoke tested," wherein a small number of tests are run to gain confidence that the integrated product will function as expected. The intent is neither to thoroughly test the new unit(s) nor to completely regression test the overall system. The objective is simply to build confidence in the expanded system. Smoke testing should occur at least twice a week, more frequently if practical.

To ensure that the product is growing in a controlled manner, the version to be tested should be generated from the CM library (completely, if a component does not exist in CM, it doesn't exist for the purpose of the test). It is advisable to have smoke test accomplished by an independent group. It is also important that the Smoke Test perform a quick check of the entire system, not just the new component(s). Smoke testing is not a new form of testing; the integrated units should have already been through all development and test stages, stages that produce a quality product. The daily build and smoke test keeps integration error small and manageable. The process prevents runaway integration problems and reduces the risk of low quality.

top

---