Software QA Checklist Before Release

Release readiness is a decision, not a test phase

A release checklist is useful only if it answers three questions: what did we verify, what remains unknown, and who accepts the remaining risk? Testing produces evidence. Release readiness turns that evidence into a decision.

This guide is a practical checklist for teams preparing a launch or a significant release. It works for a product built in-house and for software delivered by an external development partner. If you need independent verification, our quality assurance and software testing service covers test strategy, execution, automation, and release gates.

1. Define the release scope and risk

Start with the release itself, not a generic list of test cases.

• What changed since the last release?
• Which users, workflows, integrations, and data are affected?
• What is the cost of each failure mode?
• Which failures would be visible to customers, finance, security, or compliance?
• What is explicitly out of scope for this release?

A small release can still carry high risk if it touches authentication, payments, permissions, or data migration. A large release can be lower risk if it is isolated and reversible.

2. Confirm requirements and acceptance criteria

Testing without a definition of done becomes a debate about opinion. Before execution, confirm that the requirements have measurable acceptance criteria.

A useful acceptance criterion describes:

• The starting condition
• The action or event
• The expected result
• The evidence that proves it

For example, “the system should be fast” is not testable. “A standard search request returns results in under two seconds for the agreed test dataset” is. If the requirements are still ambiguous, fix that first. Our software requirements and delivery planning service can help turn a rough brief into testable requirements.

3. Build a risk-based test strategy

A test strategy should explain where testing effort goes and why. It does not need to be a large document. It needs to be specific to the release.

Cover these decisions:

• Test levels: unit, integration, end-to-end, and user acceptance
• Test types: functional, regression, API, performance, accessibility, and exploratory
• Environments: which environment matches production closely enough for the risk
• Test data: what data is needed, and how it will be protected
• Entry criteria: what must be ready before testing starts
• Exit criteria: what evidence is required before release
• Owners: who tests, who reviews, and who accepts risk

Not every release needs every test type. The strategy should make the trade-offs explicit.

4. Test the critical journeys manually

Manual testing is still valuable when the goal is to find unexpected behaviour. Focus first on the journeys that define the product:

• A new user can sign up, verify their account, and reach the first useful outcome
• An existing user can complete the core task without losing data
• A permission boundary prevents the wrong person from seeing or changing something
• A failure path gives the user a clear recovery route
• A billing, payment, or entitlement change behaves correctly

Test the unhappy path as carefully as the happy path. Empty states, slow connections, expired sessions, duplicate submissions, cancelled actions, and partial failures are common sources of customer-visible defects.

5. Check the integration boundaries

Many release failures happen between systems, not inside a single screen.

• API contracts and version compatibility
• Authentication and token expiry
• Retry, timeout, and error handling
• Duplicate or out-of-order events
• Data mapping and validation
• Third-party service failures
• Webhooks and background jobs

Where possible, test with realistic data and observe what happens when a dependency is unavailable. A successful response is not enough if the failure path leaves data in an inconsistent state.

6. Run the regression baseline

Regression testing protects behaviour that is supposed to stay the same. It is especially important when the release changes shared components, permissions, data models, or infrastructure.

At minimum:

• Re-run the highest-risk automated checks
• Manually verify the journeys most affected by the change
• Confirm previously fixed defects have not returned
• Check browser, device, and viewport coverage that matters to your users
• Record known failures and their impact

If the regression suite is slow or unreliable, that is a quality problem to fix, not a reason to skip verification.

7. Check performance and accessibility

Performance and accessibility are product quality, not optional polish.

Performance checks

• Does the critical path meet the agreed response-time budget?
• What happens under expected peak load?
• Are slow dependencies handled gracefully?
• Do background jobs compete with user-facing traffic?

Accessibility checks

• Can the main journeys be completed with a keyboard?
• Are form labels, errors, and status messages announced correctly?
• Is colour contrast sufficient?
• Does the interface work at zoom levels and on small screens?
• Are interactive elements reachable and understandable?

Record the results as evidence, not just a pass or fail.

8. Produce release evidence

A release decision should be supported by a short, readable record:

• Scope and version being released
• Test coverage and what was not tested
• Defects found, fixed, deferred, and accepted
• Known issues and workarounds
• Performance and accessibility results
• Rollback or feature-flag plan
• Final recommendation and decision owner

This record protects the team from vague go/no-go conversations. It also gives support and operations the context they need after launch.

9. Plan the first hours after release

Release readiness continues after deployment.

• Who is monitoring errors and key business metrics?
• What is the rollback trigger?
• Who can disable a feature flag?
• Where should incidents be reported?
• What is the support script for the most likely user issue?
• When will the team review the release and update the test baseline?

A release that cannot be observed or reversed is harder to operate safely.

A compact release-readiness checklist

• Release scope and risk are written down
• Acceptance criteria are testable
• Critical journeys have been tested
• Permission and data boundaries have been checked
• API and integration failure paths have been exercised
• Regression checks have run
• Known issues are documented with impact
• Performance and accessibility checks are complete for the agreed scope
• Rollback or feature-flag plan exists
• A named owner has accepted the release decision

Common failure patterns

• Treating “all tests passed” as a release decision without checking coverage
• Testing only the happy path
• Using production-like data without a privacy plan
• Automating unstable tests and then ignoring the failures
• Leaving known issues in chat instead of the release record
• Asking the development team to independently certify its own work
• Releasing without a rollback or monitoring plan

FAQ

What is release readiness?

Release readiness is the evidence and decision process that determines whether a release can go live. It brings together scope, test coverage, known issues, risk acceptance, rollback planning, and post-release monitoring.

How much testing is enough?

Enough testing depends on the cost of failure and the change being released. A risk-based strategy focuses effort on critical journeys, high-impact integrations, and areas that changed. The release record should state what was tested and what was not.

Can QA be independent from the development team?

Yes. Independent QA is useful when the builder should not be the only verifier of its own work. It can review requirements, design tests, execute verification, and provide a release recommendation without taking over development.

Does test automation replace manual testing?

No. Automation is good for repeatable, stable checks. Manual and exploratory testing are still valuable for discovering unexpected behaviour, usability problems, and gaps that a scripted test will not notice.

How do we start if we have no QA process?

Start with one release, identify the critical journeys and highest-risk changes, and create a small test strategy and evidence record. Expand the process only after the team has used it on a real release.