Custom code and functional regression

A conversion keeps your processes but changes what sits underneath them. Standard SAP functions are simplified, data structures change and custom code has to be adapted. Testing everything equally is neither affordable nor smart. The custom code analysis and the simplification items tell you where change happened; the regression strategy should follow that map.

Where the findings come from

Simplification items relevant to your system, from SAP Readiness Check or the Simplification Item Catalog, describe functional and technical changes in each area.
Custom Code Migration checks custom code against S/4HANA simplifications before the conversion; the guide notes the checks do not yet find every issue, so custom code must also be tested in S/4HANA.
After SUM: modifications are adjusted with SPDD, SPAU and SPAU_ENH, and remaining issues are found with an ATC run using the check variant S4HANA_READINESS in the converted system.
Usage data: unused custom code can be identified and retired, which removes it from both adaptation and testing.

FindingsATC readiness findings, SPAU/SPDD adjustments, relevant simplification items
Map to objectsWhich custom objects and standard functions changed
Map to processesWhich business processes and test cases use them
PrioritizeBy change depth and business criticality
TestUnit tests for adapted code; targeted functional tests; full regression for critical paths

Turning custom code findings into a focused regression scope.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-404

Mapping code to processes

The hard step is the middle one. Developers think in objects, testers in processes. Build a simple traceability list: for each adapted custom object, which transactions, apps, jobs or interfaces call it, and which test cases cover those. Usage statistics from production help a lot here, because they show which programs actually run in which business context. Kenji's team owns the object side; Priya's team owns the test case side; together they fill the gap.

The traceability list links each adapted Z object to whatever calls it and to the test cases that cover those callers, joining the developer and tester views.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-404

Finding at Contoso	Adapted object	Process and test focus
Customer/vendor master moves to business partner	Custom customer-creation interface	Create and change customers via the interface; check Great Lakes Fleet Services master data and credit data
Changed pricing data model	Custom pricing report reading pricing conditions	Report totals reconciled against billing for a month of orders
Material number field length extended	Custom label print program	Labels for CMC-ALT-100 and CMC-RTR-200; layout and barcode
Finance tables replaced by the universal journal	Custom GL extract to the consolidation tool	Extract compared with trial balance for 1710 and 1810
Modification in sales order pricing	Adjusted in SPAU	Full order-to-cash regression with all price scenarios

Examples of findings mapped to targeted tests. Topics are typical conversion areas; confirm the relevant simplification items for your system.

Test layers for adapted code

Adapted code gets three kinds of evidence. Developer tests: ABAP Unit where the code allows it, or at least a documented developer test with before/after output from ED1 and CMD. Comparison tests: run the same report or interface with the same selection in the old system and the converted one and compare results, which is powerful for reports and extracts. Process tests: the business process end to end in CMQ, with key users for critical flows. Unchanged custom code still gets regression through the processes that use it, but with lower priority.

A comparison test runs the same report or interface with the same selection before and after, then hands over to the process test.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-404

Targeted testDeep change, low criticality: developer test plus one functional check

Full regression plus key usersDeep change, critical process: all layers, every iteration

SampleLittle change, low criticality: covered by broad regression

Automated regressionLittle change, critical process: automated end-to-end run each iteration

Prioritizing conversion regression by depth of change and criticality.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-404

What would you do?

After 4,300 unused objects were deleted, Kenji's scoped ATC run on the 7,500 in-scope custom objects shows 3,900 readiness findings, and usage data shows many objects run only rarely. The test budget covers about 300 targeted tests. What should Priya propose?

Hands-on lab · ACCELQ

Rerun one regression suite on a baseline and a converted system

This lesson's comparison test runs the same check with the same selection in the old system and the converted one. In ACCELQ, two App Environments and a Global Property let one Test Suite run against both without editing a single test, so any difference comes from the system, not the test.

Practice on SAPUI5 Shopping Cart demo app (public, no login), standing in for both the ECC baseline and the converted system

If you haven't set up ACCELQ yet, do the setup lab first.
Make sure you have at least three Scenarios on the Shopping Cart, for example browsing a category, searching for a product and adding an item to the cart. Record any that are missing with the Web Recorder, picking any category or product you see.
In Project Administration (click the project name at top right, then the Settings icon), open Application Environments. Use two existing environments, or add two if you are a Project Admin, and treat them as "ECC baseline" and "Converted".
In Resources, create a Global Property named CartURL and give it the Shopping Cart URL for both App Environments. In a real program the two values would be an EP1 copy and the converted CMQ.
In each Scenario, click the URL on the Initiate Browser Session step and point it to CartURL, so no Action holds a URL.
Give the suite something to compare. In the add-to-cart Action, use Get Element Text on the cart total, store it as an Action Output, and print it with Log Parameter Value.
Click "+" > Test Suite, choose Static, and add the Scenarios with the most critical first, as the lesson's matrix would rank them.
Click Run, pick the suite, set App Environment to "ECC baseline" and choose your Local Agent. Then run it again unchanged with "Converted".
Open both Test Reports side by side. Compare pass/fail per Scenario and the logged cart totals. Treat any step Self-Healing recovered as a changed screen to review, and give every difference a result: explained and documented, or a defect.

Done when The same suite ran twice with only the App Environment changed, and every difference is either explained or logged as a defect. Keep both Test Report links as your comparison evidence.

Learn more in ACCELQ’s docs: Setting up Application Environments · Opening browser with dynamic URL in ACCELQ · Challenge 05: Capturing information from the application screen

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Key points

Use simplification items, custom code checks, SPDD/SPAU adjustments and ATC readiness runs as the change map.
Map adapted objects to processes and test cases; usage data links code to business context.
Combine developer tests, old-versus-new comparison tests and process tests.
Retire unused code and prioritize the rest by depth of change and business criticality.

Where the findings come from

Mapping code to processes

Test layers for adapted code

Lesson check