Lesson 1 of 6
Before you start
8 min
User acceptance testing (UAT) is where the business, not the project team, confirms that SAP S/4HANA supports the way it works. Business users and key users execute realistic scenarios, record what happened and raise defects. The process owner later relies on those results to sign off. Half of the failed UAT days on SAP projects are lost before the first step is executed: wrong client, missing roles, no stock, a transport that never arrived. Ten minutes of preparation saves those days.
Five checks before step 1
| Check | What to confirm | Contoso example |
|---|---|---|
| System and client | You are logged on to the test system and client named in the test plan, not development or training | QAS, client 100 (client 200 is training and has different data) |
| User and roles | You are using your own test user with the business roles the real job will have, not a user with every authorization | Maria's test user holds the order-to-cash business roles only |
| Build level | The transports or configuration the test depends on have been imported, and you know which build you are testing | Priya's daily note: "Build 14 in QAS since 07:00, includes the pricing fix" |
| Test data | Master data and stock exist and are in the right state; periods are open | 50 pieces of CMC-ALT-100 unrestricted in plant 1710, storage location 171A; customer Great Lakes Fleet Services with sales area 1710 / 10 / 00 |
| Test case | You have the current version, with expected results written down before you begin | TC-OTC-012 v3, with expected price, tax and revenue account |
The system and client appear in the SAP GUI status bar and in the Fiori launchpad's user menu (About or user settings, depending on release). Make checking them a habit: testing a correct process in the wrong client produces evidence nobody can use.
- Am I in the right system and client?Yes → check my user · No → log off and log on to the client named in the test plan
- Does my user have the planned business roles, and only those?Yes → check the build · No → stop and ask the test lead; do not borrow another user
- Is the build or transport my test depends on imported?Yes → check data · No → mark the test blocked and note the missing item
- Is the test data in the expected state?Yes → start executing · No → request or prepare data before step 1, and record what you changed
Why your own user matters
Testing with a powerful shared user hides two kinds of defect. Authorization defects, where the real user will not be able to run a step, only appear with realistic roles. Segregation-of-duties defects, where a user can do something they should not, only appear when roles are tested as designed. A UAT result produced with a borrowed all-powerful user is not acceptance of anything the real user will experience. If your roles are wrong, that is a finding in itself: log it.
Test data is part of the test
Many SAP scenarios consume their data. Once Contoso ships the 50 alternators, the stock is gone; the next tester finds zero and the delivery fails. Good UAT plans assign data to testers or include a data-preparation step. If you change data to make a test run (for example, posting stock with a goods receipt), record exactly what you did so the result can be interpreted and repeated. Never "fix" master data in a shared test system without telling the test lead; another tester's expected result may depend on it.
What would you do?
Maria logs on at 8:00 to run TC-OTC-012. The order saves, but the price is $10 lower than the expected result. She then notices the status bar shows client 200. What should she do?
- Check system and client, user and roles, build level, test data and test case version before step 1.
- Use your own test user with realistic roles; wrong roles are a finding, not a reason to borrow a user.
- If a dependency is missing, the test is blocked, not failed.
- Record any data you create or change so results can be interpreted and repeated.
Check your understanding · not graded
Lesson check
1. Why should a UAT tester avoid a shared user with broad authorizations?
2. The transport containing the pricing fix has not been imported into QAS. How do you mark the pricing retest?
3. Where can you confirm which client you are logged on to?
4. You posted a goods receipt to create stock for your test. What should you do?