Ist ein Playwright-Versus-Robot-Framework-Vergleich sinnvoll?

Die Frage «Playwright oder Robot Framework?» stellt sich in fast jeder Tool-Evaluation. Die kurze Antwort: beide sind stark — für unterschiedliche Szenarien. Wer das falsche wählt, merkt es erst nach Monaten.

Zwei Frameworks, zwei Philosophien

Playwright ist ein Browser-Automatisierungstool von Microsoft. Schnell, zuverlässig, sehr gute Developer Experience. Geschrieben in TypeScript, optimiert für Web-Testing.

Robot Framework ist eine technologie-agnostische Orchestrierungsschicht. Der Kern kennt kein Testobjekt — alles läuft über austauschbare Libraries. Eine einzelne .robot-Datei kombiniert Browser, REST-API, Datenbank, SSH und CLI in einem Report.

Der Vergleich ist wie Rennwagen gegen Geländewagen. Beide fahren — auf unterschiedlichem Terrain.

Wo Playwright überlegen ist

Reines Web-Testing. Playwright ist schneller, die API kompakter, das Debugging direkter. Auto-Wait, Netzwerk-Interception, Multi-Browser-Unterstützung sind nativ ohne Plugins. Für Teams, die ausschliesslich Browser-basierte Anwendungen testen, ist Playwright die stärkere Wahl.

Developer-Teams ohne Nicht-Techniker. Playwright-Tests sind TypeScript oder JavaScript. Entwickler fühlen sich sofort zuhause. IDE-Support, Breakpoints, Debugging — alles Standard. Kein Abstraktionslayer dazwischen.

Performance bei grossen Suites. Robot Framework hat einen Parsing-Overhead von 30–40 % gegenüber direkter Python- oder pytest-Ausführung. Bei 10’000+ Tests in einer CI/CD-Pipeline summiert sich das zu Stunden.

Wo Robot Framework überlegen ist

Heterogene Technologielandschaften

Ein typischer Enterprise-Testflow sieht so aus: Browser-Login → REST-API-Call → Datenbank-Assertion → SSH-Logfile-Check → SOAP-Service-Validierung. Fünf Technologien in einem Test.

Für jeden Schritt liefert Robot Framework eine fertige, community-gepflegte Library:

Technologie	Robot Framework	Playwright
Browser / GUI	Browser Library (basiert auf Playwright)	nativ
REST APIs	RequestsLibrary	APIRequestContext
SOAP APIs	SoapLibrary, ZeepLibrary	kein Support
Datenbank	DatabaseLibrary (Multi-DB)	externes Paket nötig
SSH	SSHLibrary (paramiko)	kein Support
CLI / Dateisystem	Process, OperatingSystem	kein Support

Die Browser Library von Robot Framework nutzt Playwright unter der Haube. Die Konsequenz: Playwrights Browser-Engine plus die Fähigkeit, im selben Test gegen Datenbanken, APIs und SSH-Server zu testen.

Cypress — die andere häufig genannte Alternative — formuliert in der eigenen Dokumentation: «Cypress is not a general purpose automation tool.»

Mixed-Skill-Teams

In vielen Organisationen schreiben nicht nur Entwickler Tests. Product Owner reviewen Szenarien. Fachtester definieren Testfälle. Auditoren prüfen Testabdeckung.

Robot-Framework-Tests können so aussehen:

Bestellung mit Rabattcode abschliessen
    Öffne Produktseite    Laptop X1
    Lege Produkt In Warenkorb
    Gebe Rabattcode Ein    SOMMER2025
    Schliesse Bestellung Ab
    Prüfe Bestellbestätigung    Rabatt 10%

Ein Product Owner versteht diesen Test. Ein Playwright-Test in TypeScript nicht.

Voraussetzung: Das technische Team hat vorab eine Keyword-Library aufgebaut. Das braucht 3–6 Monate fokussierte Arbeit. Danach können Fachtester mit technischer Grundbildung eigene Szenarien schreiben — und alle Stakeholder können Tests lesen und bewerten.

Regulierte Branchen

FINMA, DORA, GxP verlangen Nachvollziehbarkeit. Robot Framework liefert drei Artefakte pro Testlauf:

output.xml — maschinenlesbar, archivierbar, auditierbar
report.html — Zusammenfassung mit Tag-Statistiken
log.html — Keyword-Execution-Traces mit Timestamps

Tests sind Plain-Text-Dateien, versioniert in Git. Jede Änderung ist nachvollziehbar. Tags wie [Tags] REQ-001 RISK-HIGH verknüpfen Tests direkt mit Anforderungen.

ISO/IEC/IEEE 29119-5:2024 hat Keyword-Driven Testing als internationalen Standard formalisiert. Robot Frameworks keyword-getriebene Architektur deckt sich strukturell mit dem in 29119-5 beschriebenen Modell — eine de-facto-Umsetzung, ohne dass die Robot Framework Foundation einen formellen Konformitäts-Claim erhebt. Kein anderes Framework referenziert diese Konformität.

KONE, OP Financial Group und Signant Health setzen Robot Framework in regulierten Umgebungen produktiv ein.

Thin-Layer-Architektur — das Beste aus beiden Welten

Der grösste Irrtum bei Robot Framework: alles in der RF-eigenen Syntax schreiben. Die effektivere Architektur trennt zwei Schichten:

Schicht	Verantwortung	Sprache
Testfall-Ebene	Szenarien, Lesbarkeit, Routing	Robot Framework (`.robot`)
Keyword-Libraries	Logik, Assertions, Integrationen	Python

Jede Python-Funktion wird automatisch ein RF-Keyword. Die gesamte Logik liegt in Python. Voller IDE-Support, Standard-Debugging, das grösste Paket-Ökosystem am Markt.

Falls sich die Anforderungen ändern: Python-Libraries sind framework-agnostisch. Eine Migration zu pytest ist jederzeit möglich, ohne die Testlogik neu zu schreiben.

Entscheidungsmatrix

Szenario	Empfehlung
Nur Browser-Testing, Developer-Team	Playwright
Nur API-, Integration- oder Unit-Tests	pytest direkt
Drei und mehr Technologien in einem Testflow	Robot Framework
Fachtester oder Auditoren lesen Tests	Robot Framework
Regulierte Branche mit Audit-Anforderungen	Robot Framework
10’000+ Tests, Speed ist CI/CD-kritisch	pytest oder Playwright

Viele Enterprise-Teams nutzen beide: Robot Framework für Acceptance- und End-to-End-Tests (Lesbarkeit, Multi-Tech, Reporting), Playwright oder pytest für schnelle Unit- und Integrationstests.

Drei Fragen für die Evaluation

Wie viele verschiedene Technologien müssen die Tests in einem Testflow abdecken?
Gibt es Stakeholder ausserhalb der Entwicklung, die Tests lesen oder reviewen müssen?
Unterliegt die Organisation regulatorischen Anforderungen an die Testdokumentation?

Bei mindestens einer Ja-Antwort verdient Robot Framework einen genaueren Blick — nicht als Ersatz für Playwright, sondern als Ergänzung auf einer anderen Ebene.