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.

Inhaltsverzeichnis

Was ist SAP-Testautomatisierung und warum sie sich rechnet
Was SAP-Testautomatisierung 2026 anders macht
Setup mit playwright-sap in 5 Minuten
UI5-Locators ohne brittle XPath
Fiori Launchpad: Tests gegen Cloud und On-Prem
3 Playwright-SAP-Frameworks im Vergleich
Tosca vs. Playwright für SAP: Entscheidungs-Matrix
CI/CD mit GitHub Actions und SAP Cloud Connector
Praxis-Case: 18 Fiori-Tests in 14 Tagen
DSGVO und EU AI Act bei SAP-Test-Daten
Fazit: Wann Playwright Tosca ergänzt
Häufige Fragen zu SAP-Testautomatisierung mit Playwright (FAQ)

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:

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.
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.
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.
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.

Framework	playwright-sap	playwright-praman	playwright-ui5
Maintainer	ArpitSureka	mrkanitkar (AI-First)	DetachHead
npm-Package	playwright-sap	playwright-praman	playwright-ui5
UI5-Locator-Syntax	ui5=sap.m.Button[text=Anlegen]	ui5Control({...})	ui5=//sap.m.Button[ui5:property...]
WebGUI-Support (SAP GUI for HTML)	Ja	Nein (UI5-only)	Nein
S/4HANA Cloud Public	Ja	Ja	Ja
BTP Cloud Foundry	Ja	Ja	Ja
KI-Self-Healing	Nein	Ja (UI5-Runtime-Inspection)	Nein
Lizenz	MIT	MIT	MIT
Empfehlung	Breitester Default	UI5-only mit KI-Bedarf	Minimaler Footprint

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.

Kriterium	Tricentis Tosca	Playwright + UI5-Erweiterungen
Lizenzkosten	Enterprise-Lizenz (5-stellig pro Jahr aufwärts)	0 (MIT Open Source)
SAP-Tiefe	WebGUI + Fiori + Mainframe + 160+ Technologien	Web + Fiori (UI5)
SAP-zertifiziert	Ja, offizieller Cloud-ALM-Partner	Nein
Modell-basiert (No-Code)	Ja, Tosca-Designer	Nein, Code-First TypeScript
CI/CD-Integration	Tricentis qTest, eigene Test-Server	GitHub Actions, Jenkins, Azure DevOps nativ
Test-Engineer-Skill	Tosca-Zertifizierung 3-5 Tage	TypeScript-Kenntnisse
Time-to-First-Test	2-3 Wochen (inkl. Schulung)	1-2 Tage
Beste Use-Cases	Konzern, Multi-System-Mix, regulatorische Audit-Pflicht	Mittelstand, S/4HANA Cloud, OSS-Stack

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.

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.
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.
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.

Testautomatisierung Beratung

Sie möchten Ihre Testautomatisierung optimieren? Unsere Experten helfen Ihnen bei der Auswahl der richtigen Tools, Best Practices und CI/CD-Integration.

Jetzt anfragen