SAP Test Automation with Xiting

SAP test automation and modern SAP testing tools are essential for validating business processes, but they often fall short when it comes to authorization accuracy. Most SAP test automation tools focus on whether a workflow executes from end to end: they rarely reflect how roles and authorizations behave under real productive conditions. As a result, an authorization check in SAP may pass in a test system, while the same activity fails – or is over-authorized – in production.

Xiting closes this gap with a combination of SAP automation testing and productive data. The Productive Test Simulation (PTS) evaluates new and redesigned roles with real productive logic, without interrupting users or processes, and dramatically reduces manual effort when you check roles in SAP. In combination with a controlled deployment approach such as Protected Go-Live (PGL), organizations gain a more stable and predictable path for every SAP role redesign project – from initial design to go-live – supported by SAP testing tools for automation instead of spreadsheets and guesswork.

Why traditional SAP role testing no longer fits modern projects

Welcome to SAP Knowledge in a Nutshell. One of the biggest challenges during a SAP role redesign project, is ensuring the functionality of new roles in daily operations. With the PTS, short for productive test simulation, you can validate authorization roles directly under real conditions. This works by comparing user activities in the productive system to the newly designed authorizations. Our solutions, the Xiting Times protocols, the missing authorization checks, and makes them available for a detailed analysis. This SAP role redesign best practice approach minimizes risks and resource demands, while providing the confidence needed for a successful go live. With the productive test simulation, you can validate your newly created roles directly in the productive environment alongside day to day business activities. Rather than relying on separate test environments and significant IT involvement, end users simply continue their normal work. Meanwhile, their actions are analyzed regarding the performed authorization checks to confirm that the new roles function as intended. By combining real usage data with a smart evaluation tool, the PTS shortens testing cycles, reduces resource needs, and ultimately ensures a smooth go live without surprises. From a technical perspective, the productive test simulation assigns a reference user in the background, which acts as a backpack for the new roles. While the employee continues working with their regular authorizations, the system quietly simulates how the new roles would have matched. This creates a safe what if scenario. If any authorization checks fail under the simulated roles, the failures are captured and logged in a dedicated Xiting table. These results provide a list of missing permissions that should be analyzed and added before the go live, ensuring that the new roles are stable and reliable from day one. After a period of productive testing, it's time to activate the new role concept. Even at this stage, missing authorizations aren't uncommon, as not every business process is performed on a regularly basis. Rather than causing interruptions or delays, Xiting Times provides temporary backup access to ensure users can continue working without disruption. This process is called protected go live. Within this project phase, users are assigned their new roles, while their old roles remain available as a temporary reference in the background. This backup isn't active by default, but users can access it on demand using a self-service if they encounter a missing authorization. This approach creates a safe fallback scenario. Users stay productive, business processes continue smoothly, and IT can efficiently track and resolve any missing permissions, ensuring a controlled and reliable go live. Xiting Times ensures a smooth and secure launch of new roles. With the productive test simulation, roles can be tested directly in the productive environment. This ensures a high quality of test results as users are executing their daily work to give us details on the performed authority checks. The protected go live provides temporary backup access, enabling users to continue working seamlessly while missing permissions are identified and corrected. With reference users and full auditability, IT gains transparency and control, minimizing risks and ensuring a reliable rollout of new authorizations. Thank you for watching. Would you like to find out more about Xiting Times? Check out our video channel on our homepage, or feel free to contact us. We will get back to you as soon as possible.

In many organizations, SAP role testing still looks very traditional. New roles are created in a development system, transported to a QA client and then handed over to business users who are asked to click through their daily work. The goal is to confirm that core processes still run and that every important authorization check in SAP passes in the test system.

From a security perspective, this approach has clear limits:

Test cases are often incomplete, and the way users actually work in production is very different from what they do in a scripted test.
As a result, an authorization check in SAP may succeed in QA but fail in the productive system, or the opposite: a user receives more access than intended because nobody had time to check authorization in SAP in all combinations of roles and org levels.

At the same time, project teams are under pressure to move faster. When a SAP role redesign project is running in parallel with other initiatives, there is little room for repeated manual test cycles. Security and compliance teams still need to check roles in SAP regularly, run each critical authorization check SAP requires for sensitive transactions and document that they have done so. Without the right SAP testing tools, this quickly leads to long test phases, overloaded key users and a growing backlog of open findings.

What is missing is a way to connect SAP test automation with the reality of productive usage. Instead of asking users to repeat artificial test scripts, organizations need a controlled way to let users work as usual and automatically record every relevant check authorization SAP performs in the background.
This is exactly the gap that Xiting’s Productive Test Simulation and Protected Go-Live address in the next sections.

Productive Test Simulation (PTS):
SAP test automation directly in productive landscape

Productive Test Simulation (PTS) is the core concept that makes SAP testing in production possible without putting operations at risk. Instead of letting users test in a separate system, Xiting lets them continue their normal work in the productive system while authorization and role checks are simulated and logged in the background.

From a technical perspective, PTS acts as an SAP test automation tool that runs directly in the productive system. New or redesigned roles are prepared in XAMS and assigned to reference users. When a PTS session starts, these reference users are assigned to the respective dialog users. Missing authorizations for the reference users are logged, whereas dialog users can continue working uninterrupted, as they keep their previous roles. In other words, you can check authorization in SAP for a new role concept while day-to-day operations remain untouched.

Welcome to SAP Knowledge in a Nutshell. Let's break down how the productive test simulation is executed. We'll first take a brief look in our SAP system how we have set up our testing scenario, and then we'll trace the authorization data utilizing PTS in exciting times. This best practice approach is a complete new way how to perform SAP testing for authorizations passively and improve user acceptance testing in SAP. Before we start testing, let's take a look at our user setup. We've already ensured that all necessary steps for the exciting time setup and customizing have been completed in the last session. So let's take a look at our test user in SU01. This user currently has basic roles and an accounting role containing too much authorizations. This role covers not only all authorizations the user needs for his daily business, but even more, which is critical. Now, let's check our reference user, which will get our newly designed accounting role that we would like to test during PTS. For productive test simulation, the reference user always has the new role, which usually contains fewer authorizations than the old roles. In our case, the new role includes some basic transactions like FB03 or MM03. But no organizational levels are maintained in the role profile. Most authorization values are filled with dummy values, meaning the role has very few authorizations. The goal here is to collect data about missing authorizations based on the actions we will execute during testing. Now that everything is set up, the admin can start the productive test simulation for the selected users in the Exciting Times administration cockpit via Start Pseudo Sessions. Let's search for our dialog user and select the line with the respective reference user. After document our actions by typing in a reason and setting the duration for how long the productive test simulation should run. Once that's done, we continue, and the reference user is automatically assigned in the background. Also, the collector job has started to trace the user activities. Before we log in as our test user, let's take another quick look at the dialog user in SU01. The reference user and its roles, our newly created accounting role, are now assigned, which means it's now being tested by our end user. Now we are logged in as our test user in the productive system. Let's walk through some of the steps he could take in his daily work. First, we will open FB03 and display some accounting documents, which is part of the new role. This will work without any issues, even though there might be missing authorizations like specific company codes in the new role, because the user still has the old roles that allow him to perform these actions. Next, let's try opening F22. This transaction is currently not included in the new role, but since the user still has his old accounting role assigned, these old authorizations are still valid and still enable him to access this transaction as the user always used to. Finally, let's try a transaction that is not included in either the old or the new role, such as SU01. Here, we'll encounter an error due to missing authorizations, as none of the roles provide the necessary permissions for this transaction. For now, we finished testing and are back in the exciting Times Administration cockpit as our admin user. To stop a simulation session, you can simply wait until the requested session time ends, and the reference user assignment will automatically be revoked and the collector job stops recording trace data for this session. You can also end a session manually in advance if you want to. This can be done using the option terminate pseudo sessions. After selecting the corresponding users again, you will have to enter a reason for the early termination of the session. That's it for the execution of PTS. The next steps are analyzing and evaluating the collected test data, which we will take a look in a future lesson. Thank you for watching. Would you like to find out more? Check out our video channel on our homepage or feel free to contact us. We will get back to you as soon as possible.

Every click they perform during a PTS session becomes part of your automated test set. Compared to manual test cycles, this approach saves significant effort and gives you much better insight into where to adjust roles and where to tighten access. Because PTS runs in the productive system, it offers a level of accuracy that generic SAP automation testing cannot reach on their own.

Traditional SAP automation testing tools validate roles, but they usually do not reflect the final, productive authorization model. PTS closes this gap by recording each authorization check SAP performs against the simulated roles of the reference users and feeding this information back into XAMS for analysis and optimization.

For organizations planning a large SAP role redesign project, PTS becomes the central SAP automation testing tool to validate the new concept before any risky go-live.

How Productive Test Simulation (PTS) works in practice

In concrete terms, setting up Productive Test Simulation (PTS) in SAP follows a clearly defined sequence of steps that bring SAP test automation directly into the productive system and capture every relevant authorization check in SAP.

Design new roles
New or redesigned roles are created using tools like Role Designer within XAMS. These roles follow the principle of least privilege and are prepared for assignment.
Prepare reference users and Xiting Times
In Xiting Times, reference users that represent the new role concept are configured. The system is set up for Productive Test Simulation mode, including RFC connections, background jobs (e.g. collector jobs), and basic customizing.
>> Check out now how to set up Xiting Times before running the PTS
Start a PTS session
A business user in the productive system gets assigned a reference user in the background for the duration of several weeks. On the surface, nothing changes: the user keeps the old roles and logs in as usual and runs daily transactions – for example FB03, MM03, or their typical process variants.
Authorization checks are simulated in the background
Every authorization check in SAP during that session is evaluated against the simulated roles. Missing permissions are logged (in a dedicated Xiting table in which the collected the trace data is stored) and later analyzed in Role Builder.
Refine roles based on real usage
Security administrators use the simulation data to adjust role content, organizational values, and SU24 proposals. Instead of guessing what might be required, the system shows exactly which authorizations were needed and which ones caused issues. Helpful add-ons with predefined blocklists and allow lists highlight critical and required authorizations.

Throughout this process, the productive system remains stable: missing permissions in the new roles do not block the user, because the simulation runs in the background and the old role assignments remain. Traditional manual test cycles are replaced with an automated, trace-driven feedback loop inside production.

Benefits of Productive Test Simulation as an SAP testing tool

With PTS, SAP test automation for roles moves closer to how application testing is already done today:

No process interruption: Testing runs in parallel to the productive system; newly created roles are tested automatically in the background while users continue their daily work.
Realistic coverage: Testing happens during real work, not in artificial scenarios.
Less test effort: Users don’t need separate test sessions; their daily work generates the test data, so business departments don’t have to allocate extra testing resources.
Higher precision: Instead of generic logs, you get clear, structured simulation data that feeds directly into SU24 so that proposal values can be adjusted based on real usage instead of guesswork.
Better control and compliance: Blocklist and whitelist functions help you enforce compliance requirements: critical activities can be explicitly blocked, while missing authorizations are suggested in a controlled way based on the productive test data.

Protected Go-Live (PGL):
Risk-free transition to a new authorization concept

Even with excellent test automation, the moment of truth is still the go-live. Especially in an SAP role redesign project, the biggest risk is simple: a user suddenly cannot perform a step because a permission is missing. That risk often leads to unwanted decisions – such as over-authorizing users or postponing necessary changes. Protected Go-Live (PGL) is Xiting’s answer to that problem.

Is your go-live date approaching, and you're concerned about a smooth transition to the new authorization concept? Do you fear that missing authorizations may disrupt daily business? Many authorization projects face the same challenge. Due to tight timelines or limited testing windows, roles are often not fully validated before go-live. As a result, missing authorizations only become visible once users start working productively. This puts pressure on both - end users, who are blocked in their tasks, and role administrators, who must react immediately to resolve missing authorizations and keep business processes running without major interruptions. A Go-Live that should be a milestone quickly turns into a stressful firefighting phase. To address this challenge, XAMS provides the Protected Go-Live concept. Protected Go-Live helps ensure a stable transition to a new authorization concept by providing a controlled operational safeguard. After the new roles and authorizations are activated and assigned to end users, the Protected Go-Live phase ensures that reference users remain available as a backup in case any authorizations are missing. These reference users retain the previously used roles or a powerful project-role depending on the context of your authorization project. If a user encounters a missing authorization that prevents him from completing his tasks, he can simply use a self-service transaction to request temporary access to the predefined project role with extended authorizations. This allows him to resume his work immediately. At the same time, authorization checks are logged and the new roles can be adapted based on the corresponding trace data. Let's take a look at how the Protected Go-Live works from an end-user perspective. We are now logged in as our test user, who has just received his new roles. Now if we attempt to access a transaction that is not included in the new authorization role, an error message will prevent us from continuing our work. Since we used to create materials in transaction MM01 in the past and that authorization is now missing, we can request temporary access to our former roles via a self-service transaction. After entering a reason and the requested duration, the reference user containing the old role set is automatically assigned, allowing the user to continue work immediately. From this point on, the previous authorizations remain active for the rest of the workday, allowing us to access MM01 again and continue working without disruption. At the same time all authorization checks are traced in the background Once the entered time period of 8 hours expires, the reference user is automatically removed, and the user will continue working only with the new authorization-set the following day. To ensure everything will function correctly, the admin analyzes the collected trace using the Role Builder Coverage Analyzer. Here, you benefit from features such as a real-time list of failed authorization checks that require maintenance, as well as color-coding that highlights critical and non-critical authorizations. The process for handling the findings list remains identical to the process used in our Productive Test Simulation. If you need a refresher, we recommend reviewing the videos on the Coverage Analyzer and the SU24 Checkman. In summary Protected Go-Live ensures a smooth go-live by allowing users to immediately regain missing authorizations through a self-service process, preventing workflow interruptions and reducing go-live chaos for both administrators and end-users. This data-driven approach allows a controlled and transparent improvement of your authorization concept and supports standard-compliant role optimization. Thereby you ensure that your roles improve based on actual system usage and you will have a smooth transition into your new role concept. If you would like to discuss how this approach can support your specific Go-Live scenario, feel free to contact us for a demo. We will get back to you as soon as possible!

How Protected Go-Live (PGL) works

During a Protected Go-Live, the new role concept is activated, but the old roles don’t disappear completely. Instead, Xiting Times keeps them in the background as a controlled fallback:

Users receive their new roles as planned.

Their previous roles remain available as “backup” in the background assigned to the cloned reference users.

If a user encounters a missing permission, they can temporarily reactivate their old roles for a predefined time period (e.g. 8 hours) – typically via a guided, self-service – to complete their task.

Every use of the fallback is logged in detail so that security and audit teams can see exactly when, why, and for how long it was used.

SAP Administrators then analyze the missing permissions, correct the new roles, and gradually reduce the need for the fallback. Once the role concept is stable, old roles can be removed in a planned, documented step.

Why Protected Go-Live (PGL) matters for SAP role redesign projects

PGL directly addresses the main reasons why an SAP role redesign project is often postponed:

Risk of production outages, because a missing authorization blocks critical processes.
Support overload, because IT has to react ad hoc to every missing authorization.
Low acceptance, because end users feel like “testers” during go-live.

With PGL, you can check roles in SAP under real productive conditions and still guarantee a safe fallback. End users stay productive, while IT gains the time and data needed to refine the new roles.

Xiting Times: The control center for PTS, PGL and Emergency Access

Both Productive Test Simulation (PTS) and Protected Go-Live (PGL) are orchestrated by the Xiting Times module in XAMS. While the technical setup includes details such as RFC connections, collector jobs and reference user maintenance, the functional concept can be summarized clearly.

Within Xiting Times, you configure:

Operation modes
Typical modes include Productive Test Simulation, Protected Go-Live and Extended Access Management (emergency access / firefighter scenarios).
Reference users and mappings
In Xiting Times, you assign reference users to productive users, start sessions and control when simulations or fallbacks are active.

Xiting refers to this as the “backpack principle”:
The reference user serves as a backpack for dialog users. Depending on the selected mode, Xiting Times is used to capture missing authorizations for the PTS or the PGL.

Jobs and trace collection
Background jobs collect authorization traces from productive sessions, store them centrally and prepare them for analysis in Role Builder and other XAMS modules.
Approval workflows and runtime controls
Depending on your governance requirements, you can define approvals, durations and conditions for PGL or extended access. This ensures that privileged access always remains transparent and audit-proof.

Where PTS and PGL deliver the most value

Organizations benefit most from PTS and PGL in scenarios with high complexity and high risk:

SAP role redesign projects
Instead of building a separate test landscape, you validate the new role concept directly in the productive system with PTS and then switch safely using Protected Go- Live.
SAP S/4HANA migrations
New processes, Fiori apps and authorization concepts bring additional uncertainty. XAMS uses Productive Test Simulation to analyze the real impact of changes and to shorten test cycles significantly.
Continuous improvement of authorizations
Even outside formal projects, PTS sessions can be used selectively to test changes in sensitive areas, identify over-authorized users and refine roles based on actual usage.

In all of these cases, SAP test automation becomes more than technical scripting. It turns into a continuous, data-driven feedback loop for your authorization concept.

Key benefits at a glance

Massive reduction in test effort for business users and IT by leveraging productive work as test input

Higher test quality thanks to realistic coverage of transactions, variants, and edge cases

Lower go-live risk through Protected GoLive and controlled fallbacks of old roles

Full auditability of simulations, emergency access, and fallback activations

Better governance with integrated approval workflows and clear separation of duties

Faster projects – Project experiences with XAMS show significant time savings in SAP authorization projects – Xiting reports reductions of up to 65% compared to purely manual approaches.

FAQ

What is SAP test automation in the context of authorizations?

In the authorization context, SAP test automation means that test cases for roles and permissions are no longer executed manually by users in a test system. Instead, tools like XAMS automate the evaluation of every authorization check in SAP during productive work. Productive Test Simulation (PTS) is the core mechanism for this automated, trace-based approach.

What exactly is Productive Test Simulation (PTS)?

Productive Test Simulation (PTS) is a unique form of authorization testing developed by Xiting. During a PTS session, users work in the productive system as usual, while their activities are evaluated against simulated roles in the background. Missing permissions are logged and analyzed without blocking the user. This allows organizations to identify and correct design issues in roles under real conditions and with minimal impact on operations.

How does PTS help in an SAP role redesign project?

In a SAP role redesign project, it is crucial to ensure that new roles support all relevant processes without introducing security risks. PTS lets you validate the new role concept directly in production: users continue their daily work while the system tracks which permissions are actually needed. Based on this, you refine role content and organizational levels before switching fully to the new concept. Combined with Protected GoLive, this approach significantly reduces project risk and accelerates timelines.

What is Protected Go-Live (PGL) and how does it work?

Protected GoLive is a concept where new roles are activated in production, but old roles remain available as temporary fallback. If a user encounters missing permissions, they can request or automatically trigger reactivation of their old roles for a limited time. All actions are fully logged. Administrators then analyze the missing authorizations, adjust the new roles, and gradually phase out the fallback. This minimizes the risk of process interruptions and increases end-user acceptance of the new authorization concept.

How does Xiting Times fit into SAP testing tools for authorizations?

Xiting Times is the operational backbone for PTS, Protected GoLive, and emergency access scenarios. It controls when simulations run, how reference users are mapped, how long fallback roles are active, and which approvals are required. Integration with the XAMS module Role Builder turns Xiting Times into a central cockpit for automated role testing and controlled privileged access.

Can PTS replace classic test systems completely?

PTS does not necessarily replace all test systems, but it significantly reduces the need for manual regression testing in QA environments when it comes to authorizations. Technical changes, custom development and integrations will still be validated in non-productive systems. For role design and authorization checks in SAP, however, PTS provides much more accurate and efficient feedback by using real productive behavior as the test input. Additionally, the described functionality in Xiting Times can also be used in QA environments for daily business test requirements.

How can I check roles in SAP more efficiently with XAMS?

Instead of manually running transaction by transaction to check roles in SAP, you use PTS sessions to collect detailed trace data in production. Role Builder processes this data, identifies missing authorizations, and helps optimize roles systematically. In addition, other XAMS components provide comprehensive analysis and reporting capabilities to continuously monitor the quality and risk profile of roles and authorizations.

Solutions

Xiting Authorizations Management Suite

XAMS supports companies in their security projects by automating costly and time-consuming tasks, improving compliance adherence, and significantly reducing the risk of errors.

Xiting Security Platform

Discover the key use cases of the Xiting Security Platform (XSP) that will revolutionize your SAP security management with comprehensive coverage, seamless integration, and advanced analytics.

Xiting Content Portal

The Xiting Content Portal (XCP) is a SaaS solution that provides a central SAP risk repository and a user interface for the straightforward creation and management of rule sets, supported by a collaborative community approach.

SAP Test Automation with Xiting

Why traditional SAP role testing no longer fits modern projects

Productive Test Simulation (PTS):
SAP test automation directly in productive landscape

How Productive Test Simulation (PTS) works in practice

Benefits of Productive Test Simulation as an SAP testing tool

Protected Go-Live (PGL):
Risk-free transition to a new authorization concept

How Protected Go-Live (PGL) works

Why Protected Go-Live (PGL) matters for SAP role redesign projects

Xiting Times: The control center for PTS, PGL and Emergency Access

Where PTS and PGL deliver the most value

Key benefits at a glance

FAQ

What is SAP test automation in the context of authorizations?

What exactly is Productive Test Simulation (PTS)?

How does PTS help in an SAP role redesign project?

What is Protected Go-Live (PGL) and how does it work?

How does Xiting Times fit into SAP testing tools for authorizations?

Can PTS replace classic test systems completely?

How can I check roles in SAP more efficiently with XAMS?

Solutions

More Solutions of Xiting

Xiting Authorizations Management Suite

Xiting Security Platform

Xiting Content Portal

Consulting

Newsletter

Resources

About Xiting

SAP Test Automation with Xiting

Why traditional SAP role testing no longer fits modern projects

Productive Test Simulation (PTS): SAP test automation directly in productive landscape

How Productive Test Simulation (PTS) works in practice

Benefits of Productive Test Simulation as an SAP testing tool

Protected Go-Live (PGL): Risk-free transition to a new authorization concept

How Protected Go-Live (PGL) works

Why Protected Go-Live (PGL) matters for SAP role redesign projects

Xiting Times: The control center for PTS, PGL and Emergency Access

Where PTS and PGL deliver the most value

Key benefits at a glance

FAQ

What is SAP test automation in the context of authorizations?

What exactly is Productive Test Simulation (PTS)?

How does PTS help in an SAP role redesign project?

What is Protected Go-Live (PGL) and how does it work?

How does Xiting Times fit into SAP testing tools for authorizations?

Can PTS replace classic test systems completely?

How can I check roles in SAP more efficiently with XAMS?

Solutions

More Solutions of Xiting

Xiting Authorizations Management Suite

Xiting Security Platform

Xiting Content Portal

Contact our experts

Melden Sie sich jetzt an!

Kontaktieren sie unsere experten

Productive Test Simulation (PTS):
SAP test automation directly in productive landscape

Protected Go-Live (PGL):
Risk-free transition to a new authorization concept