Regression Testing Checklist After a Change

Regression testing checks whether behavior that worked before still works after a code, configuration or data change. Start with the changed interaction, then choose nearby paths sharing its data, controls or navigation and any known prior fixes. Record the build, expected and actual result, evidence and untested paths. A targeted checklist helps make the decision reviewable; it cannot establish that every other path is free of regressions.

Microsoft’s testing-strategy guidance describes regression checks after changes, manual or automated, and notes that targeting affected areas leaves other areas unconfirmed. Its examples concern Dynamics implementations; use the principle to choose cases for your own system, not its process as a universal rule.

Suppose a form fix is intended to keep a drafted message when the email field is missing. The original-bug retest checks that repair. The other rows check behaviors that the same validation, form state or navigation change might disturb. All cases begin Not tested.

For the fictional validation fix, run the original missing-email case first because it proves the intended repair. Next run valid submission because it shares the changed form path and can reveal a blocked success case. Then sample browser Back and the prior duplicate-submit fix because both depend on state around submission. Record the interrupted-request case as still Not tested if the safe test environment cannot control the connection; assign an owner and a later window rather than silently dropping it.

This ordering is a choice based on the change and its likely dependencies, not a coverage guarantee. Microsoft’s regression-testing guidance describes the tradeoff between testing affected areas and leaving other areas unconfirmed.

Copy the blank mapping for a real change. Keep unrun cases Not tested; after execution, record Pass, Fail or Blocked with the named build and reviewed evidence. Retesting the original bug alone proves only that particular repair in that environment.

Change: [code/configuration/data change and linked issue]
Build and environment: [release, browser/device, safe test account]
Original bug retest: [steps, expected fix, actual result] — Not tested
Adjacent path 1: [shared form behavior and expected result] — Not tested
Adjacent path 2: [navigation, persistence or retry expectation] — Not tested
Known prior fix: [linked issue and behavior that must remain fixed] — Not tested
Assumed unaffected path to sample: [reason it could still be touched] — Not tested
Each result: [Pass/Fail/Blocked, evidence, tester, time]
Omitted paths and reason: [explicit blind spots, owner for later review]

The separate fictional failure below shows the handoff if an adjacent behavior breaks. It is an illustration, not a measured product outcome:

Fictional regression finding — contact-form build r18
Change: Missing-email validation was adjusted to retain the message.
Case: Return to the form with browser Back after a validation error.
Expected: Previously entered message remains available for correction.
Actual: Message field is blank in this invented attempt.
Status: Fail for this case; other mapped cases remain Not tested.
Evidence: [reviewed screenshot, time, browser/version, exact steps]
Owner/next step: [triage owner investigates, fixes if confirmed, retests on named build]

The smoke checklist checks basic critical functions before deeper QA. The UAT plan and UAT checklist builder support a separate business-acceptance decision. For a failed case, use reproduction steps, the triage worksheet and the sample report to make the next action clear.

Published October 9, 2026. Updated October 10, 2026. All form scenarios are invented teaching examples; no regression run or acceptance decision occurred here.