Smoke Testing Checklist After Release

A smoke test asks whether a release’s basic, critical functions work well enough to continue deeper testing. Choose a small representative journey, record the exact build and environment, and check each observable result. Keep every unrun case Not tested; a blank or quiet report is not a pass. MDN’s smoke test definition places critical-function checks before more in-depth testing.

This guide uses a fictional web app’s draft workflow. Substitute your own critical task and safe test data. A smoke pass does not certify the release, cover every regression, or grant business approval. The UAT plan defines who can decide business acceptance; the UAT checklist builder records scenario outcomes for that separate review.

All four rows below are planned examples, not executed tests. The expected result makes each check actionable; the initial status remains Not tested.

Stop using the affected journey as a basis for broader QA until an owner reviews the build, steps and evidence. Mark an observed mismatch Fail; use Blocked when a missing prerequisite prevents the check from running. Leave unrun checks Not tested and assign investigation. After a candidate fix, repeat the failed check on the named build and record the new result. A failed smoke does not by itself trigger a production rollback; that decision belongs to the release owner using the actual impact and release process.

The following is an invented failure record, not an observed defect in ContextCapture or a customer app:

Fictional failed smoke — staging build r12
Check: Recovery after saving a safe test draft
Steps: Sign in; open test draft; change title; save once; refresh; reopen draft.
Expected: The new title remains visible after refresh.
Actual: The old title appears after refresh in this invented attempt.
Status: Fail for this check. Other journeys: Not tested.
Evidence to review: browser/version, time, screenshot, request or console excerpt.
Next action: Pause this draft journey; owner checks build and evidence, then retests.

For the fictional draft release, sign-in and navigation establish that the tester can reach the changed journey; save and reopen check its useful result. If sign-in is Blocked by a missing test account, mark the later checks Blocked because their prerequisite is unavailable, then restore the account before running them. If sign-in passes but reopening shows the old title, mark recovery Fail and pause deeper draft testing for that build.

A list-filter setting outside this release’s critical draft path can be scheduled for deeper regression work, with its omission recorded. This is a risk choice for the example, not a promise that four checks cover the release. MDN’s smoke test definition frames these checks as a first screen of critical functionality.

Copy this static checklist to your release notes. Replace expected outcomes with your own critical journey, then update each status only after a real run. No test executes on this page.

Smoke check — [environment and release/build]
Tester / time: [name or role, timestamp]
Test account and safe data: [nonprivate identifiers]
Sign in: Not tested | Expected: test account reaches its home page
Navigate: Not tested | Expected: draft list opens and target draft can be selected
Save: Not tested | Expected: one safe draft edit shows confirmation
Recovery: Not tested | Expected: after refresh, the saved draft still shows the edit
For each run: [steps, actual visible outcome, evidence link, Pass/Fail/Blocked]
If a critical check fails: [affected journey, build, owner, reviewed evidence]
Next decision: [pause affected journey / investigate / retest; owner and reason]

For the wider release review, use the website launch checklist. A failed check can go into the bug triage worksheet with reproduction steps; the sample report shows how reviewed evidence reaches a developer.

Published October 9, 2026. Updated October 10, 2026. The draft workflow and failure record are fictional teaching examples; no smoke test or release approval occurred here.