Verification and Evidence

A Developer marking a defect Fixed signals that the correction is ready for assessment. QA Engineer independently repeats the reported behavior and checks the expected result. The defect becomes Verified only when that assessment succeeds. Closure follows after the team retains the evidence needed to explain the decision and confirms that the accepted correction matches the original problem.

The report, corrective task and supporting files provide the context for the check. A screenshot can show what the tester observed; notes can explain the environment and the result. Review decisions can record acceptance of the corrective task using its actual reference and project. Keep the defect’s verification state clear alongside that task decision so the team can trace what was accepted.

• Independent retest. Assign a QA Engineer who can assess the correction separately from its implementation. Repeat the reported conditions and compare the result with the expected behavior. A failed retest remains unverified and needs an explanation the Developer can use for further work.
• Evidence location. Give each supporting file a useful name and kind, such as Screenshot or Evidence. Record its parent identifier and uploader so the team can find the actual work it supports. Agree the defect evidence mapping before the pilot and test it by reopening the file from the intended record.
• Decision context. Record a task acceptance decision with the actual task reference, reviewer and project. Approved, Rejected and Returned distinguish the assessment outcome. Explain the reason in the decision notes, especially when the Developer needs to revise the correction or clarify the handoff.

Agree who can verify a fix and how the team preserves independence when the same person has several responsibilities. Define the test evidence needed for the severity levels you use. A visual defect may need a screenshot and reproduction notes; a calculation problem may need the inputs and expected result described clearly enough to repeat.

Decide where the evidence is stored and how its parent record is identified. Confirm the audience allowed to open file links in the connected storage system. Keep the reviewer and decision date attached to the actual acceptance record. Make clear who confirms that verification is complete before the defect is Closed and the corrective task is marked Done.

The Developer presents the checkout discount correction as Fixed. QA Engineer reads the original report and repeats the same input conditions. The corrected display matches the agreed result, and the tester retains a screenshot with notes explaining the check. The defect moves to Verified; task acceptance records the reviewer and project before the remaining closure steps are completed.

Now rehearse a failed retest. The display is correct for the initial example but still wrong for another condition described in the report. QA records the failed result and keeps the defect unverified. The Developer receives the explanation and continues the correction. Finally, attempt to use an unrelated task’s approval as verification evidence. The Project Manager should identify the mismatch through the issue key and actual record references.

• Fixed Defects Awaiting Verification — Corrections ready for an independent check against the reported behavior.
• Approved Review Decisions — Accepted delivery subjects with the reviewer and project available for inspection.

Rehearse fix and verification, then review the retained decision during project delivery review.