What is Smoke Testing?

What is smoke testing?

Smoke testing is a fast, shallow set of checks that runs against a fresh build to confirm the system is stable enough to deserve deeper testing. The name comes from hardware QA: power the board on; if smoke comes out, stop. In software, it answers a single question: did the build break something so fundamental that no further test will give useful signal?

A smoke test exercises the most critical paths only. Home page renders. Login works. A core API endpoint returns 200. The database connection opens. If any of those fail, the build is rejected and the rest of the test suite is skipped, saving CI minutes and surfacing the regression in seconds rather than after a 40-minute full run.

Smoke testing vs regression testing vs full QA

Three concentric circles of coverage, each answering a different question:

• Smoke testing: is the build runnable at all? Seconds to a couple of minutes. Runs first.
• Regression testing: did this change break anything that worked before? Minutes to an hour. Runs after smoke passes.
• Full QA / acceptance testing: does every feature still meet spec? Hours, often manual. Runs less frequently.

Smoke is the gate. Skipping it means a broken-deploy regression slips into the regression suite and burns the full CI budget before the failure is even reported.

What a smoke test covers

• Application start. The process boots without crashing. Health endpoint returns 200.
• Critical user flows. Sign-in, the main feature path, checkout (if commerce), one API call against the most-used endpoint.
• Integration handshake. The app connects to its database, cache, message queue. No timeouts at boot.
• Static asset availability. The main JS bundle and CSS load from CDN with a 200, not a 404 from a stale hash mismatch.
• Configuration sanity. Required env vars resolve. No undefined in the rendered HTML.

What a smoke test does not cover: edge cases, validation errors, every branch of a workflow, performance under load. Those belong in regression or in a load test.

When to run a smoke test

1. On every CI build. First stage of the pipeline. If it fails, the pipeline stops and nothing else runs.
2. Post-deploy to staging or production. Confirms the deploy actually came up before traffic is routed to it. Blue-green deploys gate the cut-over on smoke pass.
3. After infrastructure changes. New DNS, new TLS cert, new database failover target. Smoke verifies the integration still works end-to-end.
4. Before a release-day load test. No point running a 30-minute load test against a build whose login is broken. Smoke first, load second.

Key smoke-test characteristics

• Fast. Seconds, not minutes. If smoke takes 10 minutes it stops being smoke and becomes a mini regression suite.
• Deterministic. Flaky smoke tests destroy trust in the pipeline. Eliminate timing dependencies, retry on transient network only.
• Build-blocking. A failed smoke test stops the pipeline. No "yellow" smoke status.
• Cheap to author. Five to fifteen HTTP checks plus a few JS assertions. Don't over-engineer.

How to run a smoke test

For HTTP-based services, a short JMeter or k6 script with 5-15 critical-path requests is a solid smoke harness. In k6, set vus: 1, iterations: 1 and add check() assertions on status and body. In JMeter, use a Thread Group with 1 user, 1 loop, and Response Assertions on every sampler.

For browser-side smoke, a 60-second Playwright or Cypress script that logs in, lands on the main feature, and asserts on a known DOM element is sufficient. Anything longer belongs in regression.

For deploy-time smoke against a real cloud environment, run from LoadFocus. Smoke tests that ran on a developer laptop don't tell you the production CDN, DNS, and TLS chain work; smoke from a cloud region against the public endpoint does.

If your team doesn't have time to design and maintain smoke harnesses across multiple services, LoadFocus offers load testing services where engineers build the smoke scripts, wire them into your CI/CD, and keep them maintained as the API surface evolves.