Smoke Test Suite Template for Agile Teams

Between 5 and 15 for most products. The smoke suite should cover critical paths only. If you have 30+ smoke tests, you have likely included tests that belong in the full regression suite. The goal is speed: the entire suite should complete in under 3 minutes. Every additional test adds execution time and maintenance burden. If a path is not worth immediate alerting on failure, it is not a smoke test.

Yes, but carefully. Production smoke tests should be read-only or clean up after themselves. Do not create real users, send real emails, or process real payments in production smoke tests. Use a dedicated smoke test account with known state. Production smoke tests catch infrastructure issues that staging tests miss: CDN problems, DNS issues, third-party service failures. Run them after every deployment and on an hourly cron.

In practice, these terms are often used interchangeably. If you want to distinguish them: smoke tests run before any other testing to verify build stability. Sanity tests run after bug fixes to verify that specific fixes work and did not introduce regressions. A smoke suite is broader (covers all critical paths). A sanity check is narrower (covers the specific area that was fixed). The [QA signoff template](/templates/qa-signoff-template) covers the full signoff process that follows smoke testing.

There is overlap, but they are not identical. E2E tests for critical paths may include multi-step flows, edge cases, and detailed assertions. Smoke tests for the same paths should be minimal: can the user do the thing? Does the page load? Does the API respond? Smoke tests favor speed over depth. E2E tests favor thoroughness over speed. Extract the "happy path, no edge cases" version of your E2E critical path tests for the smoke suite. See the [e2e test template](/templates/e2e-test-template) for structuring the full E2E suite.

A flaky smoke test is a high-priority bug. If your team starts ignoring smoke failures because "it's probably just that flaky test," you lose the entire value of the suite. Quarantine flaky tests immediately: remove them from the blocking suite and create a ticket to fix within 48 hours. If the test cannot be stabilized, delete it and replace it with a more deterministic version that tests the same path differently. ---