Smoke Testing vs Sanity Testing: When to Run Each

Smoke testing is a shallow, wide pass on a new build: app starts, login works, primary navigation loads, critical APIs respond. Think of it as build verification. If smoke fails, you stop deeper testing — you do not burn a day on regression against a broken deploy.

In CI, smoke often means a small Playwright or API suite on every merge to main. Keep it under 10–15 minutes. Fail loud. Flaky smoke destroys trust faster than no smoke.

Sanity testing is a narrow, deep-enough check after a bug fix or small change. You retest the fixed area and nearby risk — not the whole product. If payment retries were fixed, sanity covers retry success, failure messaging, and one adjacent invoice view — not the entire billing encyclopedia.

Teams confuse the terms because both are “small.” The difference is intent: smoke gates the build; sanity gates the change. You can automate both; humans still catch context smoke scripts miss.

On deploy to staging: smoke first. On ticket “fixed”: sanity by the assignee or QA owner before moving to Done. Before production: smoke again on the production-like artifact, then targeted regression. Do not rename your entire regression suite “smoke” — that word should stay cheap.

Document a one-page smoke list (8–12 checks) and a per-area sanity cheat sheet. New contractors should run smoke without a 30-minute briefing.

If smoke is tribal knowledge in one engineer’s head, your next PTO week is a risk event. External QA can own the smoke pack and sanity templates while your eng team keeps shipping.

TestSync Lab includes release smoke and fix sanity in monthly retainers from $999. Start with a free QA audit at /contact. Chatbot and LLM checks are scoped separately from classic product smoke.