19/08/2026
Before I say “this web application is ready for release,” I check more than whether the new feature works.
A feature can work perfectly in one test scenario and still create problems for real users.
My practical pre-release checklist usually looks like this:
✅ Critical user flows work
✅ Forms and validations behave correctly
✅ Error and edge cases are handled
✅ APIs and third-party integrations are working
✅ Browser and responsive behavior looks good
✅ Recent changes have been regression tested
✅ Critical/high-severity bugs are understood
✅ Production configuration has been reviewed
✅ Known limitations are documented
✅ The team understands the remaining release risk
One thing I particularly try to avoid is testing only the “happy path.”
Users don't always enter the expected data.
They don't always follow the intended flow.
And production doesn't always behave exactly like staging.
That's why I see release testing as more than bug hunting.
The real question is:
“Do we have enough confidence to release this without surprising our users?”
That’s the standard I find much more useful than simply asking whether all test cases passed.
What would you add to this checklist?
Comment with the one release check you think QA teams should never skip.
