Bug Fix Verification Template: Retest and Report Results

Start with the original report and its expected result. Write an observable acceptance condition before testing: 'The downloaded file contains the header and the three rows visible in the filtered report.' An expectation such as 'export works' leaves room to pass a test that never checks the reported failure. If the expected behavior is disputed, have the issue owner resolve that question before recording a pass.

Identify the candidate build, environment, role, sample data, and setup. Compare them with the original report. A newer browser or different account permission may be a necessary difference, but record it explicitly. If the reported condition cannot be recreated, mark that check blocked and assign the missing setup; a successful alternative path does not fill the gap.

Where practical, confirm the failure on a known affected build using safe sample data, then repeat the same task on the candidate build. Preserve earlier reproduction evidence when the old build is unavailable. Without a comparable before test, report that limitation rather than manufacturing a baseline. Do not repeat destructive customer actions to prove a defect.

Use one row or numbered entry per check. Retesting asks whether the original failure has been corrected under the checked conditions. Related regression checks ask whether the change disrupted behavior that should still work. Choose those checks from the changed workflow and likely failure boundaries, rather than adding a long list of unrelated pages.

For a filtered export fix, useful neighboring checks might include an unfiltered export, a date range with no matching records, and a role that should not have export access. Write the expected result for each before running it. The correct empty-range result depends on the product's agreed behavior; do not assume it must match the original three-row sample.

A check passes when its observed result matches its acceptance condition. It fails when they differ. Mark it blocked when setup, access, or evidence prevents a conclusion. Record the number of attempts for an intermittent issue; two successful attempts provide evidence for those attempts, not proof that recurrence is impossible. Required failures and blocked checks need an owner and explicit next action.

This fictional example uses an imaginary reporting app. Build 2.4.0 displays three sample rows for a date range but exports only a header. The issue owner agrees that the file should contain the header and those three rows. The verifier reproduces that failure in a test workspace and repeats the same sequence on candidate build 2.4.1.

The candidate exports all three rows on both attempts. The unfiltered export also matches the sample data, and an empty date range returns the agreed header-only file. These checks support a pass for the recorded sample conditions. A second supported browser remains unavailable to the verifier. Because the owner marked it required, the overall verification is incomplete until another person runs that check.

After the second browser passes, the team releases 2.4.1 to a pilot group. The technical verification can now be complete within its stated scope while general availability remains pending. A reporter outside the pilot still uses 2.4.0. Keep that release boundary visible in the issue and customer message; a test result does not establish that every customer has the fix.

Before sending a resolution message, confirm that the recipient can access the changed behavior. State what was tested, which version or rollout audience has it, and any action they need to take. If availability is pending, explain the progress and next update checkpoint. Do not label the customer's task resolved merely because code was merged or a test environment passed.

If a required check fails, keep the investigation open and name the next action. If a reporter still sees the failure after release, compare their build and conditions with the verification record. Reopen the original issue when the same acceptance condition fails; link a separate report when the new observation describes a different failure. Preserve both observations so the team can see what changed.

In Feedbackly, an owner can change a public request's status and add public-safe context in discussion. The supported statuses are Under review, Planned, In progress, and Completed. Keep QA decisions and private test evidence in your internal system. A status change can trigger updates for request followers through the configured delivery workflow; copying this message or adding a comment does not itself send that status email. Check the intended communication path before relying on it.