Smoke Testing

Smoke testing (also called build verification testing) is a preliminary test that checks whether the most critical functions of the software work. It's the first line of defense after a new build is deployed, answering one simple question: "Is this build stable enough to invest more testing time in?" The term comes from hardware testing — if you plug in a device and it literally starts smoking, you don't need to run the full test suite to know something is wrong.

Characteristics of effective smoke tests:

• •Fast: Usually 15-30 minutes for manual execution, seconds to minutes for automated runs
• •Critical Path Only: Covers the most essential user journeys, not edge cases or rare scenarios
• •Shallow and Broad: Surface-level verification across many areas rather than deep testing of one area
• •Go/No-Go Decision: The primary output is binary — proceed with more testing, or reject the build
• •Stable: Smoke tests should almost never fail due to test issues — only due to real problems
• •Automated When Possible: Ideally triggered automatically on every deployment
• •Independent: Each smoke test should stand on its own without complex dependencies

If smoke tests fail, the build is rejected and sent back to development for fixes. Further testing is halted until a stable build is available. This prevents the common waste scenario where testers spend hours executing detailed test cases against a build that has fundamental issues — like the app won't even start, or the database connection is broken, or a critical dependency is missing. Finding these problems quickly saves everyone time.

A common misconception is that smoke testing and sanity testing are the same thing. While related, they serve different purposes. Smoke testing is broader — it checks whether the whole build is stable enough for testing. Sanity testing is narrower — it checks whether a specific bug fix or feature change works as expected before investing in full regression testing. In practice, many teams blur this distinction, but the conceptual difference matters when planning your testing approach.

The biggest mistake teams make with smoke tests is letting the suite grow too large. A smoke suite should be ruthlessly curated. If it takes more than 30 minutes to run, it's no longer serving its purpose as a quick stability check — it's become a mini regression suite. When team members suggest adding tests to the smoke suite, ask: "Would this test's failure mean the build is fundamentally unstable?" If the answer is no, it belongs in the regression suite, not the smoke suite. Another mistake is having smoke tests that are too environment-dependent or flaky. A smoke test that fails intermittently trains the team to ignore smoke test failures, which defeats the entire purpose. If a smoke test is flaky, fix it or remove it — there's no middle ground.

In practice, mature teams integrate smoke tests into their CI/CD pipeline so they run automatically after every deployment. The typical flow is: code is merged, the CI builds and deploys to the test environment, smoke tests run automatically, and the team is notified of the result. If smoke tests pass, the build is marked as eligible for further testing. If they fail, the build is automatically rolled back or flagged, and the team investigates immediately. Some teams run different levels of smoke tests: a minimal 5-test suite after every commit, a broader 20-test suite after deployment to staging, and a pre-production verification before the final go-live. This tiered approach provides fast feedback at every stage without overloading any single checkpoint.