Smoke Testing in Software: What to Check After Every Deployment

The name comes from hardware: switch the device on and see if it smokes. In software, the equivalent question is whether the release is fit to test further or fit to keep in production. A missing configuration value, an expired API key or a failed database migration can break a release completely while every unit test still passes.

A smoke test should cover the few user journeys and integrations a business cannot run without, finish in minutes, run automatically after every deployment and block or roll back the release when it fails, because its job is to catch total failures early.

This article explains what smoke testing is, how it compares with sanity and regression testing, what to include, how to automate it after each deployment and what a real post-deployment smoke suite caught. It does not cover load testing or full test strategy design.

Key takeaways

• A smoke test checks that a build or release works at the most basic level. It is broad and shallow, not deep.
• Sanity tests check a specific fix or change. Regression tests check that existing features still work in depth.
• Include startup and health checks, sign-in, the one or two journeys that bring in money, key integrations and configuration.
• Keep the suite under about five minutes, so it can run after every deployment to every environment.
• Run it against production too, with test accounts, and connect it to alerts or automatic rollback.
• In a delivered project, k6 smoke tests running after every deployment to QA, pre-production and production catch integration errors before users do.

Smoke, sanity and regression testing compared

Teams sometimes use the terms loosely. What matters is that each kind of test has a clear purpose and a clear owner, and that the fast checks run first.

What to include in a smoke test

Leave out edge cases, detailed validation rules and layout checks. Those belong in regression tests. A smoke test that grows to 40 minutes stops being run after every deployment, which defeats its purpose.

How to automate smoke tests after every deployment

1. Pick the journeys. List the five to ten actions that would make the product useless or lose money if broken.
2. Write them as automated tests. API-level checks are fast and stable. Add one or two browser tests for the most important screens.
3. Use dedicated test accounts and data. Create accounts and records that exist in every environment, are clearly marked and never trigger real emails, charges or orders.
4. Run after each deployment. Add the suite as a pipeline step that runs against the environment that was just deployed: QA, staging and production.
5. Make failure stop the release. In lower environments, a failure blocks promotion. In production, it pages the on-call engineer or triggers an automatic rollback.
6. Report clearly. Show which check failed, with the request and response, so the cause is visible in seconds.
7. Keep it fast and stable. A smoke test that fails at random teaches people to ignore it. Fix or remove unreliable checks quickly.

Smoke testing in production

Running smoke tests in production finds problems that staging cannot: production configuration, real third-party credentials, DNS and certificates. Use separate test accounts, payment provider test modes where the provider allows them in production, and markers that exclude test traffic from analytics and reports. Many teams also run the same checks every few minutes as synthetic monitoring, which turns the smoke suite into an early warning system between deployments.

Smoke tests with canary releases

When a release goes first to a small share of users or servers, a practice the Google SRE workbook calls canarying, run the smoke suite against the new version before widening the rollout. If it fails, only the canary is rolled back.

A post-deployment smoke suite in practice

A US media company runs webcast registration across three brands. Single sign-on goes through Auth0, event data syncs with Swoogo and ON24, and the sites run on Next.js, WordPress and Symfony. With this many moving parts, a release could pass its own tests and still break registration, because an integration, a template or a configuration value had changed elsewhere.

.wrk added k6 smoke tests to the GitHub Actions pipeline. They run after every deployment to the QA, pre-production and production environments, and they check the registration flow and the integrations behind it. The same work moved password entry to the identity provider's domain, so password managers work across brands, made webcast registration one click for signed-in users and replaced polling of the event platform with webhooks. Integration errors are now caught by the smoke suite before users report them. Read the SSO and webcast registration case study.

For a threat intelligence platform at the same company, integration testing and smoke tests in the CI/CD pipeline run before every production rollout, alongside automated code review. Read the NEXUS case study.

Tools for smoke testing

Choose tools your team already uses for other tests where possible. The k6 documentation describes a smoke test as the first step before heavier performance tests, which is a useful habit: if the smoke test fails, there is no point running the load test. Our guide to load testing covers the next step.

Common smoke testing mistakes

• Making it too big. A long suite gets skipped or moved to nightly runs, and broken releases slip through.
• Testing only the build, not the deployment. Many failures come from configuration, secrets and infrastructure in the target environment.
• Skipping production. Staging rarely matches production exactly. A short production check catches what staging misses.
• Using real customer accounts. Test data must be separate, clearly marked and safe to repeat.
• Ignoring failures that seem random. Unstable checks hide real failures. Fix or remove them.
• No connection to action. A failed smoke test that nobody sees does not protect users. Connect it to blocking, alerts or rollback.

If your team has inherited a system without tests, our guide to software project rescue explains where smoke tests fit in the first 30 days of a takeover.