Execution checklist format

Deep reference for manual-test-script-author SKILL.md. A full step-table script is overkill for some situations:

• A 5-minute production smoke after every deploy.
• An on-call's "is it broken?" first-pass verification.
• A periodic (weekly / monthly) compliance check.
• A bug-bash kickoff (give every participant the same checklist).

For these, a focused checklist wins: ~10-30 items, each one line, each with a clear pass/fail. The whole list fits on one screen / one printed page; the runner sweeps through it in 5-15 minutes. This format converts a regression suite (or test plan) into that checklist.

When to use this format

• After a deploy, the team needs a fast "did anything obviously break" sweep.
• On-call rotations want a "is the system broken?" template they can run before paging others.
• A bug-bash needs the same checklist for every participant so coverage is consistent.
• A compliance review needs a periodic verification record.

If the use case is "test a feature thoroughly before release," use the full step-table format from the SKILL.md body instead - expected results per step.

Step 1 - Pick scope

A checklist's value is its focus. Scope by one of:

Wider scope = lower run frequency = less repeated value.

Step 2 - Convert each test case to one-line form

Source TCs from the step-table scripts or the existing regression suite. Compress each to a single line with three slots:

[ ] [feature]: [action] → [observable outcome]

Examples:

[ ] **Login**: enter `qa-test-user@example.com` + password from vault item `QA / qa-test-user` → dashboard loads in <3s.
[ ] **Cart**: add `BOOK-001` → cart count badge shows "1".
[ ] **Promo code**: apply `WELCOME10` → subtotal drops by 10%.
[ ] **Checkout**: click `Place order` → confirmation page within 5s.
[ ] **Email**: order confirmation arrives within 5 min.

If a step needs 3+ lines to express, split into multiple checklist items OR move it back to the full step-table format - the checklist isn't the right artifact for that step.

Step 3 - Group by flow

A 30-item flat list is hard to scan. Group:

## Production smoke - release `v1.4.5`

**Tester:** ___________________  **Date:** ___________________  **Time:** ___________________
**Environment:** prod | staging   **Build SHA:** ___________________

### Auth flow

- [ ] **Login** (existing user): `qa-test-user@example.com` + password from vault item `QA / qa-test-user` → dashboard <3s
- [ ] **Logout**: click `Sign out` → redirect to `/login`
- [ ] **Password reset**: click `Forgot password` → email arrives within 5 min

### Cart + checkout flow

- [ ] **Add to cart**: SKU `BOOK-001` → cart count badge shows "1"
- [ ] **Cart page**: navigate to `/cart` → item visible with qty 1, $24.99
- [ ] **Promo code**: apply `WELCOME10` → subtotal drops to $22.49
- [ ] **Checkout**: complete checkout with the Stripe test-mode Visa → confirmation page

### Account flow

- [ ] **Profile update**: change email → save → reload → email persists
- [ ] **Order history**: view past orders → most recent test order present

### Sign-off

**Pass / fail / partial:**
**Defects raised:** (list IDs)
**Notes:**

The flow grouping doubles as a coverage check - empty groups mean the smoke doesn't cover that flow.

Step 4 - Time-box and document

A checklist that takes "as long as it takes" gets skipped. Set an explicit budget per group:

| Group               | Items | Budget |
|---------------------|------:|-------:|
| Auth flow            |    3  |  3 min |
| Cart + checkout flow |    4  |  6 min |
| Account flow         |    2  |  3 min |
| **Total**            |   9   | 12 min |

If the actual run exceeds the budget by >50%, the checklist is too long; trim to the highest-signal items.

Step 5 - Pair with a defect-raising flow

Same as the SKILL.md body's defect-raising step - checklist failures need a path to a logged defect:

### Defects raised this run

| # | Item                                          | Observed                            | Severity | Bug ID  |
|---|-----------------------------------------------|-------------------------------------|----------|---------|
| 1 | Promo code: apply WELCOME10                   | Subtotal stayed at $24.99           | high     | BUG-987 |

Step 6 - Versioning

The checklist evolves with the product. Keep it in docs/:

docs/checklists/
├── prod-smoke-v1.md
├── prod-smoke-v2.md          ← current
├── on-call-first-pass-v1.md
└── bug-bash-checkout-v1.md

Bumping the version when the items change (rather than mutating in place) preserves the historical record - useful for audit ("what did the smoke check on 2026-04-15?") and for retrospective on incidents that the smoke missed.

Output format

## Test execution checklists - `<feature/area>`

**Generated from:** `<source - TC suite / test plan / story>`
**Total items:** N
**Total wall-time budget:** M minutes
**Scope:** smoke | first-pass | full sweep | compliance

(per-checklist bodies follow per Step 3)

### Coverage notes

- Auth flow: N items covering login + logout + password reset
- Cart flow: N items covering add + view + checkout
- Areas NOT covered (intentional): admin panel (out of smoke scope),
  internationalized currencies (covered weekly via `prod-smoke-i18n.md`)

Anti-patterns

Limitations

• Subjective pass/fail. A one-line check ("dashboard loads in <3s") relies on tester judgment. For exact-value checks, use the full step-table format.
• Coverage gaps invisible. A 10-item smoke won't catch a regression in the 100 areas it doesn't cover. Pair with full regression runs at lower frequency.
• Tester fatigue. Same checklist run daily becomes mechanical; testers stop noticing the failures. Rotate checklists per week / per tester to keep attention fresh.
• No automation parity. A passing manual checklist doesn't imply an automated suite would pass; the checks are different by design.

References

• bug-bash-facilitator - consumes a checklist as the bug-bash kickoff template.
• smoke-suite-gate (qa-process) - automated equivalent for CI-runnable smoke.