Written by Minami — Paddy & Water Inc. / Technology & Platform

Mastering the Test Phase

Ensuring Quality and Accelerating DX

June 2026

Introduction: Testing Is Not “Bug Hunting” — It Is “Insurance for Go-Live”

In SAP S/4HANA implementation projects, the test phase tends to be regarded as a passive activity — something you “try out” once design and development are finished. However, this perception is fundamentally mistaken. Testing is the activity of accumulating objective evidence to answer the question, “Is it acceptable to move to production in this state?” in preparation for the single, one-shot event that is go-live.

“No bugs were found” is not proof that “quality is high.” Only the fact that “sufficient scenarios were tested with sufficient technique by sufficient people, and all passed” constitutes evidence of quality for the first time. What determines the quality of testing is not “how many tests were run” but “which scenarios, with which data, from which perspectives were tested.”

This guide provides a practical explanation of the test phase in an SAP S/4HANA implementation, covering everything from the overall design through execution, management, and go/no-go criteria. The central message of this guide is to position testing not as a mere “task” but as “the last line of defense that leads DX to success.”

Chapter 1: Overall Design of the Test Framework — “What, in What Order, and by Whom” to Test

1-1 The Four-Layer Structure of SAP S/4HANA Testing

In an SAP S/4HANA implementation, testing consists of four layers. Each layer is interdependent, and the principle is to manage them using a “gate method,” in which progress to the layer above is only permitted once the layer below has passed.

Test Layer	Purpose	Performed By	Definition of Done
① Unit Testing (UT)	Verifying the behavior of individual functions and programs	Consultants / developers	All test cases pass. Defect fixes completed.
② Integration Testing (IT)	Verifying coordination across multiple modules and processes	Consultants + business teams	End-to-end scenarios pass. Zero critical defects.
③ UAT (User Acceptance Testing)	Final confirmation of business fit by actual users	Business department staff	All UAT scenarios pass. Sign-off obtained from the business department.
④ Performance Testing	Verifying performance under production-equivalent data volume and concurrent connections	Technical team	SLAs (response time, batch completion time) are met.

1-2 Defining the Test Scope: Decide “What to Test” First

One of the most important decisions in testing is “defining the scope.” Attempting to test every single function requires unlimited time and resources and will cause the project to collapse. Scope should be prioritized on a risk basis.

Priority	Criteria	Test Density
Highest priority	Critical business paths (shipping, billing, period-end closing)	Thorough testing covering all scenarios, including exception cases
High priority	Functions used frequently on a daily or weekly basis	Coverage of the main scenarios
Medium priority	Functions used monthly or quarterly (month-end closing, inventory counts)	Representative scenarios
Low priority	Rarely used functions (annual processing, special transactions)	Minimal confirmation
Out of scope	Existing standard functions with no changes, or items planned for a future phase	Omitted (only changed items are tested)

Chapter 2: Designing Test Scenarios — Reproducing “Real-World Operations”

2-1 What Is a Test Scenario? Connecting the Entire Business Flow with “a Single Thread”

A test scenario is a scenario document that covers the entire business flow, describing “which screen operation in SAP a given business event starts from, what processing it goes through, and what the outcome should be.” A test case such as “material master can be registered” is not a scenario. An end-to-end flow such as “Customer A orders 10 units of Item B → inventory allocation → shipment → invoice issuance → payment received → accounts receivable clearing” is a scenario.

2-2 The Process for Designing Test Scenarios

Five Steps for Designing Test Scenarios

Step 1: Identify the “processes to be tested” from the list of business processes

Step 2: For each process, identify “normal-path (standard transaction)” and “exception-path (error/exceptional)” scenarios

Step 3: Set specific “test data” (item codes, quantities, amounts, etc.) for each scenario

Step 4: Clearly state the “expected result” of each step (e.g., invoice XXX is generated, with an amount of YYY yen)

Step 5: Organize the “execution order and dependencies” among scenarios (in cases where one scenario’s results are referenced by a subsequent scenario)

2-3 The Importance of Exception-Path Testing: “When Things Go Wrong” Is Precisely the Moment of Crisis in Production

The area most often skimped on in test design is “exception-path testing.” Anyone can think of normal-path tests (expected operations and data), but “exception-path tests” (incorrect operations, erroneous data, out-of-authorization operations) tend to be overlooked unless deliberate attention is paid to them.

However, what confuses users most in the production environment is precisely “when things do not go well.” An error message is incomprehensible and operations grind to a halt; no one approves a request in the approval workflow and work cannot proceed; inventory goes negative and a stock transfer document cannot be posted — it is essential to confirm and document the handling procedures for such exception-path situations during the test phase.

Type of Exception-Path Test	Test Example	What to Verify
Input error	A required field is left blank, or text is entered into a numeric field	That an appropriate error message is displayed
Authorization error	An unauthorized user attempts to view a confidential report	That access denial (authorization error) functions correctly
Business rule violation	Registering a sales order that exceeds the credit limit	That the credit check is triggered and the order is placed on hold
Insufficient inventory	Attempting to ship an item with zero inventory	That an ATP-failure error occurs and the shipping document cannot be created
Outside the accounting period	Attempting to post a journal entry to a closed accounting period	That posting is blocked with an error (or an appropriate warning is issued)

Chapter 3: Integration Testing (IT) — Crossing “the Walls Between Modules”

3-1 The Essence of Integration Testing: Integration Testing Is Difficult Precisely Because SAP Is “a Single Monolith”

SAP S/4HANA is a single system, yet it is composed of numerous functional modules, including SD (Sales), MM (Purchasing), PP (Production), FI (Finance), and CO (Management Accounting). Integration testing is testing that verifies “whether data is correctly linked” across these modules.

The reason integration testing is difficult is that a single business event cascades across multiple modules. For example, when “shipment processing (SD)” is executed, “inventory is simultaneously reduced (MM)” and “the cost-of-goods-sold journal entry is automatically generated (FI).” Verifying whether this chain of events functions correctly requires the SD owner and the FI owner to execute the same test scenario together. Testing separately by module in a “siloed” manner cannot capture the fundamental challenge of integration testing.

3-2 Designing Integration Test Scenarios: E2E (End to End) Is the Principle

Integration Test Scenario	Start	End	Modules Involved
Order to Cash (O2C)	VA01 Sales order creation	F-28 Incoming payment clearing	SD / MM (ATP) / FI
Procure to Pay (P2P)	ME21N Purchase order creation	F110 Automatic payment	MM / FI
Production planning to finished-goods receipt	MD01N MRP run	MB31 Finished-goods receipt	PP / MM / CO
Project to percentage-of-completion revenue recognition	CJ01 WBS creation	VF44 Revenue recognition	PS / SD / CO / FI
Monthly closing cycle	FB01 Manual journal entry	F.07 A/R reconciliation	FI / CO

3-3 Defect Management: “How Should Issues Be Managed?”

A large volume of defects (bugs, configuration mistakes, discrepancies from specifications) are discovered during integration testing. Unless these are managed appropriately, it becomes impossible to grasp “which defects have been resolved” and “which defects remain outstanding,” and testing will never converge.

Defect management should use a “defect management tool” (Jira, ServiceNow, an Excel tracking sheet, etc.) and must always record the following four items.

Required Items to Record for Defect Management

① Defect ID, date found, discoverer, test scenario ID

② Steps to reproduce the defect (operating procedure, test data, actual result, expected result)

③ Severity (Critical/High/Medium/Low) and priority (P1–P4)

④ Owner, planned fix date, fix verifier, close date

Consultant’s Perspective

It is not uncommon for projects to still have Critical bugs (defects that block go-live) remaining the day before cutover. Presenting management with a weekly “trend graph of remaining Critical bug counts,” and maintaining a trajectory such as “5 this week → 2 next week → 0 the week after,” is a necessary condition for calmly making the Go/No-Go decision.

Chapter 4: UAT (User Acceptance Testing) — “The People Who Use the System” Grant the Pass

4-1 UAT Is the Process of Obtaining Sign-off (Approval)

UAT (User Acceptance Testing) is the process of obtaining the final “certificate of acceptance” for the system from users in the business departments. No matter how strongly the technology team or consultants insist the system is “perfect,” there is no basis for proceeding to go-live unless the business departments confirm “we can carry out our operations with this.” UAT must be designed as a formal process for obtaining this “declaration of acceptance (sign-off) by the users.”

4-2 Planning and Running UAT

Item	Recommended Approach
Who performs UAT	Frontline users who actually perform the operations (consultants may not perform UAT on their behalf)
UAT scenarios	All major patterns of daily operations, plus representative scenarios for monthly and annual processing
UAT data	Real data close to production (or sample data close to real data)
UAT duration	2–4 weeks (compressing the period too much causes many issues to be overlooked)
Sign-off conditions	Zero Critical defects / all High defects confirmed with planned fixes / signature of the business department owner
Response in case of an NG (fail)	After the defect is fixed, retest the relevant scenario and obtain re-sign-off

4-3 The “Three Traps” That Make UAT a Mere Formality

In practice, UAT easily becomes a mere formality. In projects that fall into the following three traps, the true purpose of UAT is lost, and in many cases a large volume of problems erupts after go-live as a result.

• Trap ①: “Consultants perform UAT on the users’ behalf” — this fails to confirm whether users can actually understand and use the system. It creates a situation in which the business department merely “feels like it passed” without grasping the actual state of affairs.

• Trap ②: “Test data is unrealistic” — testing with fictitious data or small data volumes cannot reproduce the complexity of real operations. For example, a high-load scenario such as 10,000 sales orders flowing through simultaneously can only be verified at real data scale.

• Trap ③: “Sign-off becomes a ritual” — cases in which sign-off is obtained “with full knowledge” of remaining defects, purely to keep the project schedule, even though many defects remain. Any “conditional sign-off given with full knowledge” of outstanding issues must be explicitly recorded and reflected in the Go/No-Go decision.

Chapter 5: Performance Testing and the Go-Live Decision

5-1 Designing Performance Tests

The problem of SAP S/4HANA being “too slow to use” in the production environment arises when testing during the test phase was only conducted with a small volume of data and a small number of users. Performance testing is the activity of verifying the system’s response speed and processing capacity under “production-equivalent conditions.”

Test Type	Purpose	Metrics Measured
Load testing	Confirming response times under a normal number of concurrent connections	Transaction response time with the peak number of concurrent users
Stress testing	Confirming behavior under extreme load	The number of users at which the system breaks down, and the point at which response is severely delayed
Batch performance	Confirming the time required for overnight batch processing	Time required for the MRP run (MD01N), the month-end closing batch, and the payment-clearing batch
Data volume testing	Confirming processing performance at production data volumes	Inquiry and aggregation speed with three or five years’ worth of accumulated data

5-2 The Go-Live Decision (Go/No-Go): The Final “Declaration of Launch”

At the end of the test phase, a “go-live decision meeting (Go/No-Go Meeting)” is held. This is the forum in which management formally decides “whether to comprehensively evaluate the test results and proceed with cutover as planned (Go), or postpone it (No-Go).”

This meeting must not be a mere formality. Objective evidence for every decision criterion (test results, defect management status, list of unresolved issues) is presented, and it is a formal process in which the project sponsor “declares Go having understood the risk of moving to production in this state.”

Decision Category	Go Condition	No-Go Condition
Test completion rate	95% or more of all UAT scenarios executed and passed	Completion rate below 80%, or major scenarios not executed
Defect status	Zero Critical bugs. High bugs have confirmed workarounds	Even a single unresolved Critical bug exists
Performance	All SLAs met (response within 3 seconds, overnight batch within 8 hours)	SLA not met, and no improvement measures determined
Sign-off	Formal sign-off obtained from all business departments	Sign-off not obtained from a major department
Organization/readiness	Assignment of all cutover personnel confirmed	Absence of key personnel with no replacement available
Rollback	Rollback procedure verified and confirmed operational	Rollback procedure unverified and not prepared

5-3 Carrying the “Quality Culture” Cultivated in the Test Phase Forward After Go-Live

Even after the test phase ends and production operations begin, the stance of “underpinning quality with evidence” must not be lost. Regular post-go-live business data quality checks, monthly monitoring of the journal-entry automation rate, and quarterly measurement of system response times — these are all extensions of the “culture of discussing quality through objective evidence” cultivated during the test phase.

Testing is not “something done before release” but rather “continuously confirming the alignment between the system and business operations at all times.” This recognition is precisely the most important organizational capability for nurturing SAP S/4HANA not merely as “a system that has gone live,” but as “a platform that continuously drives DX.”

— End —