Lesson 6 of 6
MDG regression pack and data owner sign-off
10 min
Listen to this lesson
An MDG implementation is never finished. Rules change, approvers change, new receivers arrive, SAP S/4HANA is upgraded, and decision table content is edited. Each change can break a path that worked. A regression pack is the set of tests that proves, quickly and repeatably, that governance still works. It turns the one-off project tests from lessons 2 to 5 into an asset that Contoso's TCoE can run in every release window.
What goes into the pack
| Area | Cases (Contoso) | Run when |
|---|---|---|
| Workflow routing | All transitions of supplier and customer request types; self-approval; no agent; substitution | Any routing table, role or org change; every release |
| Validation and derivation rules | Equivalence classes per rule; derivations with user values | Any rule change, including directly maintained content |
| Duplicate check | Labeled pair set (60 pairs); four-cell counts | Threshold or search configuration change; upgrades |
| Consolidation and mass | One source file with expected groups and survivors; one mass change | Process template change; upgrades |
| Replication | Receiver matrix per receiver | Receiver, filter, mapping or integration flow change |
| Authorizations | Each role sees and processes only its steps; rule maintenance limited to owners (for example MDQRM_RULE) | Role changes; every release |
Contoso's MDG regression pack (about 140 cases; illustrative).
Triggers, not just a calendar
Running the full pack every release is the baseline. On top of that, specific changes trigger specific parts. The most often forgotten trigger is content: a decision table row edited directly by an authorized user, or a data quality rule moved to Approved. Agree with Hannah that every such change is logged and that the related cases are run within a day, in CMR if the change can be reproduced there, or as a careful check in production if it cannot.
- Did routing tables, roles or org assignments change?Yes → workflow and authorization cases · No → next question
- Did a rule or directly maintained table content change?Yes → that rule's classes and dependent workflow conditions · No → next question
- Did duplicate check or consolidation settings change?Yes → pair set and consolidation file · No → next question
- Did a receiver, filter, mapping or integration flow change?Yes → that receiver's matrix · No → next question
- Is it an SAP S/4HANA upgrade or MDG support package?Yes → full pack · No → targeted cases only
Test data and automation
MDG tests consume data: every activated record is permanent, and duplicates of earlier test records distort duplicate tests. Wei's test data recipe for MDG creates unique names and tax numbers per run, keeps the labeled pair set as a loadable file, and lists which records may be reused. The steady, high-volume cases (rule classes, routing transitions, receiver matrix) are good automation candidates; duplicate threshold reviews and survivor checks stay partly manual because they need judgment. Contoso automates the change request flows through the UI and the receiver checks through APIs, using the program's standard automation approach.
Add a small set of volume checks to the pack. MDG performance problems usually show as slow duplicate checks, long-running derivations on large requests, and mass activations that lock records during the business day. Contoso keeps three timing checks: a duplicate check on a new customer, a multiple-record request with 40 ship-tos, and a mass change of 300 customers. Each has a recorded baseline time from the last release, and a run that is much slower than the baseline is investigated before sign-off, even if every functional case passed.
The sign-off record
Who signs matters. The data owner signs that the routing, rules and thresholds are the intended business behavior. The test lead signs that coverage and evidence are complete. The receiving system owner signs that the receiver holds correct data. Keep these signatures separate: a test lead cannot accept a business rule, and a data owner should not have to judge test coverage.
What goes wrong in testing
- Pack frozen at go-live. New request types and receivers are added without cases; coverage silently shrinks. Review the pack against the configuration list every quarter.
- Content changes outside the pack. Directly maintained tables change routing without any test. Log content changes and trigger cases.
- Evidence without versions. Results cannot be tied to the rule or table version tested. Record versions with every run.
- Sign-off by one person for everything. Business and test responsibilities blur; keep separate signatures.
What would you do?
Two weeks after a release, Hannah's team edits a derivation decision table directly in production to change the default payment terms for new Monterrey customers. Nobody ran any test. What should the TCoE put in place?
- A regression pack covers workflow, rules, duplicates, consolidation, replication and access.
- Run it every release and trigger parts on specific changes, including direct content edits.
- Manage MDG test data deliberately; automate stable cases, keep judgment cases manual.
- Separate signatures: data owner for behavior, test lead for coverage, receiver owner for data.
Check your understanding · not graded
Lesson check
1. Which change is the most often forgotten trigger for MDG regression?
2. Which MDG tests usually stay partly manual even with automation?
3. Who should sign that routing and rules are the intended business behavior?
4. Why record configuration versions with every regression run?