A release is ready when its highest-risk user journeys have objective evidence, known defects have accountable decisions, production recovery has been rehearsed and the team can detect problems after launch. “All tickets complete” is not a quality standard. Start from business risk, test critical paths and exceptions, then make a documented go/no-go decision.
This checklist fits websites and business software, but it is not a substitute for specialist safety, financial, medical or regulatory assurance. Scale the depth of testing to the harm a failure could cause.
What should be agreed before testing starts?
Define the release scope, intended users, supported environments and acceptance criteria. Every requirement should be testable. Replace “easy to use” with named tasks users must complete; replace “loads quickly” with agreed measures, conditions and thresholds.
Identify risks in a short workshop with product, engineering, operations, support and subject experts. Consider financial loss, data exposure, exclusion, legal non-compliance, damaged records, interrupted operations and reputational harm. Rank likelihood and impact, then assign deeper testing to the largest risks.
Prepare:
- A release owner with go/no-go authority
- A list of changed components and dependencies
- Representative test accounts and permitted test data
- A stable test environment close enough to production
- Entry and exit criteria for each test phase
- A defect severity model and triage schedule
- A trace from critical requirements to test evidence
Have the critical user journeys been tested?
Test complete journeys, not only individual screens. For an ecommerce service that means finding an item, checking availability, paying, receiving confirmation, handling a failed payment and viewing the order internally. For a lead form it includes validation, consent, delivery to the correct team, CRM creation, notifications and failure handling.
Test as each relevant role, including unauthenticated, standard, manager and administrator users. Confirm that changing a URL or request does not grant access to another user’s records.
Cover valid, invalid, empty, duplicate, delayed and unusually large inputs. Check interrupted sessions and retries. A friendly error should tell users what happened, preserve safe input and offer a next step without exposing technical details.
Run regression tests across areas touched indirectly. A shared account component change can affect sign-in, checkout and profile management. Automation is valuable for stable, repeated checks, while exploratory testing is better at discovering unexpected interactions. Use both where risk justifies them.
Is accessibility part of acceptance?
Accessibility is a release requirement, not a final visual check. Set the target against WCAG 2.2 and test representative journeys with keyboard-only navigation, visible focus, zoom, high contrast and screen-reader use. Confirm labels, instructions, errors and status messages are programmatically available.
Automated tools find some patterns but cannot judge whether alternative text is useful, focus order is logical or a task is understandable. Include disabled users in research and testing where possible.
Check documents, videos and third-party widgets as well as page templates. Captions, transcripts and accessible document formats need owners. Public-sector bodies should also review the UK accessibility requirements for public-sector websites and apps.
Have security and privacy checks been completed?
Confirm authentication, authorisation, session expiry, password reset and multi-factor flows. Test that permissions are enforced by the server, not merely hidden in the interface. Review secrets, dependency findings, security headers, logging and rate controls according to the service risk.
Use secure, synthetic or appropriately controlled test data. Production personal data should not be copied casually into development environments. Verify privacy notices, retention behaviour, exports, corrections and deletion workflows where applicable. The ICO data protection guidance provides the UK framework.
The NCSC secure development and deployment guidance covers secure design, development and operation. Higher-risk systems may need independent penetration testing, but a penetration test does not replace secure engineering or functional QA.
Security and privacy checklist
- No secrets are stored in client code or logs
- Users can access only authorised records and actions
- Sensitive data is protected in transit and at rest as designed
- Logs avoid unnecessary personal or secret values
- Backups are encrypted, retained and restorable
- Dependencies and infrastructure are supported and patched
- Consent and preference changes reach connected systems
- Incident contacts and escalation routes are current
Are integrations and data migrations trustworthy?
For each integration, test normal responses, invalid credentials, rate limits, timeouts, duplicates, partial failures and recovery. Confirm retries are safe. A retried payment or order request must not silently create duplicates.
Reconcile migrated data using counts plus sampled records and business totals. Check relationships, attachments, dates, currencies, encoding and permissions. Document transformations and rejected records. Obtain business-owner sign-off rather than relying solely on a successful import message.
Test scheduled jobs around time zones, daylight-saving changes, month-end and empty queues where relevant. Confirm alerts fire when jobs fail and identify who responds.
Is performance acceptable under realistic conditions?
Measure important journeys on representative devices and networks, not only a developer laptop. Test expected concurrency and plausible peaks. Include third-party scripts, realistic data volumes and cold starts.
For public web pages, Core Web Vitals can provide useful user-experience indicators; Google documents the measures in its web vitals guidance. They are not a complete performance or business acceptance test.
Observe server response, database queries, asset delivery and client interaction. Define what happens when capacity is exceeded: queue, degrade a non-critical feature or return a controlled error. Performance fixes after launch can be expensive when architecture is already constrained.
Can the team deploy and recover?
Write the deployment plan as a sequence with owners, expected durations and verification points. Include database changes, cache handling, feature flags, third-party configuration and communication. Avoid combining unrelated risky changes simply because they share a date.
Define rollback honestly. Some database or external-system changes cannot be reversed by redeploying old code. In those cases, prepare forward fixes, backups or compensating procedures. Rehearse restoration and record how long it actually takes.
Launch-day checklist
- Scope and known-defect list are frozen and reviewed
- Production configuration has independent verification
- Backup or recovery point is confirmed
- Deployment and rollback owners are present
- Status, support and supplier contacts are ready
- Smoke tests cover every critical journey
- Monitoring dashboards and alerts are active
- Analytics and audit events are verified
- Customer communication is approved if needed
- Go/no-go decision and rationale are recorded
What should be monitored after launch?
Watch technical health and user outcomes. Monitor error rates, latency, queue depth, failed jobs, payment or submission success, authentication failures and support contacts. Compare with a known baseline and define alert thresholds before release.
Run production smoke tests immediately after deployment without damaging real data. Review logs for unexpected personal information. Keep the delivery team available during the agreed observation window and avoid declaring success after only a homepage check.
Schedule a review after enough real usage has occurred. Record incidents, near misses, user confusion and manual workarounds. Feed lessons into automated tests, documentation and the next release checklist.
How should defects affect the launch decision?
Severity should reflect impact and recoverability, not how dramatic a screenshot looks. A cosmetic defect on a rarely used page differs from silent corruption of customer records. Consider affected users, workaround quality, detectability and duration.
Every accepted defect needs an owner, rationale and review date. Do not relabel a release-blocking defect as minor merely to meet a deadline. Equally, zero known defects is not a realistic universal gate; make explicit, risk-based decisions.
Frequently asked questions
Is automated testing enough?
No. Automation is excellent for repeatable checks, but exploratory, accessibility, usability and operational testing require human judgement. Choose the mix by risk.
Who should sign off a release?
An accountable business or product owner should make the decision using evidence from engineering, QA, security and operations. QA informs readiness; it should not own every business risk.
When should penetration testing happen?
Allow time to fix and retest findings before launch. Scope it around system risk and major architectural changes, and confirm that the tester can safely assess the intended environment.
Should testing stop after launch?
No. Production monitoring, incident learning, dependency maintenance and regression testing continue throughout the service life.
