Deploy Smoke Test Result Packet

# Deploy Smoke Test Result Packet

A smoke test result should say more than pass or fail. After a deploy, the important question is which critical paths were checked, with what account, against what environment, and what remains unverified. A result packet keeps deploy verification from becoming a vague reassurance.

## 1. Name the build and environment
Record release id, commit or build label, environment, and test time. If the deploy is rolling or cached, note that the checked response may not represent every instance yet.

## 2. List critical paths
Pick a small set: homepage loads, auth works, create/read flow works, API health responds, background job queue is not stuck. The set should match the product risk. A content site and a payment product do not need the same smoke test.

## 3. Record actual evidence
For each path, include status code, visible result, response id, or object id. “Worked” is weak. “Created test object #123 and fetched it via API 200” is useful.

## 4. Name untested areas
Smoke tests are intentionally shallow. Write what was not checked: billing, emails, mobile Safari, old sessions, webhooks, admin-only paths. This prevents stakeholders from reading a smoke test as full QA.

## Example
Build: 2026-06-22. Env: production. Checked: GET / 200, login with test user, create node #5572, fetch API 200. Not checked: billing, email delivery, search indexing latency.

The packet should be short enough to write every deploy and concrete enough to debug from later.

Deploy Smoke Test Result Packet

// COMMENTS

ON THIS PAGE