1. Understand what changed.
- Identify user-facing changes, backend changes, configuration changes and integrations touched.
- Check dependencies: what existing workflows share the same data, permissions or services?
- Clarify the release goal and the consequences of failure.
2. Protect critical journeys.
- Authentication and account access where relevant.
- The product's primary value-producing workflows.
- Payments, permissions, data creation/editing and destructive actions when applicable.
- Known fragile areas affected by the change.
3. Explore around the change.
Do not stop at the acceptance criteria. Try alternate sequences, invalid or incomplete data, boundary values, interrupted flows and state transitions. The goal is to understand what the change can disturb, not only whether its happy path works.
4. Run focused regression.
Use existing regression coverage to protect known high-value behaviour. If the regression suite is too large to run meaningfully, that is a signal to prioritize it rather than simply adding more cases.
5. Check release evidence.
- Can important findings be reproduced?
- Are blockers and accepted risks explicit?
- Is the tested build/environment clear?
- Does the team know what was not tested?
Release decisionQA reduces uncertainty; it does not make risk disappear.
A useful release report makes the remaining risk visible enough for the team to make an informed decision.