Pre-release QA checklist for teams without a QA engineer

This is a working checklist for B2B SaaS teams that don't have a QA engineer and need to ship reliably anyway. It takes about 15 minutes if done manually, less if you've automated the items via a regression suite.

The goal isn't comprehensive coverage. It's catching the embarrassing classes of bug (login broken, dashboard blank, signup form rejecting valid input) before customers do.

How to use this

Three modes, depending on where you are:

• Manual. One person clicks through the checklist on the staging URL before each promotion to production. ~15 minutes. Good for first month or two.
• Semi-automated. Half the checklist is automated (auth, critical paths), half is manual (browser sanity, perf smoke). Run automated bits on every deploy, manual bits weekly.
• Fully automated. Every item except subjective ones is in your regression suite. The suite runs on every staging deploy and gates promotion.

Don't aim for fully automated on day one. Aim for manual coverage of the right items, then automate over time as you find which ones actually catch things.

The checklist

What's intentionally not on this list

• Cross-browser (Firefox, Safari). If you're 5-50 engineers, your customers are 90%+ Chromium. Add this when the data shows it matters.
• Visual regression / pixel diffs. Too noisy. Use only after exhausting other signals.
• Accessibility audit. Important, but a separate concern with its own tooling cycle. Run quarterly with axe or Lighthouse, not pre-release.
• Load / stress testing. Different category. Run before scale events (launch, big customer onboarding), not before every release.
• Penetration testing. Annual third-party audit, not pre-release.

When to revise this checklist

Revise after every customer-reported regression. The pattern: regression slips through, customer reports it, postmortem identifies that the affected flow wasn't on the checklist. Add it. Repeat.

Within 6 months of disciplined use, this checklist tends to grow from 14 items to 20-25, with the additions being the exact paths your specific product is most fragile on. Don't fight that growth. The list is supposed to evolve.

What you should fight: items that have been on the list for three months without ever catching anything. Those are dead weight. Delete them.

Why 14 items and not 40

The instinct, the first time a regression embarrasses you, is to write a giant checklist that covers everything. Those lists die fast. A 40-item list takes 45 minutes, so it gets run in a hurry, or skipped on the exact Friday you most needed it. A list nobody runs catches nothing.

Fourteen items is short enough to actually run before every release and long enough to cover the flows that break most often: auth, the core revenue action, and data that has to persist. In ten years of QA work the same truth held everywhere I saw it: coverage you run beats coverage you wrote once and abandoned. Keep the list at a length your team will run under pressure, and let it grow only when a real bug proves a gap.

Make it a release ritual, not a hero task

A checklist only works if it is wired into how you ship, not left to whoever happens to remember. Three things make it stick:

• One owner per release. Rotate it if you like, but exactly one person runs the list and signs off before promotion. Shared responsibility is no responsibility.
• Run it on staging, against real data. A pass on a clean local environment proves little. The bugs live in the messy staging state that actually resembles production.
• Gate the promotion. The checklist is done before the release, not after. If an item fails, the release waits. The first time you ship anyway and it bites you, the gate earns its respect.

The moment this starts to feel painful enough to dread is the moment to automate the mechanical half, so the human only does the parts that need judgment.

Common questions