The dashboard is green. The demo looks good. The release date is tomorrow. Is the product ready?
Passing tests are useful, but their meaning depends on what was checked, which build was used and what the checks actually assert. A green result cannot answer questions that were never included in the suite.
A practical release review brings that evidence together so the team can make an informed decision.
Check the build, environment and data
Begin with a simple question: does the evidence describe the version you intend to release?
Record the build or commit, the environment, relevant configuration and when the checks ran. A successful result from before the latest change may no longer cover the behavior being shipped.
Test data also matters. An empty account can behave differently from an account with a long history. A sandbox integration may not reproduce every condition of the production service. Document those differences instead of treating the environments as interchangeable.
Follow the critical journey to its real outcome
Choose a small set of journeys that must work for this release. Confirm the result beyond the visible success message where the agreed access allows it.
For an illustrative booking product, a confirmation screen is only part of the evidence. The booking should also be saved correctly, appear in the appropriate account and preserve the agreed details. Any notification included in the scope should be checked too.
For a mobile app, consider returning after backgrounding, a denied permission or an interrupted connection. For a website, consider refreshing, navigating back or submitting twice. Select the cases that matter to the changed feature and supported environments.
Review defects by impact, not just count
Three open defects can be more serious than thirty. The important questions concern what fails and who is affected.
- Can a customer complete the intended task?
- Could the failure affect money, data or access?
- How often is the affected path likely to be used?
- Is there a realistic workaround, and will users understand it?
- Who owns the decision to fix, delay or accept the issue?
Keep severity and release priority explicit. A team may accept a known limitation, but that decision should have an owner and a reason. An unexplained “known issue” label is not enough.
Understand the gaps behind the green result
Look for skipped checks, unsupported devices and integrations that were unavailable. Investigate tests that pass only after repeated retries; an eventual pass does not explain the original failure.
Combine automation with focused human exploration. Test automation is useful for repeatable regression checks, while a person can investigate unclear behavior and ask questions outside the scripted path.
If an important area was not checked, say so directly in the release summary. That is useful information for a decision, not something to hide inside a coverage percentage.
Plan how to notice and recover from a problem
Before release, agree who will watch the relevant operational signals and customer reports. Choose signals that reflect the product, such as failed bookings or unsuccessful sign-ins, and handle any collected data according to the team's privacy requirements.
Also agree what happens if a serious issue appears. Can the change be disabled or rolled back? Do data changes make reversal more complicated? Who has the access and responsibility to act?
Recovery planning does not replace testing. It gives the team a response when production reveals something the pre-release checks did not.
Write a release summary someone can use
Keep the decision record brief: the version reviewed, critical journeys checked, important findings, unresolved gaps and the agreed next action. Name the decision owner rather than describing QA as the only gatekeeper.
The goal is not to promise a bug-free release. It is to make the remaining uncertainty understandable enough for the team to decide what to ship, what to fix and what to watch.
