SAP Testautomatisierung:
Automatisiertes Testen direkt im Produktivsystem
SAP Testautomatisierung und moderne SAP Testing Tools sind essenziell, um Geschäftsprozesse zu validieren – doch häufig scheitern sie an der Genauigkeit von Berechtigungen. Die meisten Tools für automatisierte SAP Tests prüfen lediglich, ob ein Workflow von Anfang bis Ende durchläuft – sie spiegeln jedoch selten wider, wie sich Rollen und Berechtigungen unter echten produktiven Bedingungen verhalten. Dadurch kann eine Berechtigungsprüfung im SAP Testsystem erfolgreich sein, während dieselbe Aktivität im Produktivsystem fehlschlägt – oder überberechtigt ist.
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.
Xiting schließt diese Lücke durch eine Kombination aus SAP Testing, der Nutzung von produktiven Daten und der Automatisierung dieser Tests. Die Produktive Test Simulation (PTS) von Xiting bewertet neue und überarbeitete Rollen mit echten produktiven Szenarien, ohne Benutzer oder Prozesse zu unterbrechen – und reduziert somit den manuellen Aufwand bei der Prüfung von Rollen in SAP drastisch. In Kombination mit einem kontrollierten Deployment Ansatz wie dem Protected Go Live (PGL) von Xiting erhalten Unternehmen einen stabilen, planbaren Weg für jedes SAP Rollenredesignprojekt – unterstützt durch SAP Testing Tools, statt durch Tabellen und Annahmen.
Warum traditionelles SAP Rollentesting nicht mehr zu modernen Projekten passt
In vielen Unternehmen sieht das SAP Testing für Rollen noch sehr traditionell aus. Neue Rollen werden im Entwicklungssystem erstellt, in ein QA System transportiert und dann an Fachanwender übergeben, die man bittet, ihre täglichen Aufgaben durchzuklicken. Ziel ist es zu bestätigen, dass Kernprozesse weiterhin funktionieren und jede wichtige Berechtigungsprüfung im SAP Testsystem erfolgreich ist.
Aus Security-Perspektive hat dieser Ansatz klare Grenzen:
- Testfälle sind oft unvollständig, und die tatsächliche Arbeitsweise der User in der Produktion unterscheidet sich stark von einem geskripteten Test.
- So kann eine Berechtigungsprüfung im QA bestehen, aber im Produktivsystem scheitern – oder umgekehrt: Ein Benutzer erhält mehr Zugriff als vorgesehen, weil niemand alle Kombinationsmöglichkeiten von Rollen und Organisationsobjekten testet.
Gleichzeitig stehen Projektteams unter Zeitdruck. Wenn ein SAP Rollenredesignprojekt parallel zu anderen Initiativen läuft, bleibt kaum Platz für wiederholte manuelle Testzyklen. Security und Compliance Teams müssen dennoch regelmäßig Rollen in SAP prüfen, jede kritische Berechtigungsprüfung für sensible Transaktionen ausführen und dies dokumentieren. Ohne passende SAP Testing Tools entstehen lange Testphasen, überlastete Key User und ein wachsender Rückstau offener Findings.
Was fehlt, ist eine Möglichkeit, SAP Testautomatisierung mit realer produktiver Nutzung zu verbinden. Anstatt Benutzer künstliche Tests wiederholen zu lassen, benötigen Organisationen eine kontrollierte Methode, um reale Arbeit automatisch zu protokollieren – inklusive jeder relevanten Berechtigungsprüfung. Genau diese Lücke schließen die PTS und der PGL.
Produktive Test Simulation (PTS):
SAP Testautomatisierung direkt im Produktivsystem
Die Produktive Test Simulation (PTS) ist das zentrale Konzept, das SAP Testing im Produktivsystem ermöglicht – ohne das Risiko, den Betrieb zu beeinträchtigen. Statt Benutzer in einem separaten System testen zu lassen, arbeiten Sie weiter wie gewohnt im Produktivsystem, während Rollen und Berechtigungsprüfungen im Hintergrund simuliert und protokolliert werden.
Aus technischer Sicht fungiert die PTS wie ein SAP Testing Tool direkt im Produktivsystem. Neue oder überarbeitete Rollen werden in der XAMS vorbereitet und Referenzbenutzern zugewiesen. Sobald eine PTS Session startet, werden diese Referenzbenutzer den jeweiligen Dialogbenutzern zugeordnet. Fehlende Berechtigungen werden nur für die Referenzbenutzer dokumentiert – die produktiven Benutzer behalten ihre alten Rollen und arbeiten ohne Unterbrechung weiter.
- Für Projektteams wird die PTS damit zu einem gezielten Werkzeug für SAP Testautomatisierung im Berechtigungsumfeld. Es erfasst exakt, wie Benutzer in der Produktion arbeiten – inklusive Varianten und selten genutzter Funktionen, die in klassischen Tests nicht abgedeckt sind.
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.
Jeder Klick während einer PTS Session wird Teil des automatisierten Testsets. Im Vergleich zu manuellen Tests spart dieser Ansatz enormen Aufwand und liefert deutlich präzisere Erkenntnisse, wo Rollen angepasst oder Zugriffe eingeschränkt werden müssen.
Weil die PTS in der Produktion läuft, erreicht es eine Genauigkeit, die generische Tools für automatisierte SAP Tests nicht leisten können. Traditionelle SAP Testing Tools prüfen Rollen, spiegeln jedoch selten das endgültige produktive Berechtigungskonzept wider.
Die PTS hingegen erfasst jeden Berechtigungsprüfschritt gegen simulierte Rollen und überführt die Daten in die XAMS zur Analyse und Optimierung.
Für Organisationen, die ein großes SAP Rollendesignprojekt planen, wird die PTS damit zum zentralen Werkzeug der SAP Testautomatisierung, um das neue Rollenkonzept vor einem risikoreichen Go Live zu validieren.
Wie die Produktive Test Simulation (PTS) in der Praxis funktioniert
Die Einrichtung der Produktiven Test Simulation (PTS) folgt einem klaren Ablauf, der SAP Testautomatisierung direkt in das Produktivsystem bringt und jeden relevante Berechtigungsprüfung erfasst.
- Design neuer Rollen
Neue oder überarbeitete Rollen werden in der XAMS erstellt, z. B. mit dem Role Designer, und nach dem Least -Privilege-Prinzip vorbereitet. - Vorbereitung von Referenzbenutzern und Xiting Times
In Xiting Times werden Referenzbenutzer eingerichtet, die das neue Rollenkonzept abbilden. Das System wird für den PTS Modus vorbereitet, inklusive RFC Verbindungen, Hintergrundjobs (z. B. Collector Jobs) und grundlegender Customizing Schritte. → Schauen Sie sich hier an wie sie Xiting Times vor der PTS Session konfigurieren
- Start einer PTS Session
Ein produktiver Benutzer erhält im Hintergrund für mehrere Wochen einen Referenzbenutzer zugeordnet. An der Oberfläche bleibt alles unverändert: alte Rollen, gewohnte Transaktionen wie FB03, MM03 oder individuelle Prozessvarianten. - Simulation von Berechtigungsprüfungen
Jede Berechtigungsprüfung wird gegen die simulierten Rollen geprüft. Fehlende Berechtigungen werden in einer dedizierten Xiting Tabelle dokumentiert und anschließend im Role Builder analysiert. - Rollenoptimierung auf Basis realer Nutzung
Administratoren nutzen die Simulationsergebnisse, um Rollen, Organisationswerte und SU24-Vorschläge anzupassen. Block und Allow Lists helfen, kritische und notwendige Berechtigungen gezielt zu identifizieren.
Währenddessen bleibt das Produktivsystem stabil: Fehlende Berechtigungen im neuen Rollenkonzept blockieren den Benutzer nicht, da die Simulation im Hintergrund läuft. Die sonst üblichen manuellen Testzyklen werden durch einen automatisierte, trace basierte Feedback Loop ersetzt.
Vorteile der Produktiven Test Simulation als SAP Testing Tool
Mit der PTS rückt die SAP Testautomatisierung für Rollen näher an moderne Applikationstestmethoden heran:
- Keine Prozessunterbrechung: Tests laufen parallel zum Produktivsystem, neue Rollen werden im Hintergrund automatisch getestet.
- Realistische Abdeckung: Tests basieren auf echter Arbeit, nicht auf künstlichen Szenarien.
- Weniger Testaufwand: Fachbereiche müssen keine eigenen Tests planen – die tägliche Arbeit erzeugt alle Testdaten.
- Höhere Präzision: Strukturierte Simulationsdaten fließen direkt in SU24-Vorschlagswerte ein.
- Mehr Kontrolle und Compliance: Block /Whitelist Funktionen stellen sicher, dass kritische Aktivitäten gezielt verwaltet werden.
Protected Go-Live (PGL):
Risikofreier Übergang zu einem neuen Berechtigungskonzept
Selbst mit einer hervorragenden Testautomatisierung ist der Moment der Wahrheit immer noch der Go-Live. Gerade bei einem Projekt zur Neugestaltung der SAP-Berechtigungen ist das größte Risiko einfach: Ein Nutzer kann plötzlich seine Arbeit nicht mehr ausführen, weil eine Berechtigung fehlt.
Dieses Risiko führt oft zu „sicheren“, aber gefährlichen Entscheidungen – wie etwa der Überautorisierung von Nutzern oder der Aufschiebung notwendiger Änderungen.
→ Der Protected Go-Live (PGL) ist Xitings Antwort auf dieses 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!
Wie der Protected Go Live (PGL) funktioniert
Während eines PGL wird das neue Rollenkonzept aktiviert, die alten Rollen bleiben jedoch als kontrolliertes Fallback bestehen:
- Benutzer erhalten wie geplant ihre neuen Rollen
- Alte Rollen bleiben im Hintergrund als „Backup“ über Referenzbenutzer verfügbar
- Bei fehlenden Berechtigungen können Benutzer ihre alten Rollen zeitlich begrenzt (z. B. für 8 Stunden) wiederherstellen
- Jede Nutzung des Fallbacks wird vollständig protokolliert
- Administratoren analysieren die Fälle, verbessern die neuen Rollen und reduzieren Schritt für Schritt den Fallback
Sobald das Rollenkonzept stabil ist, werden alte Rollen strukturiert und dokumentiert entfernt.
Warum ein PGL für SAP Rollenredesignprojekte entscheidend ist
Der Protected Go-Live (PGL) eliminiert zentrale Risiken:
- Produktionsausfälle durch fehlende Berechtigungen
- Überlastung des Supports durch spontane Berechtigungsanforderungen
- Geringe Akzeptanz der Endanwender, die sich als Tester fühlen würden
Mit dem PGL prüfen Unternehmen Rollen unter echten produktiven Bedingungen – und haben dennoch eine sichere Rückfallebene.
Xiting Times: Die Steuerzentrale für PTS, PGL und Notfallzugriffe
Die PTS und der PGL werden über das Modul Xiting Times innerhalb der XAMS gesteuert.
Xiting Times ermöglicht:
- Betriebsmodi
– PTS, PGL und Extended Access Management für Notfallzugriffe - Referenzbenutzer & Zuordnungen
– Zuordnung von Referenzbenutzern zu produktiven Benutzern, Start von Sessions, Steuerung aktiver Modi
– „Backpack Prinzip“: Der Referenzbenutzer wird wie ein Rucksack an den Dialogbenutzer „angehängt“.
-
Jobs & Trace Sammlung
Sammeln und Aufbereiten von Berechtigungstraces für den Role Builder -
Genehmigungsworkflows
Definition von Regeln, Laufzeiten und Bedingungen für PGL und Notfallzugriffe
Wo die PTS und der PGL den größten Mehrwert liefern
Typische Einsatzszenarien:
- SAP Rollenredesignprojekte
– Validierung im Produktivsystem + sicherer Go Live - SAP S/4HANA Migrationen
– Analyse realer Auswirkungen und stark verkürzte Testzyklen - Kontinuierliche Berechtigungsoptimierung
– Gezielte Analysen in sensiblen Bereichen
SAP Testautomatisierung wird so zu einem kontinuierlichen, datengetriebenen Feedback System
Key Benefits auf einen Blick
Massive Reduzierung des Testaufwands
Bessere Governance und SoD‑Transparenz
Höhere Testqualität durch realistische Abdeckung
Vollständige Auditierbarkeit
Geringeres Go-Live Risiko dank des PGL
Schnellere Projekte – bis zu 65 % Zeitersparnis möglich
FAQ
Was ist SAP Testautomatisierung im Berechtigungskontext?
SAP Testautomatisierung bedeutet, dass Berechtigungstests nicht mehr manuell im Testsystem ausgeführt werden. Tools wie die XAMS automatisieren die Auswertung jeder Berechtigungsprüfung im SAP-Produktivsystem. Die PTS bildet dabei die Basis für diesen trace-basierten Ansatz.
Was genau ist Produktive Test Simulation (PTS)?
Die PTS ist eine von Xiting entwickelte Testmethode, bei der Benutzer wie gewohnt im Produktivsystem arbeiten, während ihre Aktionen im Hintergrund gegen simulierte Rollen geprüft werden – ohne sie zu blockieren.
Wie unterstützt die PTS ein SAP-Rollenredesignprojekt?
Die PTS ermöglicht die Validierung neuer Rollen direkt in der Produktion. Das neue Rollenkonzept wird anhand realer Nutzungsdaten optimiert. In Kombination mit dem PGL sinken Risiken und Projektlaufzeiten erheblich.
Was ist der Protected Go-Live (PGL) und wie funktioniert dieser?
Neue Rollen werden produktiv geschaltet, alte bleiben als Fallback verfügbar. Fehlende Berechtigungen können temporär aus alten Rollen bezogen werden. Alles wird transparent protokolliert.
Wie fügt sich Xiting Times in SAP Testing Tools ein?
Xiting Times steuert die PTS, den PGL und Notfallzugriffe, verwaltet Referenzbenutzer und steuert Berechtigungs-Sessions. Die Integration mit dem Role Builder ermöglicht eine vollständige automatisierte Berechtigungsanalyse.
Kann die PTS klassische Testsysteme vollständig ersetzen?
Nein – technische Anpassungen müssen weiterhin im Testsystem geprüft werden. Für Berechtigungstests liefert PTS jedoch deutlich präzisere und schnellere Ergebnisse.
Wie kann ich Rollen in SAP effizienter prüfen?
Durch PTS-Sessions im Produktivsystem werden detaillierte Trace-Daten gesammelt, die im Role Builder analysiert und zur Rollenanpassung genutzt werden können.
Weitere Xiting Tools für Ihr SAP-System
Xiting Authorizations Management Suite
Die XAMS unterstützt Unternehmen in ihren Security-Projekten, indem sie kosten- und zeitintensive Aufgaben automatisiert, die Einhaltung von Compliance-Vorgaben verbessert und das Fehlerrisiko deutlich reduziert.
Xiting Security Platform
Entdecken Sie die wichtigsten Anwendungsfälle der Xiting Security Platform (XSP), die Ihr SAP-Sicherheitsmanagement mit umfassender Abdeckung, nahtloser Integration und fortschrittlicher Analyse grundlegend verändern wird.
Xiting Content Portal
> Das Xiting Content Portal (XCP) ist eine SaaS-Lösung, die ein zentrales SAP-Risk-Repository und eine benutzerfreundliche Oberfläche zur einfachen Erstellung und Verwaltung von Regelwerken bietet – unterstützt durch einen kollaborativen Community-Ansatz.