Glossary
Smoke testing is a quick, surface-level validation that the most critical paths of an application work after a deployment or build. The term comes from hardware engineering: when you power on a new circuit board, you check if smoke comes out. If it does not smoke, you proceed to deeper testing.
A smoke test suite typically covers 5 to 10 critical user flows: can users log in, can they access the main dashboard, does the primary feature load, does the checkout process initiate? These tests are not comprehensive. They do not check edge cases, error handling, or secondary features. Their purpose is to answer one question: is the application fundamentally working?
Smoke tests are distinct from sanity tests and regression tests. Sanity tests verify that a specific fix or feature works as intended (narrowly scoped). Smoke tests verify that the overall application is not broken (broadly scoped but shallow). Regression tests verify that all existing functionality still works (broadly scoped and deep).
Smoke tests are the first line of defense after deployment. When a production deploy goes out at 3 PM on a Friday, a 2-minute smoke test that verifies login, dashboard, and checkout can catch catastrophic failures before users report them. Without smoke tests, teams rely on monitoring and alerting, which have a detection lag of minutes to hours depending on traffic volume.
The speed of smoke tests makes them suitable for deployment gates. A full regression suite that takes 45 minutes cannot gate every production deploy without slowing deployment frequency. A smoke suite that takes 2 to 5 minutes can gate every deploy without creating a bottleneck. Many teams run smoke tests post-deploy and automatically roll back if critical paths fail.
Smoke tests also serve as a sanity check during development. When an engineer pulls the latest main branch and wants to verify the application still works before starting a new feature, running the smoke suite takes 2 minutes versus 45 minutes for the full regression suite.
Most teams create smoke suites by selecting a subset of their E2E tests and tagging them with a "smoke" label. CI pipelines run the smoke-tagged tests on every deploy and the full suite on a schedule (nightly or per-PR). The challenge is keeping the smoke suite updated: as features change, the critical path definitions change, but the smoke tags often become stale.
Common smoke test patterns include: login flow (authentication works), main feature load (core value proposition renders), data creation (users can create primary records), and payment flow (revenue-critical path works). Teams in regulated industries add compliance-critical flows: audit log generation, permission enforcement, data export.
Some teams run smoke tests against production immediately after deploy using synthetic monitoring tools like Datadog Synthetic Tests or Checkly. These tools execute predefined user flows against the live application at regular intervals, serving as continuous smoke testing.
Zerocheck supports smoke testing as a tagged subset of your test suite. Critical-path tests can be flagged for post-deploy execution with faster turnaround. Because Zerocheck tests are written in plain English, the smoke suite reads like a checklist of critical user journeys that any team member can review and update without engineering effort.