SAP Testautomatisierung mit Playwright 2026: UI5, Fiori

Wenn du SAP-Fiori-Apps testen willst, hattest du bisher zwei Optionen: Enterprise-Tools wie Tricentis Tosca mit Lizenzkosten im fünfstelligen Bereich, oder selbst gebauter Selenium-Code mit brittle XPath-Selektoren. 2025 ist eine dritte Option dazugekommen: Playwright mit speziellen UI5-Erweiterungen, die SAP-Controls über die UI5-Runtime ansprechen statt über DOM-Heuristik.

In diesem Artikel zeige ich dir die drei produktiv eingesetzten Playwright-SAP-Frameworks (playwright-sap, playwright-praman, playwright-ui5), wann jedes sinnvoll ist und wo die Grenzen liegen. Du bekommst Code aus echten Projekten, eine Tosca-Vergleichs-Matrix und einen Praxis-Case aus einem Mittelstands-S/4HANA-Rollout.

Zusätzlich klären wir den Compliance-Teil: Wenn dein Test-Code SAP-Mitarbeiterdaten anfasst, greift DSGVO. Wenn du KI-gestützte Locator-Heilung nutzt, kann der EU AI Act zuschlagen. Diese Sektion habe ich bewusst in Beratungs-Tonalität geschrieben, damit du sie an deine IT-Leitung weitergeben kannst.

Was ist SAP-Testautomatisierung und warum sie sich rechnet

SAP-Testautomatisierung beschreibt den Einsatz von Software-Werkzeugen, die SAP-Anwendungen wiederholbar und ohne menschliches Klicken testen. Statt dass fünf Power-User nach jedem Release drei Tage lang dieselben Bestell-, Buchungs- und Reklamations-Workflows manuell durchspielen, übernehmen automatisierte Test-Skripte diese Arbeit in Minuten. Das gilt für klassisches SAP ERP genauso wie für S/4HANA On-Premise, S/4HANA Cloud Private und S/4HANA Cloud Public.

Für Entscheider ist die Frage selten „ob", sondern „wann und wie". Vier konkrete Argumente machen Testautomatisierung in SAP-Landschaften 2026 zur strategischen Notwendigkeit:

1. Release-Geschwindigkeit: Viermal jährlich liefert SAP neue Cloud-Releases (Februar, Mai, August, November) mit Innovationen, aber auch mit Risiken. Nach jedem Update müssen Geschäftsprozesse erneut getestet werden, damit Bestellungen, Wareneingänge und Abrechnungen weiterhin sauber durchlaufen.
2. Manuelle Fehlerquoten: Wiederholte Klick-Tests durch Menschen werden bei der zehnten Iteration unzuverlässig. Schritte werden vergessen, Eingaben verwechselt, Edge-Cases nicht geprüft. Automatisierte Tests sind reproduzierbar und liefern dasselbe Ergebnis bei jedem Lauf.
3. Kritische Geschäftsprozesse: Bricht der Bestell-Workflow oder die Lieferantenanlage nach einem Release, kann die Logistik nicht abwickeln, der Cash-Flow leidet, Vertragsstrafen drohen. Automatisierte Regressions-Tests fangen solche Brüche im Test-Mandant ab, bevor sie produktive Auswirkungen haben.
4. Strategische Notwendigkeit, nicht Nice-to-have: Wer SAP Cloud nutzt, hat keine Kontrolle mehr über das Release-Tempo. Manuelle Test-Pakete skalieren nicht mit der Update-Frequenz mit. Die Investition in Test-Automatisierung amortisiert sich typischerweise nach drei bis vier Release-Zyklen.

In der Praxis sehen wir zwei Tool-Welten: Konzern-Setups mit Tricentis Tosca oder Worksoft Certify (kommerzielle Enterprise-Tools mit fünfstelligen Jahreslizenzen) und mittelständische S/4HANA-Cloud-Kunden, die mit Open-Source-Werkzeugen wie Playwright deutlich günstigere Setups aufbauen. Dieser Artikel zeigt, wann Playwright die richtige Wahl ist und wo Tosca weiterhin den Standard setzt. Vertiefung zur Enterprise-Sicht findest du im Tricentis-Tosca-Artikel.

Was SAP-Testautomatisierung 2026 anders macht

SAP-Testautomatisierung hat eine lange Tool-Geschichte. Bis etwa 2015 dominierten klassische SAP-GUI-Tester wie SAP eCATT, SAP TAO oder Tricentis Tosca mit speziellen GUI-Engines. Mit der Einführung von Fiori als HTML5-Frontend ab 2013 und der Cloud-Transformation zu S/4HANA Cloud Public 2018 hat sich die technische Basis fundamental geändert. SAP-Anwender öffnen heute ein Browser-Fenster, nicht mehr einen nativen GUI-Client.

Für die Testautomatisierung bedeutet das: Die alten Tool-Engines passen weiterhin, decken aber nur noch einen Teil der Realität ab. Tosca dominiert in Konzernen mit Mainframe-, Java-Swing- und WebGUI-Mischsystemen. Für mittelständische Unternehmen mit reinem S/4HANA-Cloud-Stack stellt sich die Frage neu, ob die fünfstellige Tool-Lizenz pro Jahr noch angemessen ist, wenn das eigentliche Test-Objekt ein Browser-Frontend ist.

Hier kommt Playwright ins Spiel. Microsoft hat das Open-Source-Framework 2019 veröffentlicht, seit 2025 gibt es spezialisierte UI5- und Fiori-Erweiterungen. Drei Frameworks haben sich produktiv etabliert: playwright-sap, playwright-praman und playwright-ui5. Sie alle adressieren das gleiche Kernproblem: SAP-Controls (Buttons, Inputs, Tables) sollen über die UI5-Runtime-Registry angesprochen werden, nicht über brittle XPath-Selektoren auf DOM-Ebene. Vertiefend zur Cluster-Einordnung findest du im Tricentis-Tosca-Artikel die Enterprise-Sicht.

Setup mit playwright-sap in 5 Minuten

Der schnellste Einstieg führt über das npm-Package playwright-sap (offizielle Quelle: playwright-sap.dev). Es ist MIT-lizenziert, vendor-frei und installiert sich in zwei Befehlen neben dem klassischen Playwright-Test-Runner.

# Voraussetzungen: Node.js 20+, npm 10+

# Installation
npm install --save-dev @playwright/test playwright-sap

# Initialisierung (legt playwright-sap.config.ts an)
npx playwright-sap init

# Browser-Binaries laden
npx playwright install --with-deps chromium

# Erster Test
npx playwright test

Der entscheidende Mehrwert gegenüber dem nackten Playwright steckt im Login-Helper. SAP-Backends sprechen ein eigenes Authentifizierungs-Protokoll mit CSRF-Token, SAML-SSO oder OAuth2-Flow gegen die SAP BTP. Playwright-SAP kapselt das in einer Fixture, die du pro Test als sapPage erhältst. Beispiel für einen Fiori-Launchpad-Test:

import { test, expect } from 'playwright-sap';

test('Fiori Launchpad öffnet sich', async ({ sapPage }) => {
  await sapPage.loginFiori({
    url: 'https://s4-staging.example.com/sap/bc/ui2/flp',
    user: process.env.SAP_USER!,
    password: process.env.SAP_PASS!,
  });
  await expect(sapPage.locator('ui5=sap.m.ShellHeader')).toBeVisible();
});

Wichtig: Die SAP-Credentials gehören nicht in den Code, sondern in eine .env-Datei (lokal) oder in GitHub-Secrets (CI/CD). Der Login-Helper holt das CSRF-Token automatisch beim Aufruf von /sap/bc/ui5_ui5/, hält die Session-Cookies bis zum Test-Ende und macht ein sauberes Logout über /saplogon.

UI5-Locators ohne brittle XPath

Das Kernproblem klassischer SAP-Tests sind die DOM-Selektoren. SAP UI5 generiert Element-IDs dynamisch über das Framework, beispielsweise __button42-inner. Bei jeder neuen UI5-Version oder jedem App-Transport verschieben sich diese IDs. Tests brechen. Jemand muss die Selektoren manuell nachziehen.

// ❌ Brittle (klassisches Playwright):
await page.click('//div[@id="__button42-inner"]/span');

// ✅ Resilient (playwright-sap mit ui5-Selector):
await sapPage.locator('ui5=sap.m.Button[text=Anlegen]').click();

// ✅ Noch resilienter (Praman mit Property-Match über UI5-Runtime):
await sapPage.ui5Control({ controlType: 'sap.m.Button', text: 'Anlegen' }).click();

Der Unterschied wirkt klein, ist aber strukturell groß. Der UI5-Locator spricht den Control über seinen semantischen Typ (sap.m.Button) und sichtbaren Text an. Ändert sich das DOM-Attribut intern, bleibt der Test grün. Ändert sich der Button-Label, fängt ihn ein KI-gestützter Heilungs-Loop ab (siehe Frameworks-Vergleich unten). Für Playwright-Grundlagen zur Locator-Strategie siehe das Playwright-Tutorial.

Fiori Launchpad: Tests gegen Cloud und On-Prem

SAP-Landschaften kommen 2026 in drei Varianten vor: S/4HANA Cloud Public (Subscription), S/4HANA Cloud Private (BYOL) und S/4HANA On-Premise. Alle drei sprechen denselben Fiori-Launchpad-Standard, unterscheiden sich aber im Authentifizierungs-Pfad und Netzwerk-Setup.

// S/4HANA Cloud Public (BTP-Auth via SAML-IdP)
await sapPage.loginCloud({
  identityProvider: 'https://accounts.sap.com/saml2/idp/...',
  user: process.env.BTP_USER!,
  // Passwort kommt aus Identity Authentication Service
});

// S/4HANA On-Premise über SAP Cloud Connector (SCC)
await sapPage.loginOnPrem({
  scc: 'https://scc.internal:8443',
  systemId: 'S4P',
  client: '100',
  user: process.env.SAP_USER!,
  password: process.env.SAP_PASS!,
});

Der SAP Cloud Connector wird zum kritischen Verbindungsstück, sobald die Test-Pipeline aus der Cloud (etwa GitHub Actions) gegen ein On-Prem-System läuft. Der Connector öffnet einen TLS-Tunnel, durch den der Playwright-Test die internen Fiori-URLs erreicht, ohne dass das SAP-System direkt ans Internet muss. Setup-Tiefe siehe SAP-eigene Dokumentation, Audit-Spuren landen in der SCC-Audit-Log.

3 Playwright-SAP-Frameworks im Vergleich

Aktuell sind drei Playwright-Erweiterungen für SAP produktiv im Einsatz. Sie überlappen funktional, setzen aber unterschiedliche Schwerpunkte. Die Wahl hängt davon ab, ob du WebGUI brauchst, ob du KI-Self-Healing willst und wie minimalistisch dein Setup sein soll.

Faustregel aus der Beratungs-Praxis: playwright-sap ist der erste Griff für Mischsysteme mit UI5 und WebGUI (etwa S/4HANA mit Legacy-Transaktionen). playwright-praman lohnt sich, wenn du eine reine Fiori-Landschaft hast und KI-getriebene Locator-Heilung einsetzen willst (analog Pattern Playwright MCP Server). playwright-ui5 ist minimaler und passt für kleine UI5-only-Projekte ohne KI-Anspruch.

Tosca vs. Playwright für SAP: Entscheidungs-Matrix

Die häufigste Frage in Beratungsgesprächen lautet: „Ersetzt Playwright bei uns Tosca?" Die Antwort hängt nicht vom Tool ab, sondern vom Stack. Die Matrix unten fasst die Entscheidungs-Achsen zusammen, die wir bei DBI, Versicherern und mittelständischen Logistikern gesehen haben.

In der Praxis schließen sich die Tools nicht aus. Wir sehen zunehmend Setups, in denen Tosca die kritischen End-to-End-Geschäftsprozesse abdeckt (Order-to-Cash, Procure-to-Pay) und Playwright die schnellen Frontend-Regressions-Tests pro Fiori-App übernimmt. Vorteil: Tosca-Lizenzkosten bleiben konstant statt mit Test-Anzahl zu steigen, Playwright-Tests laufen pro Pull-Request kostenlos in der CI/CD-Pipeline.

CI/CD mit GitHub Actions und SAP Cloud Connector

Eine produktive Pipeline für SAP-Playwright-Tests besteht aus drei Komponenten: einem Self-Hosted-Runner mit Tunnel zum SAP-System, einem GitHub-Secrets-Store für die SAP-Credentials und einem Workflow, der pro Pull-Request die Tests ausführt. Beispiel-Konfiguration:

# .github/workflows/sap-playwright-tests.yml
name: SAP Fiori Tests

on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1-5'  # Werktags 06:00 UTC nach SAP-Transport

jobs:
  test:
    runs-on: self-hosted  # Self-Hosted-Runner mit SCC-Tunnel
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - name: Run SAP Fiori tests
        env:
          SAP_USER: ${{ secrets.SAP_USER }}
          SAP_PASS: ${{ secrets.SAP_PASS }}
          SAP_BACKEND: https://s4.internal:8443
        run: npx playwright test --grep @sap
      - if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: playwright-trace
          path: test-results/
          retention-days: 14

Drei Patterns sind in unseren Mandaten gut angekommen: Erstens, der Self-Hosted-Runner läuft als Linux-VM in derselben Netzwerk-Zone wie der SAP-Cloud-Connector und übernimmt den Tunnel-Aufbau bei Start. Zweitens, der Test-Run startet automatisch nach jedem SAP-Transport (Cron-Schedule), nicht nur bei Frontend-Pull-Requests. Drittens, fehlschlagende Tests laden ihre Playwright-Trace-Files als GitHub-Action-Artifact hoch, damit die Testanalyse später ohne Re-Run möglich ist. Für tiefere CI/CD-Patterns siehe Playwright-Tutorial.

KI ersetzt keine Tester. Sie ersetzt Tester, die keine KI nutzen.

Praxis-Case: 18 Fiori-Tests in 14 Tagen

Ein mittelständischer Logistik-Kunde aus Süddeutschland (~500 Mitarbeiter, EBITDA-Mitte zweistelliger Bereich) hat 2026 sein klassisches SAP ERP auf S/4HANA Cloud Public migriert. Der Frontend-Stack: 18 produktive Fiori-Apps für Bestellung anlegen, Wareneingang buchen, Inventur-Korrektur, Reklamationsbearbeitung und Lieferantenstammpflege. Vorher: manuelle Regressions-Tests durch fünf Power-User, drei Personentage Aufwand pro Release-Zyklus, alle vier Wochen.

Wir haben mit dem Team in 14 Personentagen eine Playwright-Suite aufgesetzt. Stack: Playwright 1.60 plus playwright-sap als UI5-Wrapper, TypeScript als Test-Sprache, GitHub Actions Self-Hosted-Runner mit SAP-Cloud-Connector-Tunnel zur Public-Cloud. Test-Daten kamen aus einem dedizierten Test-Mandant mit anonymisierten Lieferanten-Stammsätzen (DSGVO-konform, kein Daten-Klon aus Prod).

Ergebnis nach drei Sprints: 18 vollautomatisierte Fiori-Tests, Time-to-Run 12 Minuten pro Pipeline-Lauf, Personentage pro Release-Zyklus auf 0,5 Tage reduziert (Test-Ergebnis-Review plus Failure-Triage). Lizenzkosten: 0 Euro, weil Open Source. Schulungs-Aufwand für das interne Test-Team: zwei Tage TypeScript-Basics, ein Tag playwright-sap-Workshop. Für Cluster-Vertiefung zu CI/CD-Setup siehe Playwright-Tutorial.

DSGVO und EU AI Act bei SAP-Test-Daten

Wenn Sie Playwright gegen Ihr produktives SAP-System fahren, müssen Sie drei Compliance-Dimensionen prüfen. Das ist keine Bürokratie, sondern eine konkrete Pflicht aus der DSGVO und seit August 2026 zusätzlich aus dem EU AI Act, sobald Sie KI-gestützte Test-Generierung einsetzen.

1. Test-Daten-Klassifizierung. Ein SAP-HR-Mandant enthält personenbezogene Daten im Sinne von DSGVO Art. 4 Nr. 1. Wenn Sie Tests gegen diesen Mandanten fahren, ohne die Daten zu anonymisieren, ist das eine Verarbeitung mit Rechtsgrundlage Art. 6 Abs. 1 lit. f (berechtigtes Interesse), die dokumentiert werden muss. Sauberer ist ein separater Test-Mandant mit synthetischen Stammdaten oder anonymisierten Klonen.
2. KI-Output-Transparenz. Wenn Sie playwright-praman oder einen anderen LLM-getriebenen Locator-Heilungs-Agent einsetzen, fällt der KI-Output unter EU AI Act Art. 50 (Transparenzpflichten). Test-Code, der durch KI generiert oder modifiziert wird, muss als solcher gekennzeichnet werden. Ein einfacher Code-Kommentar wie // AI-generated 2026-05-18, reviewed by Wilson reicht aus.
3. SAP-Audit-Pflicht. SAP-Anwender-Logs (Tabelle USR02, Log SM19/SM20) müssen erkennen können, dass eine Anmeldung von einem Test-Bot stammt, nicht von einem echten Anwender. Lösung: dedizierte Test-User-Accounts mit Präfix wie TEST_BOT_FIORI_01, kein generischer Tech-User.

Konkrete Maßnahmen, die Sie heute umsetzen können:

• Test-Mandant strikt von Produktion trennen, kein 1:1-Daten-Klon ohne Anonymisierungs-Schritt.
• Test-User-Accounts mit Präfix und Audit-Sticker im SAP-Auth-Log; pro Test-Suite ein eigener Account.
• Bei KI-Locator-Heilung den LLM-Provider mit EU-Rechenzentrum wählen (Azure OpenAI Region Westeurope, Anthropic über AWS Frankfurt) und einen Auftragsverarbeitungsvertrag prüfen.
• Test-Code in Code-Review behandeln wie Produktiv-Code; KI-Generierte Anteile durch Tester sichten und freigeben.
• Für die EU-AI-Act-Vertiefung mit Annex-III-Bezug siehe unseren KI-Pillar-Artikel.

Fazit: Wann Playwright Tosca ergänzt

Playwright mit UI5-Erweiterungen ist 2026 produktiv-reif für drei Szenarien: mittelständische Fiori-Stacks ohne Konzern-Lizenz-Budget, Frontend-Regressions-Tests in CI/CD-Pipelines neben Tosca-getriebenen Geschäftsprozess-Tests und Code-affine Test-Teams, die TypeScript statt Tosca-Designer bevorzugen. Nicht produktiv-reif für: 160+ Technologie-Coverage à la Großkonzern, regulatorisch verpflichtende No-Code-Test-Designer-Workflows und SAP-GUI-für-Windows-Tests (dort bleibt Tosca oder SAP CBTA der Standard).

Für 2026 und 2027 ist absehbar, dass die UI5-spezifischen Playwright-Erweiterungen weiter wachsen. Praman-ähnliche KI-Self-Healing-Modi werden zur Default-Erwartung, ein SAP-Cloud-MCP-Server analog Microsoft Playwright-MCP ist in der Community angekündigt, und Tosca-Side-by-Side-Strategien (Tosca für Geschäftsprozesse, Playwright für Frontend) werden sich als Best Practice durchsetzen.

Tests sind kein Add-on. Tests sind der Vertrag. Das gilt für Tosca genauso wie für Playwright: Was die Pipeline durchlässt, geht in Produktion.

Häufige Fragen zu SAP-Testautomatisierung mit Playwright (FAQ)

Kann ich Playwright statt Tosca für SAP einsetzen?

Ja, für Fiori- und UI5-basierte Apps. Für Mainframe-, Java-Swing- oder Legacy-WebGUI-Mischsysteme bleibt Tosca der Standard, weil playwright-sap dort nicht hinreicht. In Konzern-Setups laufen beide Tools meist parallel. Vertiefung im Tosca-Artikel.

Welches Playwright-SAP-Framework ist am Besten?

Default-Empfehlung: playwright-sap als breitester Wrapper für UI5 und WebGUI. Bei reinen Fiori-Stacks mit KI-Bedarf greift playwright-praman, bei minimalistischen UI5-only-Projekten reicht playwright-ui5. Detaillierte Matrix siehe Frameworks-Vergleich.

Funktioniert Playwright mit S/4HANA Cloud Public?

Ja. Der Login-Helper in playwright-sap unterstützt BTP-Auth über SAML-IdP und OAuth2-Flow. Hauptherausforderung in der Praxis sind die Custom-Rollen im Test-Mandant, weil die Standard-Rollen nicht alle Fiori-Apps freigeben. Setup-Dauer typisch ein bis zwei Tage.

Wie geht Playwright mit SAP-CSRF-Token um?

Das Framework playwright-sap holt das CSRF-Token automatisch beim Login über einen HEAD-Request auf /sap/bc/ui5_ui5/ mit Header X-CSRF-Token: Fetch. Bei eigenen Setups ohne playwright-sap musst du das Pattern manuell implementieren. Die Token-Lebensdauer entspricht der SAP-Session.

Was kostet Playwright im Vergleich zu Tosca?

Playwright und playwright-sap selbst kosten 0 USD (MIT-Lizenz). Reale Kosten entstehen für den Self-Hosted-Runner (eine Linux-VM, typisch 50-100 USD pro Monat) und für Test-Engineer-Zeit. Tosca Enterprise-Lizenz beginnt erfahrungsgemäß ab 50.000 USD pro Jahr für mittlere Konzern-Setups. Tiefer in Tosca vs. Playwright.

Kann ich SAP-GUI für Windows mit Playwright testen?

Nein. SAP-GUI für Windows ist eine Native-Anwendung ohne Browser-Frontend, Playwright steuert ausschließlich Web-Browser. Für SAP-GUI-Tests bleiben Tosca, SAP eCATT oder SAP CBTA die Standard-Werkzeuge. Eine Migration auf Fiori-Frontends ist mittelfristig der Ausweg.

Wie integriere ich Playwright in SAP Solution Manager?

Der Solution Manager bietet keine native REST-API für Test-Status-Imports. Das produktiv erprobte Pattern: Playwright schreibt JUnit-XML als Test-Output, ein Custom-Script lädt das Ergebnis über die ChaRM-OData-Schnittstelle in den Solution Manager. Alternative: Tricentis qTest mit Playwright-Adapter, allerdings kostenpflichtig.