40. SW Dev Practices – Smoke Test
Smoke Test: Project regression test to ensure a safe Software Quality Control (SCQ) Build. (p. 90)
There can be a variety of software development life cycles (waterfall, agile, spiral, etc.) but all efficient and effective software development organizations use a Smoke Test process to check new code before investing in more extensive testing. The smoke test is usually an automated suite of test scripts that checks broadly from end to end the critical functions of the system. Its script content grows as the system grows and significant new functions are added to the software product.
The purpose of the Smoke Test is to ensure that any new code being added to a software product has not seriously broken any major functions already developed. Only code that has passed the smoke test is allowed to be incorporated into the software product build and proceed to further in depth testing. Failing the smoke test is known as “breaking the build” and it is a noteworthy disgrace among programmers.
This often incurs some “public penalty” such as buying donuts or popcorn for everyone else in their programming group or posting a telltale sign on their office door or cubicle. It often means they did not do a thorough code review and unit test before putting their code into the smoke test build.
Their breaking of the Smoke Test build could delay the work of others who need the failed code for running another part of the system. When repairs are made and the Smoke Test is passed, the telltale sign can be removed from their work area.
As the development cycle progresses and many builds have been tested, the Smoke Test may be followed by a Sanity Test which goes narrower and deeper into checking the specific function of the new component code in the context of its related function in the system.
|Smoke Testing||Sanity Testing|
|Smoke Testing is a subset of Regression Testing||Sanity Testing is a subset of Acceptance Testing|
|Smoke Testing exercises the entire system from end to end||Sanity Testing exercises only the particular component of the entire system|
|Checks that critical program functions work well||Checks new components and fixed bugs|
|Verifies “stability” of system to proceed to more rigorous testing||Verifies “rationality” of minor changes in code or function & bugs fixed without new issues arising|
|Usually documented or scripted||Usually is not documented & not scripted|
|Performed by developers or testers||Usually performed by testers|
One good industry practice is to conduct a Daily build and smoke test in software projects. In industry, Sanity test cases are often combined with Smoke test cases to speed up test execution.
Next Month: Cloud Validation – PQ Testing of SaaS Applications
PQ, however, can still be performed by users as usual using their work process to validate the ability of the cloud-hosted software application to perform as expected. (p. 160)