SAP S/4HANA regression testing: a practical checklist for upgrades and migrations
Every S/4HANA upgrade, support pack or migration carries the same risk: something that worked yesterday quietly breaks today, and you find out when an order doesn't ship or an invoice doesn't post. This checklist walks through what to test, how to prepare and what to automate, so your next SAP release goes live with confidence.
Key takeaways
- Scope regression testing by end-to-end business process, not by transaction code.
- Interfaces, custom code, Fiori roles and test data cause more surprises than standard functionality.
- Automate stable, high-value scenarios you run every release; keep volatile ones manual.
- Agree exit criteria and sign-off owners before testing starts, not during cutover week.
1. Know what kind of change you're testing
The type of change determines how deep testing needs to go:
| Change | Typical risk | Testing focus |
|---|---|---|
| Support pack / feature pack | Changed standard behaviour, notes, UI changes | Regression of core processes, Fiori apps, interfaces |
| S/4HANA release upgrade | Simplification items, deprecated functions, custom code impact | Regression plus targeted tests of changed areas |
| ECC to S/4HANA conversion | New data models (e.g. Business Partner), changed processes, data migration | Functional validation, data reconciliation, full regression, performance |
| Regular transports | Unintended side effects of configuration or code changes | Risk-based regression of affected processes |
For conversions in particular, review SAP's simplification items for your target release and the results of custom code checks early. They tell you which areas will behave differently and therefore need more than a simple regression run.
2. Scope regression by end-to-end business process
Users don't experience SAP as transactions; they experience processes. Build your regression scope around the processes that keep the business running, and include the hand-offs between modules, where most defects hide.
Order-to-cash (SD, LE, FI)
- Sales order creation with pricing, taxes (including GST/HST/QST where relevant) and credit checks
- Availability check, delivery creation, picking and goods issue
- Billing, output (invoices, EDI) and posting to accounting
- Returns, credit memos and incoming payments
Procure-to-pay (MM, FI)
- Purchase requisition and purchase order, including release strategies
- Goods receipt and quality inspection where used
- Invoice verification, including price and quantity variances
- Payment run and vendor (Business Partner) master changes
Record-to-report (FI, CO)
- Journal entries, accruals and allocations
- Asset postings and depreciation
- Period-end close steps and key financial reports
Warehouse (EWM or WM)
- Inbound: inbound delivery, goods receipt, handling unit creation, putaway tasks and confirmation
- Outbound: wave creation and release, picking, packing, staging, loading and goods issue
- Internal: replenishment, stock transfers, physical inventory and cycle counting
- RF/mobile transactions used on the warehouse floor
Tip: include at least one "unhappy path" per process: a blocked customer, a quantity variance, a short pick. Many regressions only appear when something goes slightly wrong.
3. Fiori apps, roles and authorizations
- Test with realistic business roles, not a superuser. Authorization changes are one of the most common sources of go-live tickets.
- Check the Fiori launchpad: catalogs, groups or spaces and pages, and tile visibility for each role.
- Re-test custom and extended Fiori apps, and the OData services behind them.
- Verify the browsers and devices your users actually use, including warehouse handhelds.
4. Custom code and interfaces
Standard SAP functionality is tested by SAP; your custom code and interfaces are not. Give them extra attention:
- Custom code: run static checks (such as the ABAP Test Cockpit with the relevant check variants) and functionally test custom reports, enhancements, user exits and BAdI implementations.
- IDocs and EDI: send and receive representative messages for each partner and message type; check status handling and error reprocessing.
- RFC and BAPI calls: verify calls from and to external systems, including authorization of technical users.
- OData and APIs: test payloads, field mappings and error responses, not just whether the service is reachable.
- Batch jobs: confirm scheduled jobs, variants and job chains still run in the right order.
- Forms and output: invoices, delivery notes and labels render correctly and reach the right printer, email or EDI channel.
5. Integrations with other systems
Most enterprises run SAP alongside a CRM, e-commerce platform, warehouse automation, carriers and banks. Regression testing should cover each integration end to end:
- A won opportunity in Salesforce creates the correct order in SAP, and status flows back
- Customer, product and price changes sync in the right direction
- Middleware mappings, retries and error alerts behave as designed
- Shipment and tracking updates reach customer-facing systems
Cross-platform scenarios like these are where SAP and Salesforce teams often test only their own half. Our SAP–Salesforce integration testing covers both sides together.
6. Test data management
Poor test data is the most common reason regression testing stalls. Plan it as carefully as the tests themselves:
- Identify the master data each scenario needs: customers, vendors, materials, pricing, storage bins and handling units.
- Decide how data will be created: copied from production (with personal information masked), generated by scripts, or created by automated set-up steps at the start of each test.
- Make tests re-runnable: automated scenarios should create or reset their own data so they can run again tomorrow.
- Protect personal information in line with Canadian privacy law when using production-derived data.
7. Environments and transports
- Confirm the test system is a realistic copy of production, including configuration, interfaces pointed at test endpoints and recent data.
- Freeze or tightly control transports during the regression window so results stay meaningful.
- Keep a transport log alongside test results so any defect can be traced to a specific change.
- Check connectivity to every integrated test system before day one of testing.
8. What to automate and what to keep manual
SAP test automation pays off when the same scenarios are run repeatedly: every support pack, upgrade and major transport. A practical split:
| Automate | Keep manual (for now) |
|---|---|
| Core end-to-end processes run every release (O2C, P2P, warehouse flows) | Processes that are being redesigned or change frequently |
| High-volume, data-driven variations (many materials, plants or order types) | Rarely used scenarios, such as annual processes, until they stabilize |
| Interface and API checks with predictable inputs and outputs | Exploratory testing of new functionality |
| Smoke tests after every transport or deployment | Usability feedback and user acceptance |
Design automated tests as reusable business components (create sales order, post goods issue, create invoice) so a change in one step is fixed once, not in every script. Connect the suite to your CI/CD or transport process so it runs automatically. TRICIQ builds and maintains suites like this as part of our SAP test automation service.
9. Defect triage
- Agree severity definitions up front, for example: a blocked business process, a workaround available, cosmetic.
- Triage daily with functional, technical and business representatives so defects are routed to the right owner quickly.
- Record the scenario, test data, transport and screenshots or logs with every defect so it can be reproduced.
- Re-run the affected regression scenarios after each fix, not just the single failed step.
10. Sign-off and cutover
- Define exit criteria before testing starts: for example, all critical processes passed, no open high-severity defects, and known issues accepted in writing by the business owner.
- Name a business sign-off owner for each process area.
- Plan a post-go-live smoke test of the most critical processes in production.
- Keep the regression suite and results for the next release; that's how each cycle gets faster.
If you need extra capacity for a release, experienced SAP testers and test managers can plug into your team for the regression window, while automation reduces the effort needed next time.