Before each release: write the scope and the must-not-break list, test new features, run regression tests, check integrations, security, speed, accessibility, browsers and devices, data and backups, and sign off in writing with known issues and a rollback plan.
This is the main guide in our testing series. The guides below cover when to automate and the QA process step by step.
1. Scope and risk
Write down before testing starts:
- What changed in this release: features, fixes, dependencies, settings.
- What must never break: login, payments, the main user tasks, data.
- Which areas the changes touch, and so where regression risk sits.
- Who tests what, and by when.
2. Functional tests of new and changed features
Test what the release adds:
- Each new feature against its acceptance criteria.
- Each user role and permission that touches it.
- Edge cases: empty, very long and invalid input; slow connections; cancellations.
- Error messages say what went wrong and how to fix it.
3. Regression tests
The ISTQB glossary defines regression testing as testing a previously tested program after modification, to check that changes did not create or expose defects in parts that were not changed. Keep a regression suite of the must-not-break flows and run it on every release; these repeat every time, so they are the first candidates for automation.
4. Integrations
Where the software exchanges data with other systems (payments, CRM, accounting, email, single sign-on), test that data moves both ways correctly, that failures are handled and reported, and that test and live credentials are not mixed up.
5. Security
Check the release against the most common weaknesses. The OWASP Top 10, whose current edition is 2025, is the usual starting list:
- Access control: users see and do only what their role allows (Broken Access Control is A01).
- Configuration: no debug modes, default passwords or open admin pages in production.
- Dependencies: libraries updated and checked for known vulnerabilities.
- Input handling: forms and APIs reject injected code.
- Logging: security events are recorded and alerts reach someone.
6. Performance and speed
Check the main pages and tasks against web.dev's Web Vitals: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint within 200 milliseconds and Cumulative Layout Shift within 0.1. For systems under load, test the expected peak number of users and watch response times and errors.
7. Accessibility
Check keyboard use, focus order, labels, contrast and target sizes against WCAG 2.2 Level AA, the current W3C Recommendation; US rules such as the ADA Title II rule cite WCAG 2.1 AA, which 2.2 includes. Automated scanners catch some issues; a manual pass with a keyboard and a screen reader catches more.
8. Browsers and devices
Test on the browsers, operating systems and screen sizes your users have, taken from your analytics, including at least one real phone of each main platform. Check that layouts hold at small widths and that touch targets work.
9. Data, migrations and backups
Data mistakes are the hardest to undo:
- Database migrations tested on a copy of production data.
- A fresh backup taken before release, and a restore tested recently.
- Personal data handled as your privacy policy says.
- Reports and exports still match after the change.
10. Sign-off and release
Sign off in writing: what was tested, what passed, known issues and why they are acceptable, and who approved. Have a rollback plan ready, and monitor errors closely in the hours after release.
Two of the delivery measures in the DORA metrics guide (last updated January 2026) track exactly this: change fail rate and failed deployment recovery time. A good checklist lowers the first; a rollback plan shortens the second.
Conclusion
A pre-release testing checklist covers scope and risk, functional tests, regression tests, integrations, security against the OWASP Top 10, speed against Core Web Vitals, accessibility against WCAG 2.2, browsers and devices, data and backups, and a written sign-off with a rollback plan. Automate the regression checks that repeat, and keep the rest as a list someone ticks every time.
PromotEdge International is an international strategy, technology, marketing and design company, and our delivery team is in India. Our testing team runs manual and automated checks before every release, and our QA testers can join your team by the hour or full-time.
The guides in this series
This is the main guide in our testing series. Each guide below goes deeper on one part and links back here.
- Manual vs automated testing: when each pays, and what to automate first.
- The QA process: the steps from requirements to release, and who does what.
Facts we rely on: see our company facts for what we state about ourselves and where each fact comes from.