Turn important rules into approved examples with inputs and expected outcomes, then compare both systems against those examples. Matching screens does not prove that discounts, permissions, rounding or cancellation behavior are correct. Equally, not every historical behavior deserves to be copied into the replacement.
Collect examples from process owners
Cover a full business cycle: creation, editing, approval, cancellation and reporting. Include ordinary cases, boundary values and known errors using synthetic or appropriately sanitized data. Record the source of each rule and who can approve its interpretation.
If two departments disagree, keep the conflict visible until the responsible owner resolves it. A developer should not settle a financial policy implicitly through an implementation choice. Characterization tests describe what the old system does; acceptance tests describe what the business has decided the replacement should do. Distinguishing the two prevents an old bug from becoming a new contractual requirement.
Keep a reproducible parity register
| Rule | Test sample | Approved result |
|---|---|---|
| Financial approval threshold | Values below, at and above the threshold | Correct approval role for each case |
| Amount rounding | Fractions and permitted negative values | A written rounding rule |
| Due date | Month-end and the agreed time zone | Date matches business policy |
| Cancellation | Before approval and after fulfilment | Explicit record and balance effects |
| Branch permissions | Users belonging to different branches | Isolation or sharing matches the policy |
Compare individual records, distributions and exceptions as well as totals. Two mistakes can cancel each other in an aggregate. Retain the test-data version, rule version and reproducible difference so another reviewer can investigate the result.
Prevent comparison runs from changing production
Use an isolated test environment. If a separately authorized shadow run is necessary, prevent its comparison path from sending messages, charging payments or writing to the production source. A read-only screen is not enough if a background job can still create an external effect.
Classify every difference: a replacement defect, a known old defect approved for correction, a data discrepancy or an unresolved rule. Do not accept a result simply because it looks closer to someone’s expectation. Link it to evidence and a responsible decision, then rerun the relevant suite after the change.
Time-dependent tests need controlled clocks and explicit time zones. Tests that depend on random ordering or changing external responses can hide regressions. Keep those conditions reproducible or document the remaining uncertainty rather than discarding inconvenient failures.
Include operational acceptance
Verify representative processing volumes, exports, permission revocation, recovery and rollback. Define who approves cutover and which unresolved differences prevent it. A small sample with no known failures is not proof of complete equivalence; record coverage limits and the monitoring required after launch.
Keep intentional changes separate from preserved behavior. Users need to know if a previously tolerated action is now rejected, and support staff need a way to distinguish the intended correction from a regression.
Collect these examples before legacy modernization. Connect them to migration planning and backup and continuity decisions so acceptance covers operation as well as code.
Sources and editorial status
- Martin Fowler: eradicating non-determinism in tests.
- Microsoft: Anti-corruption Layer pattern.
- Original contribution: the parity register and difference-classification workflow; no client system has been certified by this example.
