Lesson 1 of 5
Why test reports
9 min
Transactions get most of the testing attention on an SAP project. Reports get a glance at the end: it runs, it shows numbers, it looks plausible. Yet reports are where the business makes decisions. A sales manager cuts a price because a margin report says a product is unprofitable. A controller releases a bonus pool because an operating profit figure crossed a threshold. A buyer doubles an order because a stock report shows too little. If the number is wrong, the decision is wrong, and nobody notices because the report looked fine.
This course treats a report as a product with a specification and an expected result, tested like any other. It applies to classic SAP GUI reports, to SAP Fiori analytical apps, to KPI tiles on the launchpad, and to dashboards fed from SAP S/4HANA.
Where SAP S/4HANA reporting comes from
Most reporting in SAP S/4HANA is embedded analytics: it reads the operational data directly, in real time, through a layer of CDS views (Core Data Services) built on the database tables. SAP delivers many views and analytical queries; key users can build their own with apps such as Custom Analytical Queries, browse what exists with Query Browser and View Browser, and define KPIs and their tiles with Manage KPIs and Reports. Some companies also report through SAP Analytics Cloud or a data warehouse, which read from the same sources but may add their own timing and logic.
How reports go wrong
| Failure type | Contoso example | Cost |
|---|---|---|
| Wrong selection | Margin report for plant 1710 silently includes plant 1720 because a default filter was lost | Detroit looks more profitable than it is |
| Wrong definition | On-time delivery KPI measures against the requested date in one region and the confirmed date in another | Regions compared on different bases |
| Wrong period or date | Revenue by posting date in the report, by billing date in the board pack | Month-end figures never agree |
| Wrong currency or unit | Totals mix USD and CAD without conversion | Overstated sales |
| Missing data | Reversed billing documents excluded, but their reversals included | Revenue understated |
| Over-exposed data | A sales rep sees margins for all customers | Confidentiality and compliance breach |
Typical reporting failures. Every one of them produces a report that runs without errors.
Many of these failures are introduced by change rather than by the original build. A transport adjusts a CDS view for one report and alters another that uses the same view. An upgrade replaces a delivered query with a successor. A role redesign removes a restriction. That is why report tests belong in the regression pack, not only in the first UAT cycle.
Test data for reports
Report tests need two kinds of data. Controlled data, posted by the tester in the test client, gives a small population where every expected value is known. Realistic data, usually a copy of production or the result of a full mock migration, shows whether the report behaves with real volumes, real oddities and real history. Use controlled data to prove the logic and realistic data to prove the report is usable and reconciles at scale. A report that only ever saw ten test documents has not been tested for month-end.
| Controlled data | Realistic data | |
|---|---|---|
| Source | Postings made by the tester in the test client | Copy of production or a full mock migration |
| Proves | The logic: formula, filters, exclusions, thresholds | Scale, oddities, history and reconciliation at volume |
| Expected result | Known exactly in advance | Derived from documents or the ledger for a narrow selection |
| Contoso example | Three billing documents for Great Lakes Fleet Services | Full period 6 for company code 1710 |
Designing a report test case
A good report test case has four parts. The purpose: which decision the report supports and who uses it. The selection: the exact parameters, such as company code 1710, fiscal period 6 of 2026, plant 1710, ledger 0L. The expected result: totals and a few line values, worked out from source documents or an independent report. The checks: reconciliation, filters, authorization, layout and drill-down. Priya helps key users write these in the same test management tool as other tests, SAP Cloud ALM at Contoso, so report tests have run status and evidence like any other.
- Prepare known data. Post a small, controlled set of transactions in the test client, for example three billing documents for Great Lakes Fleet Services with known amounts, so you know exactly what the report must show.
- Fix the selection. Save it as a variant so the test is repeatable in every cycle.
- Compute the expected result from the source documents before running the report.
- Run and compare totals, sample lines, and drill-down to documents.
- Vary the conditions: another period, another plant, another user, an empty selection.
What would you do?
Contoso's sales margin report was "tested" in the last cycle by running it and confirming it showed data. Dan asks whether that test can be marked passed for sign-off. What is the best answer?
- Reports drive decisions, and wrong reports fail silently.
- SAP S/4HANA embedded analytics reads live data through CDS views and analytical queries.
- Failures come from selection, definition, period, currency, missing data and over-exposure.
- A report test case has a purpose, a fixed selection, an independent expected result and checks.
- Use controlled test data so the expected result is known.
Check your understanding · not graded
Lesson check
1. What layer of SAP S/4HANA embedded analytics restricts which rows a user can see?
2. Why do report tests need an expected result worked out before running?
3. Which app lets key users create their own analytical queries?
4. What makes a report test repeatable across cycles?