# Late change QA handoff

Studio Figgy · Brandon Figueroa

Public technical writing sample, reconstructed for this portfolio. No internal identifiers, systems, or release instructions are reproduced.

## Purpose

Give QA an unambiguous test request when a change arrives after a release candidate has already been validated.

## Before replacing a release candidate

1. Pin the candidate. Record the exact build identifier and confirm it matches the artifact QA will install.
2. Describe the delta. List the changes since the tested candidate, including related configuration and dependency changes.
3. Agree the validation scope. Identify affected user journeys, regression coverage, and evidence needed to close the request.
4. Confirm ownership. Assign an engineering contact for questions, a QA owner for results, and a release owner for the decision record.
5. Reconfirm the decision. Keep the release on hold until new evidence and required approvals are recorded.

Do not carry a previous test result forward as proof for a changed build. Record what remains valid and what must be tested again.

## Example handoff excerpt

The replacement candidate contains a change to session recovery. Validate reconnecting after an interrupted session and confirm normal session startup still works. Record the candidate identifier, environment, result, and any failure evidence in the test report. The release remains on hold until that report is reviewed and the required approvers record a decision.

This example is fictional and is not a report of a defect in any named product.

## Completion criteria

The candidate is identifiable. The change and affected behavior are documented. QA knows what evidence to return. Open issues have owners. A recorded decision exists before the candidate is promoted.