QA audit before release: what to check before you ship
A practical checklist for teams that want to reduce production risk before release without adding process theatre.
Why run a QA audit right before release
The final days before release are usually the riskiest. The feature is “done”, the team is already shifting focus, and changes often reach production after only partial validation on staging.
A short QA audit is not about blocking the release. It is a focused check that the highest-impact business scenarios work and that known issues have an owner and an explicit decision.
Minimum viable release checklist
The exact checklist depends on the product, but a few areas should be part of almost every release.
- Critical user flows: sign-up, login, checkout, form submission, primary CTA paths.
- Regression of the riskiest areas: parts touched by the change, integrations, roles and permissions.
- Basic technical checks: JavaScript errors, broken links, error states, responsiveness.
- Performance and accessibility sanity checks: Core Web Vitals, keyboard navigation, contrast, form errors.
- Release decision log: what is a blocker, what is accepted risk and who approved it.
When this audit brings the highest value
It delivers the most value before a larger release, redesign, checkout change, onboarding update or campaign launch. That is where bugs are both the most expensive and the most visible.
If you need an independent check before deployment, a standalone QA audit makes sense. If releases happen often, the better move is to turn that audit into a repeatable release process supported by automation.