Lesson 1 of 6
Where MDG projects fail testing
10 min
Listen to this lesson
An MDG implementation looks easy to test. Create a request, approve it, see the record. That is exactly why MDG projects fail: the visible path works in every demo, and the defects hide in the paths nobody walks. A rejection that loops forever, a rule that blocks every Monterrey customer, a duplicate check that never fires because the search index was not built, a receiver that gets a second copy of a customer after the first change. This course shows how to design tests that find those defects, using Contoso's MDG Release 1 for business partners as the running example.
The context comes from sap-xpr-206: Contoso runs MDG co-deployed in its SAP S/4HANA system, in classic mode with rule-based workflow. Hannah is the master data lead, Maria, Omar and Lucía are the main requesters, Dan approves supplier bank data, and Elena's warranty claims app on SAP BTP receives customers through SAP Integration Suite. Priya is the test lead; Wei owns test data. The integration test thinking from sap-tst-203 applies throughout.
Where the defects hide
| Failure pattern | How it shows in production | Test design that catches it |
|---|---|---|
| Happy-path-only workflow tests | A rejected request returns to nobody; approvals stall for days | Transition coverage of every step and action (lesson 2) |
| Rules tested with one example | Rule blocks legitimate Mexican tax formats | Equivalence classes and boundaries per rule (lesson 3) |
| Duplicate check tested with identical copies | Typos and abbreviations create duplicates daily | Labeled pair sets with near-duplicates (lesson 4) |
| Replication checked by "message sent" | Receiver shows duplicates after the first change | Create, change twice, block, with key mapping checks (lesson 5) |
| Super-user test accounts | Real approvers never receive tasks | One test user per production role |
| No regression after rule content changes | A decision table edited in production breaks routing | A regression pack triggered by rule changes (lesson 6) |
Six failure patterns seen in MDG projects and the test design that prevents each.
Who tests what
| Role at Contoso | Tests | Signs |
|---|---|---|
| Configuration team (MDG consultants) | Unit tests of decision tables, rules and duplicate settings, mostly by simulation | Unit test evidence per configuration item |
| Testers (Priya's team) | Process and integration tests with role users in CMQ | Coverage and evidence |
| Wei (test data and environments) | Test data recipe: unique names and tax numbers per run, the labeled pair set, CMQ and CMR readiness | Test data readiness before each cycle |
| Data owners (Hannah, Dan, Lucía) | Acceptance scenarios with realistic data; review of routing tables and rules | Intended business behavior |
| Receiver owners (Elena) | Checks inside the receiving system | Correct data in the receiver |
Test responsibilities in Contoso's MDG Release 1.
Test levels for MDG
The test basis for MDG is unusually concrete. Change request types, the rule-based workflow decision tables, the validation and derivation rules, the duplicate check configuration and the replication models are all configuration that can be listed. Each row of each table is a requirement that can be tested. Start the test design by exporting those tables, not by interviewing users about what they "usually do."
Set entry and exit criteria per level. Process tests start only when every decision table and rule in scope has passed its unit tests and Wei has confirmed fresh test data in CMQ. Process tests exit when transition coverage per change request type is complete and no high-severity defect is open. Integration tests exit when every receiver matrix has passed, including the two-change key mapping case. Acceptance exits with the data owners' signatures. These criteria give Grace's PMO a factual answer to "are we ready?" instead of a feeling.
What goes wrong in testing
- Test data that cannot be reused. Every test activates records, so the second run finds duplicates of the first. Wei's test data recipe generates unique names and tax numbers per run.
- Shared test users. Two testers using the same approver account process each other's tasks, and evidence becomes ambiguous.
- Checking the request, not the record. "Request completed" is not the result; the active business partner is.
What would you do?
Priya reviews the MDG test plan written by the implementation partner. It has 25 cases, one per change request type, each with "create, approve, check status completed." What should she ask for first?
- MDG defects hide in rejection paths, rules, duplicate checks, activation and replication.
- Plan five test levels: configuration unit, process, integration, data owner acceptance, regression.
- Build the test basis from configuration tables; each row is a testable requirement.
- Verify the active record and the receiver, not just the request status.
Check your understanding · not graded
Lesson check
1. Why is a "create, approve, completed" test weak for MDG?
2. What is the best test basis for an MDG implementation?
3. At which level is BRFplus simulation most useful?
4. What is the actual result of an MDG process test?