Lesson 3 of 6
Test users and assignments
7 min
Listen to this lesson
A role test is only meaningful if the test user holds what a real production user will hold: the same roles, in the same combination, with the same organizational values. Most role defects found late are combination defects, where each role is fine on its own but a user gets two roles whose authorizations add up to something unexpected, or a composite role is missing one of its parts.
Build users from the production assignment plan
Start from the planned user-to-role assignment for go-live, not from the role catalog. If Maria, the order-to-cash key user, will hold a composite role made of sales order processing, delivery display and customer master display for sales area 1710 / 10 / 00, create a test user with exactly that composite role. If some Chicago warehouse staff will also hold a cycle-counting role, create a second warehouse test user with both roles.
| Aspect | Test each role in isolation | Test production combinations |
|---|---|---|
| Test user setup | One user per single role from the role catalog | One user per distinct combination in the go-live assignment plan |
| Missing part of a composite role | Not found | Found: the user holds exactly the composite Maria will hold |
| Authorizations that add up across roles | Not found | Found: the warehouse lead's two roles are tested together |
| Org values | Often generic | The real ones: plant 1720, storage location 172A, sales org 1710 |
| Test user | Mirrors | Roles assigned | Org values |
|---|---|---|---|
| T_OTC_CLERK_01 | Sales clerk, Detroit | Composite: sales order processing, delivery display | Sales org 1710, plant 1710 |
| T_BUYER_CHI_01 | Buyer, Chicago | Purchasing operational role | Purchasing org 1710, plant 1720, purchasing group 001 |
| T_WH_CHI_01 | Warehouse clerk, Chicago | Goods movements | Plant 1720, storage location 172A |
| T_WH_CHI_02 | Warehouse lead, Chicago | Goods movements plus physical inventory | Plant 1720 |
| T_AP_CLERK_01 | Accounts payable clerk | Supplier invoice processing | Company code 1710 |
Contoso test users for role testing in QAS client 100. Names follow a convention so they are easy to find and never mistaken for real users.
Creating and maintaining test users
In the ABAP stack, users are maintained in SU01, or in bulk with SU10, and roles can be assigned from the user or from the role in PFCG. After roles change, the users' profiles must be brought up to date (the user master comparison), or the user keeps the old authorizations. Check this before every role test run: a test that fails because the comparison was not run is a wasted defect.
- Use dialog users for role tests, since they behave like real interactive users.
- Never add a broad role to a role-test user "just to get past" a step. If the step fails, that is the finding.
- Keep test user definitions under change control: when the production assignment plan changes, update the test users the same day.
- After a QAS refresh, test users are overwritten. Export and restore them, or recreate them from a script, as part of the refresh runbook.
- Keep passwords for shared test users in your organization's approved vault, never in test scripts or test case text.
Watch validity dates as well. Role assignments in SAP have a start and end date, and test users created for a previous cycle may have assignments that have quietly expired. A user whose role assignment ended last Friday will fail every test on Monday with messages that look like role defects. Include a quick SUIM check of assignment validity in the readiness list for every role test run.
- Has the user master comparison run since the last role change?Yes → next check · No → run it, or failures will be stale-profile noise
- Does SUIM show the user's roles match the assignment plan?Yes → next check · No → correct the user before testing
- Are all role assignments valid for today's date?Yes → next check · No → extend them; expired assignments look like role defects
- Has QAS been refreshed since the users were set up?No → ready to test · Yes → restore or recreate the test users from the runbook first
- Assignment planSecurity and process owners agree which users get which roles
- Create test usersOne per distinct role combination, with production org values
- CompareRun the user master comparison so profiles are current
- VerifyUse SUIM to confirm each user's roles match the plan
- TestRun positive and negative tests and record results by user
What would you do?
During UAT, the Chicago warehouse lead's test user fails to post a goods receipt. A colleague suggests adding the broad QAS tester role to the user so UAT can continue. What should Priya do?
- Test users must mirror production role combinations and org values, not individual roles in isolation.
- Maintain users in SU01/SU10, assign roles via user or PFCG, and run the user master comparison after role changes.
- Never widen a role-test user's access to get past a failure; the failure is the finding.
- Restore or recreate test users after every refresh, and use SUIM to verify assignments.
Check your understanding · not graded
Lesson check
1. Why should test users mirror production role combinations rather than single roles?
2. Which transaction maintains many users at once?
3. A role was changed yesterday but the test user still behaves as before. What is a likely cause?
4. Which tool answers "which roles contain this authorization object value?"