QA Checklist Snippets for Release Testing

A release tested from memory is tested differently every time. Someone checks the happy path and ships; the next release skips the migration step; a third forgets to verify the rollback. The checks are not hard — they are just never written down in the place you actually do the testing. A small set of QA checklist snippets fixes that: you paste the right checklist into the PR, issue, or test note with a short trigger, and every release runs the same gauntlet.

This guide gives you a starter set of release-QA checklists and a way to drop them into your workflow without retyping the list.

Why a pasted checklist beats a remembered one

Release QA fails in the gap between "we have a process" and "the process is right here while I test." A checklist stored in a wiki is a checklist nobody opens mid-release. A checklist you can type into the PR description in one trigger is a checklist that gets filled — because it is already where you are working, with checkboxes waiting.

Pasting the checklist into the artifact also leaves a record. The filled list lives on the PR or the release issue, so the next person can see exactly what was verified, and a missed box is visible instead of assumed.

How do I reuse a QA checklist in a PR or issue?

PR descriptions, issue bodies, and most test-tracking fields are plain web text areas, so a browser-based text expander can insert a full checklist:

1. Save each checklist as a snippet with a clear trigger — //qaweb, //qaapi, //qarelease.
2. Open the PR description or release issue you are testing against.
3. Type the trigger, and the full checklist appears as Markdown checkboxes.
4. Work the list, ticking boxes and adding notes as you verify each item.

Because the snippets live in the browser, the same checklists work across your code host, issue tracker, or any web field your team tests in. SlashSnip inserts the text; it does not run tests, gate a merge, or talk to CI — it makes the manual checklist consistent and visible, sitting alongside whatever automated checks you already have.

A starter set of release-QA checklists

Start with three: a general release gate, a web-surface pass, and an API/data pass.

Release gate (//qarelease)

## Release QA — {{date}}

- [ ] Build is the release build, not a debug build
- [ ] Changelog / release notes updated
- [ ] Migrations run cleanly on a copy of prod-like data
- [ ] Rollback path verified (not just forward)
- [ ] Feature flags set to intended state
- [ ] Smoke test of the critical user path passes
- [ ] No new errors in logs during smoke
Tested by: {cursor}

{{date}} stamps the run; {cursor} lands on the sign-off line.

Web-surface pass (//qaweb)

## Web QA pass

- [ ] Renders correctly in light and dark themes
- [ ] Mobile and desktop breakpoints (no overflow, no overlap)
- [ ] Empty / loading / error states each show
- [ ] Keyboard navigation + visible focus
- [ ] Forms: invalid input handled, success + failure messaging
- [ ] Links resolve (no 404s introduced)

API / data pass (//qaapi)

## API / data QA pass

- [ ] Auth required where expected; unauth path is fail-closed
- [ ] Invalid payload rejected before business logic
- [ ] Idempotent endpoints stay idempotent on retry
- [ ] Rate-limit / abuse guard still triggers
- [ ] No secrets or PII in the response or logs
- [ ] Backward compatibility for existing clients

Use variables so the checklist stamps itself

The checklists use the four public SlashSnip variables so the repeatable parts fill in:

• {{date}} stamps the QA run so the record reads in order.
• {{time}} helps when you log multiple passes in a day.
• {{clipboard}} drops in a build hash or release link you just copied.
• {cursor} lands where you start typing — usually the sign-off.

The smart variables reference covers the exact syntax. A note on Markdown: many PR and issue editors are rich-text surfaces, so test that your - [ ] checkboxes paste as intended before you rely on the format.

Keep the lists short and tied to real failures

A QA checklist earns its place by catching the things that actually broke before, not by being exhaustive. Two rules:

• Cap each list at six to eight items. A 30-item checklist gets skimmed, not worked.
• Add a line only after a real miss. When a release breaks on something the list did not cover, that is the moment to add the item — earned checks, not theoretical ones.

For the pre-merge, per-change side of quality, the code review checklist snippets guide covers a different stage. One thing to settle early: snippets are stored locally per browser, with no shared team library or cloud sync yet, so a team keeps one set of QA lists by agreeing on triggers and sharing the snippet text directly.

Next steps

Save the release gate first — it is the list most teams run from memory — then add the web and API passes. SlashSnip for developers shows where browser snippets fit an engineering workflow, and the current plan details cover the free tier.