Ein Team sah sich mit zunehmenden Reibungsverlusten bei Ende-zu-Ende-Tests konfrontiert und führte einen sauberen Vergleich von Cypress und Playwright durch. Rechthaberische Workflows, Plugins, Iframe-Probleme, fehlerhafte Screenshots und eine Paywall für parallele Läufe hatten die Lieferung verlangsamt. Ein gemeinsamer Hackathon mit Entwicklern und Testern ergab Skripte, Zeitpläne und Fehlerwirkungen. Playwright hatte die Nase vorn, wenn es um Geschwindigkeit, browserübergreifende Unterstützung und Kontrolle über Netzwerk und Kontext ging. Die frühe Migration zielt auf die wichtigsten Benutzerströme und Produktions-Smoke-Checks ab. Cookies, A/B-Flags und das Abfangen von Anfragen haben die Einrichtung und die Ausstattung neu gestaltet. Die Kapazität bleibt knapp, doch die Umstellung macht einen weiteren Punkt deutlich. Die Wahl des Tools ist eine Produktstrategie.
In dieser Folge spreche ich mit Maciej Wyrodek über den Wechsel von Cypress zu Playwright. Wir sprachen darüber, warum Cypress anfing, gegen das Team zu arbeiten: rechthaberischer Stil, Plugin-Churn, iFrames, unzuverlässige Screenshots und eine Preisschranke für parallele Läufe. Maciejs Antwort war ein praktischer Hackathon mit Entwicklern und Testern. Playwright hat gewonnen. Die Migration begann mit ihren Top-10-Flows und Produktions-Smokechecks.
"There is a lot of our custom admin stuff like managing artworks, managing the copyrights, managing work with the artist. So there is a lot of custom code there. So it's not just simple E-commerce." - Maciej Wyrodek
Maciej Wyrodek ist Wissenssucher, Qualitätsberater, Mentor und Trainer - spezialisiert auf Testautomatisierung und Prozessverbesserung.Maciej ist immer auf der Suche nach neuen Herausforderungen und Möglichkeiten, seine Fähigkeiten zu verbessern. Er hat Erfahrungen in verschiedenen Unternehmen mit unterschiedlichen Arbeitsmodellen gesammelt, von kleinen bis hin zu großen Konzernen, vom Produkt über die interne Entwicklung bis hin zum Softwarehaus. Dank dieser Erfahrung hat er einen umfassenden Einblick in das Testen von Qualität und die Schaffung von Mehrwert.Während seines Aufenthalts in Dublin hat er seine Leidenschaft entdeckt: Die Weitergabe von Wissen.Er ist der festen Überzeugung, dass das, was uns zu Menschen macht, die Fähigkeit ist, zu lernen und Wissen zu teilen.Aus diesem Grund tut er seit fast zehn Jahren sein Bestes, um der IT-Gemeinschaft etwas zurückzugeben, indem er Artikel schreibt, Videos auf seinem Kanal Itea Morning aufnimmt und auf Konferenzen spricht.
Für viele Entwicklungsteams ist Cypress die Standardlösung für die Testautomatisierung im Web. Es ist beliebt, leicht zu erlernen und das Ökosystem floriert. Aber was passiert, wenn Ihr wachsendes Projekt an die Grenzen des gewählten Test-Frameworks stößt?
Genau das ist Maciej Wyrodek und seinem Team bei Displate passiert. In einer kürzlich erschienenen Folge von Software Testing Unleashed erzählte Maciej, wie - und warum - sie die Entscheidung getroffen haben, eine umfassende Migration von Cypress zu Playwright vorzunehmen, und erläuterte den Prozess mit Einblicken, praktischen Ratschlägen und einigen überraschenden Ergebnissen.
Maciej hat sich die Entscheidung nicht leicht gemacht. Als er zu Displate kam, war Cypress bereits für die Frontend-Automatisierung im Einsatz, und als neuer Leiter der Qualitätssicherung entschied er sich zunächst dafür, die Anwendung auch auf Backend-Geschäftssysteme auszudehnen - vor allem, um keine Unruhe zu stiften. Im Nachhinein stellte er jedoch fest, dass die Design-Entscheidungen von Cypress und die starken Meinungen darüber, wie Tests geschrieben werden sollten, nicht gut mit den Bedürfnissen seines Teams übereinstimmten.
Im Laufe des Projekts traten mehrere Probleme immer deutlicher zutage:
Neben den technischen Hürden spielten auch geschäftliche Erwägungen eine entscheidende Rolle. Der Bedarf des Teams an erschwinglicher Parallelisierung führte es zu einem Drittanbieterdienst, Currents. Als Cypress jedoch Schritte unternahm, die die Unterstützung von Currents in neueren Versionen blockierten, schwand das Vertrauen und Displate sah sich gezwungen, sich anderweitig umzusehen.
Der Wechsel von Frameworks in einer aktiven, funktionsreichen Umgebung ist keine Kleinigkeit. Das Team stand vor der doppelten Herausforderung, wichtigen Automatisierungscode zu migrieren und gleichzeitig die tägliche Produktentwicklung und Qualitätssicherung aufrechtzuerhalten.
Ihre Strategie begann mit einer klaren Reflexion: Was nutzten sie tatsächlich und was gefiel ihnen an Cypress? Welche Probleme wollten sie unbedingt lösen? Auf dieser Grundlage stellte Maciejs Team eine Matrix mit Anforderungen zusammen, in der "Must-haves", "Nice-to-haves" und "Show-stoppers" für jedes neue Tool aufgeführt waren.
Anstatt sich bei der Entscheidung ausschließlich auf die Dokumentation oder die Angebote der Anbieter zu stützen, organisierte das Team einen praktischen Hackathon. Sieben Tool-Kandidaten traten gegeneinander an und wurden jeweils von kleinen Gruppen (darunter Entwickler und QA-Ingenieure) anhand von zehn realen Testfällen aus dem Displate-Bereich bewertet.
Playwright kristallisierte sich schnell als Spitzenreiter heraus - nicht nur wegen seines Funktionsumfangs, sondern auch wegen seiner praxisnahen Leistung und der Einfachheit, stabile Tests zu starten.
Einige Tools verloren schnell an Boden, entweder aufgrund schlechter Dokumentation, veralteter Anleitungen oder einer Fehlerwirkung, die den praktischen Anforderungen des Arbeitsablaufs des Teams nicht gerecht wurde.
Experimente mit KI-basierten Tools hatten zwar einen gewissen Unterhaltungswert - ein Skript, das minutenlang nach dem Zufallsprinzip über die Website wanderte, bevor es ein Szenario abschloss -, waren aber für die Produktionsmigration noch nicht zuverlässig genug.
Wichtig war, dass das Team die Anpassung durch eine Demo am Ende des Hackathons sicherstellte. Während einige andere Frameworks bewundernswerte Leistungen erbrachten, fand die Kombination aus Flexibilität, Community und praktischen Ergebnissen von Playwright breite Zustimmung.
Nachdem die Entscheidung für Playwright gefallen war, begann die harte Arbeit der Migration. Das Team priorisierte zunächst die kritischsten Tests - die zehn wichtigsten End-to-End-Szenarien, die für den Geschäftswert entscheidend sind - und migrierte sie während der Entwicklungspause für neue Funktionen im Dezember. Von da an war ihr Ansatz pragmatisch:
Während die manuelle Programmierung weiterhin im Mittelpunkt steht, experimentiert das Team mit KI-Tools wie Cursor, um die Migration zu unterstützen, den Cypress-Code in Playwright zu übersetzen und routinemäßige Neuschreibungen zu beschleunigen. Die ersten Ergebnisse sind vielversprechend, wenn auch gelegentlich unvorhersehbar. Maciej erwartet mit der Reife der Tools eine weitere KI-Integration.
Wird das Team die Migration in diesem Jahr abschließen? Das hängt davon ab - die Ressourcenplanung ist noch nicht abgeschlossen, und die geschäftlichen Anforderungen haben immer Vorrang. Mit der zunehmenden Akzeptanz von Playwright sowohl bei der Qualitätssicherung als auch bei den Entwicklern sieht die Zukunft der Testautomatisierung bei Displate jedoch kollaborativ, wartbar und lernfähig aus.
Abschließende Überlegungen:Maciejs ehrliche Überlegungen bieten praktische Lektionen für jedes Team, das mit Tool-Müdigkeit konfrontiert ist oder die Testautomatisierung skalieren muss. Die wichtigsten Erkenntnisse: Verstehen Sie Ihren Kontext, binden Sie das gesamte Team ein, testen Sie Tools in Ihrer realen Umgebung, erwarten Sie Überraschungen und passen Sie sich kontinuierlich an - sei es durch Prozessoptimierungen oder aufkommende Technologien wie KI.