Build Verification Test

In computer programming and software testing, smoke testing (also confidence testing, sanity testing,ISTQB® Glossary for the International Software Testing Qualification Board® software testing qualification scheme
ISTQB Glossary
International Software Testing Qualification Board. build verification test (BVT) and build acceptance test) is preliminary testing or sanity testing to reveal simple failures severe enough to, for example, reject a prospective software release. Smoke tests are a subset of test cases that cover the most important functionality of a component or system, used to aid assessment of whether main functions of the software appear to work correctly.Dustin, Rashka, Paul. "Automated Software Testing -Introduction, Management, and Performance". Addison-Wesley 1999, p. 43-44. . When used to determine if a computer program should be subjected to further, more fine-grained testing, a smoke test may be called a pretest or an intake test. Alternatively, it is a set of tests run on each new build of a product to verify that the build is testable before the build is released into the hands of the test team. In the DevOps paradigm, use of a build verification test step is one hallmark of the continuous integration maturity stage.

For example, a smoke test may address basic questions like "does the program run?", "does the user interface open?", or "does clicking the main button do anything?" The process of smoke testing aims to determine whether the application is so badly broken as to make further immediate testing unnecessary. As the book ''Lessons Learned in Software Testing'' puts it, "smoke tests broadly cover product features in a limited time ..if key features don't work or if key bugs haven't yet been fixed, your team won't waste further time installing or testing".

Smoke tests frequently run quickly, giving benefits of faster feedback, rather than running more extensive test suites, which would naturally take longer.

Frequent reintegration with smoke testing is among industry best practices. Ideally, every commit to a source code repository should trigger a Continuous Integration build, to identify regressions as soon as possible. If builds take too long, you might batch up several commits into one build, or very large systems might be rebuilt once a day. Overall, rebuild and retest as often as you can.

Smoke testing is also done by testers before accepting a build for further testing. Microsoft claims that after code reviews, "''smoke testing'' is the most cost-effective method for identifying and fixing defects in software".

One can perform smoke tests either manually or using an automated tool. In the case of automated tools, the process that generates the build will often initiate the testing.

Smoke tests can be functional tests or unit tests. Functional tests exercise the complete program with various inputs. Unit tests exercise individual functions, subroutines, or object methods. Functional tests may comprise a scripted series of program inputs, possibly even with an automated mechanism for controlling mouse movements. Unit tests can be implemented either as separate functions within the code itself, or else as a driver layer that links to the code without altering the code being tested.

Etymology

The term originates from the centuries-old practice of mechanical smoke testing, where smoke was pumped into pipes or machinery to identify leaks, defects, or disconnections. Widely used in plumbing and industrial applications, this method revealed problem areas by observing where smoke escaped.

In software development, the term was metaphorically adopted to describe a preliminary round of testing that checks for basic functionality. Like its physical counterparts, a software smoke test aims to identify critical failures early, ensuring the system is stable and that all required components are functioning before proceeding to more comprehensive testing, such as end-to-end or load testing.

In the context of electronics, the term was humorously reinterpreted to describe an initial power-on test for new hardware. This usage alludes to the visible smoke produced by overloaded or improperly connected components during catastrophic failure. While the imagery is memorable, the occurrence of smoke was never an intended or sustainable testing method. Instead, it underscores the importance of performing basic checks to catch critical issues early.

For example, Cem Kaner, James Bach, and Brett Pettichord explain in ''Lessons Learned in Software Testing'':

''"The phrase smoke test comes from electronic hardware testing. You plug in a new board and turn on the power. If you see smoke coming from the board, turn off the power. You don't have to do any more testing."''

See also

* "Hello, World!" program
* Sanity testing
* Shakedown

References

External links

PC Mag's Definition

{{DEFAULTSORT:Smoke Testing
Tests
Software testing