Lesson 2 of 5
Positive testing
10 min
A positive role test proves that a user holding the role can do every task the job needs, end to end, in the org units they work in. It sounds easy. In practice it is where most go-live access problems are found, because users discover on day one that a step in their daily work fails with "You are not authorized".
The single most important rule
Test with a dedicated test user that holds only the target role (plus any baseline roles every user gets). Never test with your own project user. Key users and testers usually have broad access to do their project work, so a step that would fail for a real billing clerk passes for them. The result is a false pass that goes straight to production.
| Tester's own project user | Dedicated test user with target role only | |
|---|---|---|
| Roles held | Many, often broad | Exactly what the real job will get |
| Missing authorization | Hidden by other roles | Shows up as an error |
| Org restrictions | Often unrestricted | As designed, for example sales organization 1710 only |
| Value as evidence | Low | High: reflects production reality |
Setting up test users
Ask the security team for one test user per role combination you will test, named so the purpose is obvious (BILL-TEST-01, PUR-TEST-01). Each user gets exactly the roles a real person in that job will get, including the baseline role, and nothing else. Record the assignments in the test plan and check them before each cycle: test users are a favorite place for someone to add an extra role "just to get past a blocker", which quietly invalidates every later test run with that user.
Running a positive test
- Prepare userTest user BILL-TEST-01 with Contoso's billing clerk role only, in QAS client 100
- Check the launchpadEvery app the tasks need is visible in the user's spaces and pages
- Run each task end to endNot just open the app: create, change, save and display real documents
- Record failures preciselyApp, step, message text, and the authorization check result
- Retest after fixesSame user, same steps, until every must-do task passes
Opening an app is not enough. In Fiori, an app can appear on the launchpad because its catalog is in the role, yet fail when the user saves, because the back-end authorization for that activity or document type is missing. Run every task to its business result: the invoice is created and posted, the credit memo is saved.
When a step fails
Record exactly what happened, then capture the authorization check. In SAP GUI and in many Fiori back-end checks, the user can run SU53 straight after the failure to display the last failed check. When SU53 is not conclusive, the security team can record an authorization trace with STAUTHTRACE while the test user repeats the step. In Public Edition, administrators use the Display Authorization Trace app, which shows checks as successful, failed or filtered. Give the security team this information, not just "it doesn't work".
| What to record | Example |
|---|---|
| User and role | BILL-TEST-01, Contoso billing clerk role, version in transport of 12 May |
| Task and step | Create credit memo from request 60000123, step: save |
| Message | Exact message text and number as shown |
| Authorization check | SU53 output or trace extract showing the failed object and value |
| Expected behavior | Credit memo should save; task is in the must-do list |
A useful missing-access defect.
Org units in positive tests
Run each task in every org unit the job covers. Contoso's billing clerks work for sales organization 1710 and bill deliveries from both shipping points, 1710 Detroit and 1720 Chicago. A positive test that only uses Detroit deliveries cannot tell you whether Chicago works. List the org units in the test data and cover each.
What would you do?
Priya's tester runs the billing clerk positive tests with her own project user and everything passes. On the first go-live day, real clerks cannot create credit memos. What went wrong?
- Positive tests prove every must-do task works end to end for the role.
- Always use a dedicated test user holding only the target role.
- Run tasks to their business result; a visible tile is not proof of access.
- Capture failures with message text and the authorization check (SU53, trace, Display Authorization Trace).
- Cover every org unit the job works in.
Check your understanding · not graded
Lesson check
1. Why test roles with a dedicated test user rather than a tester's broad access?
2. A Fiori tile is visible but saving fails. What is the likely cause?
3. Which transaction shows the last failed authorization check for a user?
4. Billing clerks work for both shipping points 1710 and 1720. What should positive tests cover?