Release testing checks whether a specific change is ready to ship under defined conditions. It covers the product, configuration, data, dependencies, and deployment method together. Passing functional tests matters, but does not establish that migration will work, an older client will remain compatible, or the team can detect degradation after launch.
QA's outcome is a clear account of assessed risks to support a release decision. "Everything was tested" hides the boundaries. Stating the build, changed areas, completed scenarios, known defects, and conditions under which the conclusion remains valid is much more useful.
What is being tested?
Identify the release candidate: commit or build identifier, dependencies, migrations, configuration, and feature flags. Tested code may behave differently with another flag value. Rebuilding from the same sources also needs a clear link to the original artifact.
Collect the changes, including infrastructure and external contracts. A small cookie configuration change can affect sign-in more than a visible screen update. Diff size does not determine risk by itself; user journeys, data impact, and recoverability matter.
Entry and exit criteria
Before starting, agree on what makes a candidate testable: an accessible environment, known build, ready data, and functioning key dependencies. If these conditions fail, results become ambiguous. Avoid concealing an environment-related delay by manually changing data without recording it.
Exit criteria describe mandatory scenarios, acceptable defects, and verified deployment readiness. There is no universal "no more than three bugs" rule: one data-loss defect matters more than dozens of minor visual issues. Responsible owners accept risks and exceptions based on evidence.
Choosing the checks
First analyze the changed area and its dependencies. Then verify fixes, new functionality, related regression risks, and main product flows. A critical smoke test is needed for the whole candidate: a localized change does not rule out packaging or configuration errors.
Consider incident history and coverage gaps. If the release changes discount calculation, totals, rounding, refunds, and documents matter. Browsing unrelated screens can consume the entire window while leaving the financial flow that motivated the release untested.
Migrations and compatibility
Test updates against data with realistic structure and volume. An empty database does not reveal conflicts in existing values, prolonged locks, or constraint violations. Clarify whether the app can run while the schema is in an intermediate state.
During gradual rollout, old and new instances may access data simultaneously. Check API and schema compatibility and returning to the previous version. Rolling back the app does not automatically reverse data changes; an irreversible migration needs a separate recovery or roll-forward plan.
Practical example: a new discount
A release changes promo code rules and adds an order field. Prepare an existing order without the new field, a new test order, and several promo codes with known restrictions. Establish expected amounts independently of the app.
- 1.Update the test environment through the standard procedure. Expect successful migration and access to older orders with their original totals.
- 2.Create orders with eligible and ineligible promo codes. Expect the correct amount, a clear rejection reason, and matching values in the API, UI, and document.
- 3.Test an older supported client against the new server. Expect consistent handling of the new field and preserved core actions.
- 4.Execute the agreed rollback or flag-disable scenario. Created orders should remain intact, with predefined behavior for new data.
After fixing a discovered error, repeat the affected flow on the new candidate. A previous pass does not automatically apply to a changed artifact.
Testing the release procedure
Deployment must be reproducible, with known steps, readiness checks, an owner, and stopping conditions. In the test environment, follow the same artifact delivery route rather than manually copying files through another method.
Check environment values, dependency availability, and migration state. A technically ready container does not establish business-operation readiness. Add a short read check and a safe action in an appropriate test context to detect configuration errors before broad impact.
Post-launch observation
Define signals before release: error rates, latency, key operation success, queues, and critical business invariants. Establish a baseline and response rules. Monitoring that nobody opens or can relate to the candidate does not reduce uncertainty.
During a canary release, comparison with a control group helps detect degradation, but a small sample may miss rare scenarios. Account for traffic composition and observation duration. Gradual rollout limits impact but does not replace advance data, security, and migration testing.
The readiness decision
QA supplies facts: what passed, failed, or was not tested, and why. State the concrete consequences of known defects and any workaround that has actually been verified. "The user can retry" is not a valid workaround until duplicate operations have been ruled out.
If the change is narrowed or a feature disabled by a flag, revise the scope of the conclusion. The decision applies to the actual release configuration. A verbal promise to disable a risky path does not replace checking that it is truly unavailable in the selected candidate.
Mistakes and completion
Common mistakes include testing a moving build, treating regression as the only task, forgetting mixed versions, and equating a green health check with readiness. After a late change, repeat a meaningful set based on its risk rather than automatically declaring the entire earlier run current.
The final release report should be short and verifiable: artifact, conditions, results, open risks, and required actions. The release decision then rests on observations, and the team understands which signals to monitor and how to respond to degradation.