Lesson 5 of 5
Testing and release changes
10 min
Listen to this lesson
A business role is finished when a user holding only that role can do the whole job, sees the data they should, and is stopped from everything else. Proving that takes role tests designed from the role's intent, not functional tests run with broad access. And because SAP changes catalogs with every release, the proof has to be repeated, selectively, after every upgrade.
What a business role test checks
| Check | Example for Ana's AP role | Layer it proves |
|---|---|---|
| Visibility | The Accounts Payable space shows the planned page and sections | Layout |
| Findability | Apps not on the page are still in the App Finder only if intended | Content |
| Launch | Each tile opens without a service error | Start authorization |
| Positive data access | An invoice for company code 1710 posts through to a document number | Back end |
| Negative data access | Posting for 1810 is refused; display follows the design | Back end (restriction) |
| Negative function | Supplier master maintenance is not reachable by tile, App Finder or link | Content and back end |
Six checks per business role, each tied to one of the access layers.
Priya runs these with test users that hold exactly the planned production role combination, nothing more. The task list that activates SAP content can generate one test user per role, which is handy in a sandbox; in CMQ Priya prefers named test users created to match the user-to-role mapping, and Sam's team restores them after every client refresh. Evidence for each check is the screen state plus, for failures, the SU53 output or trace (covered in the troubleshooting course).
Release changes in Private Edition
When Contoso upgrades to a new SAP S/4HANA release or feature pack, SAP may change catalogs (apps added, replaced or deprecated) and authorization default values. Two tools matter. Transaction SU25 compares SAP's new SU24 data with Contoso's and lists roles to check, including a step that updates application groups such as Fiori catalogs in role menus. For catalog changes specifically, the role menu comparison in PFCG, or report PRGN_COMPARE_ROLE_MENU, brings roles in line with changed catalogs; services added manually to a role are not covered by that comparison and must be reviewed by hand.
Release changes in Public Edition
Public Edition tenants are upgraded by SAP on a fixed schedule, with major upgrades twice a year. Changes ripple upward: a new field in a restriction type changes the restriction type, which changes the catalog, which changes every role using it. SAP's guidance is to start with the Release Assessment and Scope Dependency tool in the What's New area of the SAP Help Portal for process impact, then use the Maintain Business Role Changes After Upgrade app for the role-level detail: new restriction types, deprecated or removed catalogs, and catalogs with successors. Each updated role is then assigned to a test user to confirm the restrictions behave.
- Before the upgradeRead what is changingRelease notes, the release assessment tool, and the list of deprecated apps and catalogs.
- Test system upgradedAdjust rolesSU25 and menu comparison (private) or the role changes app (public); add successor catalogs.
- Regression windowRe-run role testsFocus on roles whose catalogs or restrictions changed, plus a sample of untouched roles.
- Production upgradedWatch the first daysMonitor authorization tickets and failed checks for affected roles.
- Is a catalog in the role deprecated?Yes → add the successor catalog and retest the apps · No → next question
- Did a catalog gain new apps?Yes → decide whether the job should have them; if not, use a custom catalog · No → next question
- Did a restriction type gain a field?Yes → set values deliberately, then test positive and negative data access · No → next question
- Were SU24 proposals changed for apps in the role?Yes → merge and review new objects before generating · No → regression sample only
What would you do?
After Contoso's first feature pack update reaches CMR, the role changes list shows that a catalog in the AP role now includes two additional apps, one of which displays supplier bank details. Grace asks whether this needs any action before the production update next week. What should Nadia say?
- Role tests check visibility, launch, positive and negative data access, and out-of-role functions.
- Use test users that hold exactly the planned production roles; restore them after refreshes.
- Private Edition: SU25 and the role menu comparison handle catalog and default-value changes.
- Public Edition: start with the release assessment tool, then the role changes app, then retest.
- A catalog change can widen access silently; the process owner decides on new apps.
Check your understanding · not graded
Lesson check
1. Which test proves the restriction part of Ana's AP role?
2. In Private Edition, which report brings role menus in line with changed Fiori catalogs?
3. What does SAP suggest Public Edition customers use first to understand an upgrade's process impact?
4. Why must a role changed after its test be retested before sign-off?