top of page

Smoke Suite Starter Worksheet

S. West
1 hour ago
5 min read

Smoke Suite Starter Worksheet

The smoke stage had grown to 25 minutes. The team began skipping it on urgent deploys, and the urgent deploy they skipped it on broke checkout.

It had started as six quick checks, then collected form validation, every user role and a report export, one cheap-looking addition at a time. Engineers learned to skip it when a hotfix was waiting. One Friday a hotfix carried a migration that locked the orders table, and customers saw a spinner at payment for most of an hour.

(Composite example, assembled from patterns common in teams whose smoke checks have grown into a slow end-to-end suite. The figures are illustrative.)

A smoke suite earns its place by being cheap enough to run on every deploy, and loses it once people start bypassing it. This worksheet starts from that constraint: check only the few things your product cannot ship without, keep the run short, and make a failure stop the deploy.

The rule that keeps you honest: As a deploy gate, a smoke suite that takes 30 minutes has stopped doing its job. The whole reason smoke exists in a pipeline is to fail fast.

McConnell (1996) notes that a daily-build smoke test can grow well beyond a few minutes as a system matures. That suits a nightly build; this worksheet is about the smoke stage that gates a deploy.

Step 1: pick the core user actions

List the three to five actions your product is worthless without. If you could not release with one broken, it qualifies.

  • ☐ Action 1: ______

  • ☐ Action 2: ______

  • ☐ Action 3: ______

  • ☐ Action 4 (optional): ______

  • ☐ Action 5 (optional): ______

For a typical web app: the app loads, a user signs in, the main page shows their data, the primary action completes, the user signs out.

Step 2: write one happy-path test per action

For each action, write a single end-to-end test of the normal path. No edge cases and no alternate roles.

#

User action

Test (happy path, end to end)

Pass means

1

______

______

______

2

______

______

______

3

______

______

______

4

______

______

______

5

______

______

______

  • ☐ Added a liveness check: request the homepage and expect HTTP 200.

These belong in your broader suite. If any crept into the table, cut it:

  • ☐ Edge cases in business logic.

  • ☐ Every user role and permission boundary.

  • ☐ Every platform and browser.

  • ☐ Validation rules and error paths.

  • ☐ Performance regressions.

  • ☐ Subtle UI defects.

Step 3: keep it fast

Speed is the point. Our rule of thumb: target under two minutes, and treat five minutes as the outer limit.

  • ☐ Suite is small: roughly 5–20 tests (a rule of thumb, not a standard).

  • ☐ A full run finishes inside the outer limit, and ideally inside the target.

  • ☐ Tests run in parallel.

  • ☐ Setup the smoke flow doesn't need is skipped.

  • ☐ State is created through the API where possible, then checked through the UI.

  • ☐ Third-party dependencies are avoided where you can.

  • ☐ Smoke runs as the first stage of the pipeline, before any other test phase.

Measured runtime of your suite: ______ (the real number, not the target)

Step 4: wire smoke to the deploy

A check that fails while the deploy carries on produces nothing. Tie the result to an action: deploy, run smoke, then continue on pass or roll back on fail.

  • ☐ Smoke runs automatically on every deploy, to every environment.

  • ☐ On pass, the deploy continues.

  • ☐ On fail, the deploy rolls back automatically.

  • ☐ For canary or blue-green releases, smoke runs against the new version before traffic shifts.

  • ☐ Smoke also runs before every manual or automated test run.

  • ☐ Smoke is available as a health check during incident response.

  • ☐ In production, smoke uses a dedicated test account or tenant and test-mode payments, so it never creates real orders.

Step 5: read failures as a diagnostic

A failing test already narrows the search. Fill in the last column so on-call knows where to start.

Smoke failure

Points at

Your owner or first place to look

Application doesn't start

Infrastructure or build

______

Login fails

Auth service or session

______

Primary action fails

Backend or database

______

Page doesn't render

Frontend or asset delivery

______

Step 6: keep it from rotting

Stale smoke is silent: it passes while real failures happen, which can be worse than no smoke at all, because it looks like coverage.

  • ☐ When a primary flow changes, smoke is updated first.

  • ☐ When a smoke test breaks, it is fixed immediately, or removed if obsolete.

  • ☐ No test is "run but ignored because it's flaky".

  • ☐ Someone reviews, on a schedule, whether smoke still covers what matters.

  • ☐ (Production option) Run a synthetic transaction every few minutes (pick an interval that fits your alerting) as continuous verification, and alert if it fails.

Reference: a worked smoke suite (illustrative e-commerce example, ~90 seconds, 8 tests)

  1. GET / returns 200 with the expected HTML structure.

  2. POST /api/auth/login with test credentials returns a token.

  3. GET /api/user/me with the token returns the test user.

  4. GET / with the token shows the signed-in UI.

  5. GET /api/products returns at least one product.

  6. POST /api/cart with a product adds it.

  7. GET /api/cart returns the added item.

  8. POST /api/checkout in test mode completes.

Step 7: check for the four anti-patterns

  • ☐ Smoke as end-to-end: a comprehensive UI suite labelled "smoke", too slow to gate anything.

  • ☐ Smoke as health check: a single ping, too shallow to notice a broken core flow.

  • ☐ Smoke without rollback: it runs, it fails, and the deploy goes ahead anyway.

  • ☐ Smoke ignored: "it's flaky, so we run it and ignore the failures".

If you ticked any of these, fix that first.

How to use it

  • Who: whoever owns the release pipeline, with one person who knows the core flows. In our experience Steps 1 to 3 take about an hour; Step 4 is a pipeline change.

  • Output: core actions with one test each, a measured runtime, a rollback-on-failure stage and a failure-to-owner map.

  • Done when: the suite runs on every deploy inside your outer limit, a test failure has been shown to trigger a rollback, and no anti-pattern box is ticked.

Where this changes

A solo developer or small team can start with three checks and a manual rollback, as long as nothing ships while smoke is red. Larger systems need a suite per service, a cross-service suite for the main journeys and a named owner per failure area. Regulated environments may need smoke results kept as release evidence.

The reasoning is in Smoke Testing: The Five-Minute Quality Gate. To build the suite step by step, follow Build a Smoke Test Suite; to make a red result stop the release, read Quality Gates That Actually Gate.

Final takeaway

A smoke suite is only valuable while it is quick enough that nobody skips it. Keep it to the actions you cannot ship without, make failure roll the deploy back, and review it before it turns into the regression suite.

Sources

bottom of page