Javítás és közeli regresszió ellenőrzése

Fix Verification & Targeted Regression

A fix that only passes the exact literal input from the bug report often breaks a neighboring case or masks the symptom while leaving state corrupted. Verify both the fix and its immediate blast radius.

Workflow

1. Replay the exact original failure scenario first:
   • Execute the documented reproduction steps on the fixed version and confirm the defect no longer occurs and the regression test fails before the fix and passes after.
2. Probe variations around the fix (Neighborhood Testing):
   • Test slight variations of the original trigger to verify the root cause was addressed rather than hardcoded around:
     • Different input shapes or boundary values on the same field.
     • Alternative entry points (e.g., if a bug was fixed in the modal form, check inline edit, keyboard shortcut, bulk action, and API endpoint).
     • Both success and failure paths of the modified code block.
3. Run targeted regression on coupled workflows:
   • Identify components that share state, database tables, events, or UI components with the changed files.
   • Verify that fixing the bug did not:
     • Break existing permissions or workspace isolation.
     • Introduce stale cache reads or broken loading/error states.
     • Regress previously passing acceptance criteria on the work item.
4. Keep re-testing proportional:
   • Do not re-run unrelated, already-verified test charters when a small, isolated change was made; focus verification strictly on the changed behavior and its direct dependencies.
   • Document the re-test verdict clearly: which commit/version was re-checked, which variations passed, and whether the issue is ready to close.