WhatA simple test case suite, designed to give confidence in an integrated build of a system or sub-system. May also be referred to as a health check or reality check.

The phrase is derived from the testing of hardware. For example a computer would be ran until it literally started smoking.

As the software is incrementally integrated, smoke testing confirms the stability of the Software Under Test (SUT).

Why?An integrated build of software is a complex thing. Defects related to interfaces, bottlenecks and usability may only come to to light at integration. Every time a build is construction, with additional components or sub-systems, new opportunities for failure arise.

When testing at the system level, the test team needs to have confidence in the stability of the overall SUT. A successful run of the smoke test, generates this onfidence. Often a smoke test, is considered an entry criteria for system testing.

An effect of smoke testing, is the early discovery of major defects, that make the SUT unreleasable. (Known universally as a showstopper.) A lot of time is saved, by not testing on an unstable platform. Smoke testing also has an element of regression testing. The smoke test, confirms (in simple terms) that previously tested and integrated code is still functioning as it should.

Smoke testing is the first stage of integration testing. Also closely related is incremental testing. In both of these an essential element is the joining together of all available components and sub-systems.

If the organisation is implementing an iterative based framework, smoke testing is used to extensively. An example is the Rational Unified Process (RUP) which seeks to progressively mitigates risks. Smoke testing can aid this process, by generating confidence in both the SUT and the build process.

Who?
Personnel involved in Smoke Testing are usually close to the build process or in the configuration arena. This is due to two reasons. Confirmation that the build is stable, has to be made as quickly as possible. Secondly is the large degree of automation.

The suite itself, would be designed by a tester or test analyst. Automation or writing the scripts may be done by a test automater or engineer.

Actual execution of the test suite, is a test technician role. The repetivity of the activity makes it extremely mundane.

Where?
As close as possible to the build environment. The vast majority of smoke testing is at the developing organisations site.

When?
The testing should be done after every build. At Microsoft this means every night, the entire product is rebuilt, and a Smoke Test ran against it. A small product, at release time may be rebuilt 2-3 times a day.

How?
The reliance on a new build to be existing, means implicitly that the organisation is testing incrementally or iteratively. As the project progresses, the SUT grows with the addition of new or altered code. (Not necessarily new features though.)

The test suite consequently grows in an incremental fashion. Ideally as potential areas of high risk are identified, they are mitigated in the SUT. Analysis is required to establish if additional test cases are required, to confirm that they have indeed been mitigated.

Automated tests are used extensively, due to the repetitive nature of the testing. Winrunner is a popular choice for such a task. If performance is an issue, LoadRunner, might be used to confirm that no performance issues, such as bottlenecks have been introduced.