Testing

SAP's conversion guide is clear that the checks are not the end: in addition to analysis and adaptation, you also need to test the custom code within SAP S/4HANA, because the checks do not yet find every instance where code does not comply. For a test lead like Priya the challenge is depth. Contoso adapted thousands of objects; testing each one in isolation would take longer than the program has. The answer is to test by risk and by process, using what scoping and adaptation already recorded.

Layers of evidence

Choose depth by risk

Usage data helps twice: it showed what to keep, and it now ranks what to test hardest. Map each adapted object to the transactions and jobs that call it, then to the business processes in the regression set. Objects that are adapted and heavily used deserve the most attention; adapted objects that nothing in the regression set calls are a gap to close.

Compare with ECC

For reports, extracts and calculations, the strongest functional test is a comparison: run the program in ECC and in the converted system for the same period and selections, and compare results. The converted quality system is a copy of production, so the data is real. Time the runs too; a program that now reads through a compatibility view or a changed data model can be correct but slow. For a slow program, an SQL trace (ST05) shows where the time goes.

Building a comparison, step by step

1. Choose a closed period and fixed selections, so production ECC (EP1) and the converted copy in CMQ hold the same data for it.
2. Run the program in EP1 (read-only) and in CMQ with the same variant, and export both results in the same layout.
3. Compare totals first (record counts and sums by key), then line by line where the totals differ.
4. Record both runtimes. Contoso’s rule: anything more than twice as slow gets a trace.
5. Explain every difference: a defect, an expected SAP S/4HANA change (documented in the simplification item), or data timing.
6. Attach both files and the verdict to the test case in SAP Cloud ALM as evidence.

Performance tools. ST05 traces one run. Before the conversion, the SQL Monitor (SQLM) in production shows which custom SQL statements run most often and cost most, and the SQL Performance Tuning Worklist (SWLT) combines that runtime data with static findings to rank what to tune. When the time is spent in ABAP rather than the database, the runtime analysis SAT shows where.

Unit tests that survive the conversions. ABAP Unit tests run from ADT in seconds. For rewritten data access, use the ABAP SQL test double framework (and the CDS test double framework for CDS views), so a test supplies its own table data instead of depending on whatever CMQ holds after the next refresh. Joule for developers can draft unit tests; a developer still checks that the assertions test the business rule.

Make it repeatable

Evidence that outlives the program. In SAP Cloud ALM, Priya keeps each comparison as a test case in the test plan for the cycle, with the custom objects it covers named in the test case. Defects raised from a failed comparison link back to that test case, so a re-test after Kenji’s fix lands on the same record. When the auditors or the next upgrade team ask how an adapted program was proven, the answer is the test case with both result files, not a chat message.

After the sandbox, Contoso converts CMD and CMQ, then rehearses the production conversion three times in CMQ refreshed from a copy of EP1 (Mock 1, Mock 2 and the dress rehearsal), and finally converts CMP. The same tests should run after each, so automate where it pays. ABAP Unit tests run in seconds after every transport. Comparison checks can be scripted with saved variants and stored outputs. Business process regression for the most used flows is a good candidate for SAP's own test tooling and SAP Cloud ALM test management, where results and defects are linked to the requirements and features they cover.