Lesson 1 of 6
Why data-layer testing is different
10 min
Listen to this lesson
Contoso Motor Co.'s data team, led by Noor, has built its first SAP Datasphere layer on top of SAP S/4HANA (CMP): replication flows bring billing, journal entry and product cost data into a finance space, an analytic model calculates margin, and an SAP Analytics Cloud story shows margin by customer to Dan, the finance process owner. Next quarter, a finance agent will read the same model. Priya, the test lead, has tested ERP processes for years. Her first question about the data layer is: what exactly are we testing, and how do we know when it is right?
Data-layer testing borrows from migration reconciliation (course sap-dmg-302) but differs in one decisive way: the data never stops moving. A migration is loaded once and signed off; a replication flow loads, then keeps applying changes every few minutes or hours, for years. A test that passed on Monday says little about Thursday unless you know what changed in between. And the outputs are numbers, not screens: nobody will notice a wrong figure the way they notice a broken button.
What is different
| Aspect | ERP process testing | Data-layer testing |
|---|---|---|
| Unit of test | A transaction or process step | A dataset: rows, keys, measures, attributes |
| Expected result | A document is posted, a status changes | Counts and totals match the source at a known time |
| Time | Mostly a snapshot | Continuous: initial load, then deltas |
| Failure looks like | An error message | A plausible but wrong number, often silent |
| Who changes things | Your transports | Your transports, SAP's updates to managed content, source configuration |
| Evidence | Screenshots, documents | Reconciliation queries, logs, run IDs, timestamps |
The layers to test
Each arrow is a hand-off where data can be lost, duplicated, filtered or transformed wrongly. A strategy names the checks at each hand-off, the data window they cover, and who owns the fix. Testing only the SAC story is like testing an invoice by looking at the total on the print-out.
A test strategy on one page
| Element | Contoso decision |
|---|---|
| Scope | Finance space: billing items, journal entry items (ledger 0L), product costs; margin analytic model; SAC margin story |
| Systems | CMQ client 100 as the source for build and delta test cycles; release regression in CMR, the masked copy of CMP refreshed quarterly; daily production checks against CMP; Contoso's test and production Datasphere tenants |
| Test types | Load reconciliation, delta tests, transformation rule tests, model tests, access tests, regression |
| Data window | Fixed closed period (September 2026) for regression; open period for delta tests |
| Tolerance | Zero for counts and amounts in document currency; rounding within 0.01 per line for translated currencies |
| Evidence | Query outputs with run IDs and timestamps, stored with the test cycle in SAP Cloud ALM |
| Owners | Noor (data build), Priya (test), Wei (test data), Dan (finance acceptance) |
Contoso's data-layer test strategy summary. Decide tolerance before testing, not after a difference appears.
Test types and who runs them
Priya splits the work into six test types. Load reconciliation proves each replicated or installed dataset is complete after the initial load. Delta tests prove changes arrive: inserts, updates, deletes and cancellations. Transformation rule tests prove each view and calculation with known cases. Model tests prove the analytic model against the ledger and against known documents. Access tests prove that restricted data stays restricted. Regression reruns all of it against a fixed baseline after any change. Noor’s team runs developer-level checks as they build; Priya’s testers run the formal cycles; Wei prepares the source documents in CMQ client 100 so every delta test has known inputs; Dan accepts the finance results.
What would you do?
Grace asks Priya to sign off the margin dashboard after a demo in which Dan said "the numbers look about right". What should Priya do?
- MapDraw the hand-offs from source to consumer
- Fix the windowClosed period plus an open period for deltas
- Define checksCounts, totals, key diffs, rules, access at each hand-off
- Set tolerancesAgreed with the business before testing
- AutomateReconciliation queries rerun every cycle and after every change
One more difference matters for planning: data-layer defects are cheap to find early and expensive late. A wrong join found in the first test cycle costs Noor an hour. The same join found after the CFO has used the dashboard for a quarter means corrected board figures, a credibility problem for the whole data program, and every downstream consumer, including the finance agent, retested. That is why Contoso runs reconciliation from the first deployment in the test tenant, not as a final acceptance step.
- Data-layer testing proves completeness and correctness over time, not a single transaction.
- Reconcile at every hand-off: replication, installation, transformation, model, consumption.
- Fix the time window: closed periods for regression, recorded cut-offs for deltas.
- Agree tolerances and evidence before testing starts.
Check your understanding · not graded
Lesson check
1. Why is a passing data test on Monday weak evidence for Thursday?
2. Which failure is most typical of the data layer?
3. When should reconciliation tolerances be agreed?
4. What is the best data window for regression comparisons?