Selenium und Playwright lösen dieselbe Aufgabe auf zwei sehr unterschiedliche Arten. Selenium ist ein quelloffenes Browser-Automatisierungs-Framework, das Browser über das W3C-WebDriver-Protokoll aus einem separaten Prozess ansteuert, ein offener Standard seit 2018. Playwright ist ein von Microsoft im Januar 2020 vorgestelltes Automatisierungs-Framework, das eine dauerhafte, CDP-nahe Verbindung mit eingebautem Auto-Wait nutzt. Für QA-Teams in Banken und regulierten Firmen entscheidet weniger die reine Geschwindigkeit als die Frage nach Standard, Wartungsaufwand und Portabilität. Dieser Vergleich ordnet beide Werkzeuge anhand nachprüfbarer Fakten ein und sagt, wann welches passt.

Kurz gefasst: Playwright gewinnt bei Stabilität und Entwicklerkomfort dank Auto-Wait und mitgeliefertem Test-Runner. Selenium punktet mit dem vendor-neutralen W3C-WebDriver-Standard (offizielle Empfehlung seit 5. Juni 2018) und fünf Sprachbindungen inklusive Ruby. Für neue Web-Projekte startet man meist mit Playwright, für Portabilität und Legacy-Bestände bleibt Selenium relevant.

Abbildung 1: Selenium out-of-process (W3C WebDriver) vs. Playwright mit persistenter CDP-naher Verbindung.

Schnellvergleich

Abbildung 2: Selenium vs. Playwright im direkten Vergleich über fünf Kernkriterien.

Selenium und Playwright unterscheiden sich in fast jedem technischen Kernpunkt. Selenium 4.44.0 (veröffentlicht am 12. Mai 2026) baut auf dem W3C-WebDriver-Standard auf; Playwright 1.61 liefert Auto-Wait, einen eigenen Runner und native Netzwerk-Interception (Selenium Downloads, 2026; Playwright Release Notes, 2026). Die folgende Tabelle fasst die Unterschiede zusammen.

Wie unterscheidet sich die Architektur?

Selenium und Playwright unterscheiden sich architektonisch grundlegend. Selenium steuert Browser aus einem separaten Prozess über das W3C-WebDriver-Wire-Protokoll, offizielle W3C-Empfehlung seit 5. Juni 2018 (W3C WebDriver, 2018). Laut der Spezifikation ist WebDriver „a remote control interface that enables introspection and control of user agents”. Playwright hält dagegen eine dauerhafte, aus dem Chrome DevTools Protocol abgeleitete Verbindung und regelt Netzwerkverkehr nativ (Playwright Release Notes, 2026).

Selenium 4 hat das alte JSON-Wire-Protokoll durch das standardisierte W3C-WebDriver-Protokoll ersetzt. Tests sprechen jetzt direkt mit dem Browser, ohne zusätzliche Encode- und Decode-Schritte (Selenium Docs, 2026).

Playwrights Modell erlaubt native Netzwerk-Interception und Request-Mocking von Haus aus. Selenium schliesst diese Lücke mit WebDriver BiDi, das bidirektionale Funktionen wie Netzwerk-Interception und Konsolenmitschnitt bringt. Die BiDi-Umsetzung ist noch im Übergang: das Projekt migriert seine Implementierung von WebDriver Classic zu BiDi, High-Level-APIs sind für Selenium 5 geplant (Selenium BiDi Docs, 2026).

Warum ist Playwright stabiler beim Auto-Wait?

Abbildung 3: Flaky Tests kosten laut ICST-2024-Fallstudie rund 2,5 % der produktiven Entwicklerzeit.

Playwright ist beim Auto-Wait stabiler, weil es standardmässig auf Elemente und deren Aktionierbarkeit wartet, bevor es klickt oder tippt. Selenium hat kein eingebautes Auto-Wait: Teams müssen explizite oder implizite Waits selbst codieren, eine der Hauptquellen für Flakiness (Playwright Release Notes, 2026; Selenium Docs, 2026).

Flaky Tests kosten messbar Zeit. Eine industrielle Fallstudie auf der ICST 2024 fand, dass der Umgang mit Flaky Tests mindestens rund 2,5 % der produktiven Entwicklerzeit bindet, aufgeteilt in Untersuchung, Reparatur und Tooling (ICST 2024, 2024). Wer diese Zeit senken will, verschiebt Wartelogik idealerweise aus dem eigenen Code ins Werkzeug.

In der Praxis heisst das: Selenium-Suites brauchen Disziplin bei den Waits, sonst brechen sie unter Timing-Schwankungen. Wie Sie diese Sprödigkeit ohne kompletten Umbau senken, zeigt unser Beitrag zu Self-Healing-Locators und Testwartung.

Welches Tool deckt mehr Browser und Sprachen ab?

Selenium deckt mit fünf offiziellen Sprachbindungen mehr Sprachen ab als Playwright mit vier, während beide dieselben drei Browser-Engines unterstützen. Selenium bietet Java, Python, C#, Ruby und JavaScript, alle auf Version 4.44.0. Playwright bietet vier Bindungen: JavaScript/TypeScript, Python, Java und .NET (Selenium Downloads, 2026; Playwright Release Notes, 2026).

Der Unterschied bei Ruby ist konkret. Wer eine bestehende Ruby-Testbasis pflegt, findet nur bei Selenium eine offizielle Bindung. Playwrights vier Bindungen kommen dafür alle aus einer Hand, von Microsoft gepflegt, was die Konsistenz über Sprachen hinweg erhöht.

Bei den Browsern testen beide Chromium, Firefox und WebKit. Playwright bündelt passende Browser-Builds mit jeder Version (aktuell Chromium 149, Firefox 151, WebKit 26.5). Selenium setzt auf installierte Browser plus passende Treiber (Playwright Release Notes, 2026). Für die Abgrenzung von Playwright gegen einen weiteren beliebten Kandidaten lohnt der Vergleich Playwright vs. Cypress.

Was macht Playwright in CI schneller?

Playwright ist in CI schneller, weil seine dauerhafte, CDP-nahe Verbindung und eingebaute Parallel-Worker In-Context-Operationen ohne den Overhead separater Wire-Protokoll-Roundtrips erlauben (Playwright Release Notes, 2026; W3C WebDriver, 2018). Konkrete Prozentangaben zum Tempo lassen wir bewusst weg.

Kursierende „Playwright ist X % schneller”-Zahlen stammen fast immer aus Vendor-Blogs oder Einzel-Benchmarks mit undokumentierter Methodik. Ohne reproduzierbares Vorgehen nennen wir keinen Faktor. Der belastbare Punkt ist struktureller Natur: Out-of-Process-Steuerung plus freie Parallel-Worker.

Selenium skaliert Parallelität über Selenium Grid, das Tests über mehrere Maschinen und Browser verteilt und aktiv gepflegt wird (Selenium Blog: Grid 4.41, 2026). Playwright bringt Parallel-Worker ohne Zusatzkomponente mit. In CI-Pipelines bedeutet das für Playwright weniger Infrastruktur-Setup, für Selenium mehr Kontrolle über verteilte Grids.

Wie senkt man Wartung und Flaky Tests?

Wartung und Flaky Tests senkt man, indem man Wartelogik aus dem Testcode ins Werkzeug verschiebt und Locators automatisch an UI-Änderungen anpasst. Der wunde Punkt jeder grossen Selenium-Suite liegt im Modell: manuell codierte Waits und Locators, die bei jeder UI-Änderung brechen. Playwright reduziert einen Teil davon über Auto-Wait und stabilere Selektoren, löst aber nicht das Grundproblem sich ändernder Oberflächen (Playwright Release Notes, 2026).

Selbstheilende Locators gehen einen Schritt weiter: erkennt das Werkzeug ein verschobenes oder umbenanntes Element, passt es die Referenz an, statt den Test scheitern zu lassen. In Kundenprojekten mit dem Selenium Toolkit sah selementrix rund 80 % weniger Wartungsaufwand, als Beratungserfahrung, nicht als Produkt-Benchmark.

Autemos ist eine KI-gestützte Testautomatisierungs-Plattform, die bestehende Selenium- und Playwright-Tests importiert und selbstheilende Locators mit eigener Stabilitätslogik zuerst ergänzt, ein LLM nur als Fallback. Jede Heilung ist dokumentiert, prüfbar und umkehrbar, kein Blackbox-Automatismus. Details zur Mechanik erklärt die Feature-Seite Self-Healing. Autemos ist dabei eine Option von mehreren, kein Ersatz für die Wahl des Frameworks.

Standard vs. Vendor: was zählt für regulierte Teams?

Für regulierte Teams zählt vor allem, dass Selenium/WebDriver ein vendor-neutraler W3C-Standard ist, während Playwright eine Single-Vendor-Toolchain von Microsoft bleibt. Selenium/WebDriver entstand in einem Community-Projekt unter dem Dach der Software Freedom Conservancy. Laut der Software Freedom Conservancy gilt: „Selenium’s WebDriver has become a World Wide Web Consortium recommendation” (W3C WebDriver, 2018).

Der Standard-Status hat praktische Folgen. WebDriver-Tests laufen portabel über verschiedene Grids und Cloud-Anbieter, ohne an einen einzelnen Hersteller gebunden zu sein. Für DACH-Banken, die vendor-neutrale Standards gegenüber Lock-in bevorzugen, ist das ein belastbares Argument.

Playwrights Single-Vendor-Modell bringt Konsistenz und schnelle Feature-Entwicklung, koppelt die Roadmap aber an einen Anbieter. Wer regulierte Systeme auditierbar testen muss, etwa unter DORA ab 17. Januar 2025, wägt diese Portabilität bewusst ab. Autemos exportiert echten Playwright- und Appium-Code, sodass Tests ausserhalb der Plattform laufen und kein Lock-in entsteht. Mehr zur Framework-Wahl im Überblick der Testautomatisierungs-Tools im Vergleich 2026.

Wann Selenium, wann Playwright?

Abbildung 4: Wann Selenium, wann Playwright? Entscheidungshilfe nach Bestand und Anforderungen.

Die Wahl hängt von Bestand, Team und Governance-Anforderungen ab. Selenium bleibt die vernünftige Wahl bei bestehenden WebDriver-Suiten, Ruby-Codebasen und wenn der W3C-Standard aus Compliance-Gründen Pflicht ist. Playwright passt für neue Web-Projekte, die Stabilität und schnellen Start priorisieren.

• Wählen Sie Selenium, wenn eine grosse WebDriver-Testbasis existiert und ein Umbau teurer wäre als die Pflege.

• Wählen Sie Selenium, wenn Sie Ruby nutzen oder den vendor-neutralen W3C-Standard aus Audit-Gründen brauchen.

• Wählen Sie Selenium, wenn Portabilität über Grids und Cloud-Anbieter Vorrang hat.

• Wählen Sie Playwright für neue Web-Testprojekte, die Auto-Wait und einen mitgelieferten Runner wollen.

• Wählen Sie Playwright, wenn native Netzwerk-Interception und schnelle Parallelität in CI zählen.

• Wählen Sie Playwright, wenn das Team ohne grosse Legacy-Bindung startet.

Wer Selenium verlassen will, ohne Tests wegzuwerfen, findet Migrationswege im Beitrag zu Selenium-Alternativen. Grundlagen zu Testtypen klärt der Überblick Testarten im Software-Testing.

Häufig gestellte Fragen

Ist Playwright besser als Selenium?

Playwright ist bei Stabilität und Entwicklerkomfort meist überlegen, dank eingebautem Auto-Wait und eigenem Test-Runner. Selenium bietet dafür den vendor-neutralen W3C-WebDriver-Standard (Empfehlung seit 2018), fünf Sprachen inklusive Ruby und bessere Portabilität. „Besser” hängt vom Projekt ab, nicht vom Werkzeug allein.

Unterstützt Selenium Auto-Wait wie Playwright?

Nein. Selenium hat kein eingebautes Auto-Wait; Teams codieren explizite oder implizite Waits selbst, was eine Hauptquelle für Flakiness ist (Selenium Docs, 2026). Playwright wartet standardmässig auf die Aktionierbarkeit von Elementen und senkt so das Timing-Risiko.

Welche Sprachen unterstützen Selenium und Playwright?

Selenium bietet fünf offizielle Bindungen: Java, Python, C#, Ruby und JavaScript. Playwright bietet vier: JavaScript/TypeScript, Python, Java und .NET (Selenium Downloads, 2026; Playwright Release Notes, 2026). Ruby gibt es nur bei Selenium.

Ist Playwright schneller als Selenium?

Playwright ist in vielen Szenarien schneller, dank persistenter Verbindung und eingebauter Parallel-Worker. Konkrete Prozentzahlen kursieren, stammen aber meist aus Benchmarks ohne nachprüfbare Methodik. Wir nennen daher keinen festen Faktor, sondern den architektonischen Grund.

Kann ich Selenium- und Playwright-Tests zusammen nutzen?

Ja. Plattformen wie Autemos importieren bestehende Selenium- und Playwright-Tests und exportieren echten Playwright-Code, sodass beide Bestände nebeneinander laufen ohne Lock-in. So lässt sich schrittweise migrieren, statt eine Suite komplett neu zu schreiben.

Fazit

Selenium und Playwright sind beide solide, treffen aber unterschiedliche Kompromisse. Playwright liefert Auto-Wait, einen eigenen Runner und native Netzwerk-Interception, was Stabilität und Startgeschwindigkeit erhöht. Selenium hält den vendor-neutralen W3C-WebDriver-Standard (offizielle Empfehlung seit 2018), fünf Sprachbindungen und eine über Jahre bewährte Grid-Skalierung. Für neue Web-Projekte ist Playwright meist der pragmatische Start; für Portabilität, Ruby-Bestände und Audit-Anforderungen bleibt Selenium relevant. Regulierte DACH-Teams gewichten die Standard-vs-Vendor-Frage besonders. Wer beide Bestände erhalten und Wartung senken will, prüft AI-gestützte Optionen mit echtem Code-Export und transparenter Selbstheilung. Sehen Sie sich diese in einer 30-minütigen Autemos-Demo an und klären Sie, welcher Weg zu Ihrer Testlandschaft passt.