Testmigration: Wenn die Cloud-Kosten das QA-Budget sprengen

Wer ein Framework für Testautomatisierung wechselt, zieht eine komplette Ende-zu-Ende-Testsuite von einem Tool ins andere um, während die tägliche Testarbeit weiterläuft. Bevor sie sich festlegen, prüfen Teams die Kandidaten meist in einem strukturierten Hackathon an echten Testszenarien. Beim Wechsel von Cypress zu Playwright tauchen oft versteckte Lücken auf: Session-Handling, das Abfangen von Requests und ganzseitige Screenshots funktionieren in beiden Frameworks unterschiedlich. Die kritischen Geldpfade ziehen zuerst um, weil sie dem neuen Framework früh ein funktionierendes Sicherheitsnetz geben.

Das Wichtigste in Kürze

• Das beliebteste Framework im falschen Kontext führt zu immer neuen Workarounds: Cypress passte schlecht zu Bezahlabläufen in iFrames, zu ganzseitigen Screenshots und zu bestimmtem Scrollverhalten unter React.
• Der Vendor-Lock-in bei der Parallelisierung hat die Beziehung zu Cypress beendet: Ab Version 13 blockierte Cypress Orchestrierungstools von Drittanbietern, Teams mussten also entweder ein Vielfaches ihres QA-Budgets für Cypress Cloud zahlen oder auf einer veralteten Version bleiben.
• Ein eintägiger Hackathon mit echten Testszenarien am eigenen Produkt zeigt schneller und verlässlicher, welches Tool passt, als jeder statische Feature-Vergleich oder jede Herstellerdemo.
• KI-gestützte Migration von Cypress zu Playwright ist vielversprechend, braucht aber sorgfältiges Prompting, bei dem der Agent Repos und Dokumentation bekommt, und die Ergebnisse müssen weiterhin von Menschen auf langfristige Wartbarkeit geprüft werden.

Warum das beliebteste Tool für Testautomatisierung trotzdem falsch sein kann

Beim Wechsel von Cypress zu Playwright lohnt es sich, mit dem Warum anzufangen: Das beliebteste Tool für Testautomatisierung ist nicht automatisch das richtige für deinen Kontext. Cypress lernt man schnell, und es ist weit verbreitet, aber es drängt dich in eine bestimmte Art, Tests zu schreiben, und die passt nicht zu jedem Projekt.

Cypress bringt eine eigenwillige domänenspezifische Sprache mit. Sie gibt weitgehend vor, wie Assertions aussehen, was ein Test prüft und wie er aufgebaut ist. Weichen deine Bedürfnisse von diesem vorgesehenen Stil ab, schreibst du gegen das Framework an statt mit ihm.

Viele Lücken füllen Plugins, und davon hat Cypress Tausende. Der Preis zeigt sich später: Die Plugins aktuell und über Cypress-Versionen hinweg kompatibel zu halten, wird zur eigenen Wartungslast. Wenn ein Tool einen ganzen Stapel Plugins braucht, um zu tun, was du willst, ist das ein Signal, das du ernst nehmen solltest.

Maciej Wyrodek beschreibt ein konkretes Muster aus seiner Arbeit bei Displate. Wie das Team Tests schrieb und was es von diesen Tests wollte, entfernte sich immer wieder von dem, was Cypress von Haus aus bot. Diese Diskrepanz, wiederholt über viele Tests, ist der eigentliche Grund, ein Framework zu hinterfragen, nicht ein einzelner lästiger Bug.

Technische Reibung, die sich aufstaut

Einzelne technische Grenzen rechtfertigen selten für sich allein eine Migration. Wenn sie sich über die Zeit stapeln, schon.

iFrames von Drittanbietern sind ein bekannter wunder Punkt. Bezahlabläufe stecken oft in iFrames, und Cypress geht damit umständlich um. Ein Plugin macht es möglich, aber der Umgang mit iFrames bleibt fragil.

Ganzseitige Screenshots bei fehlgeschlagenen Tests waren bei einer langen Webseite ein echtes Ärgernis. Prüfte eine Assertion ein Element außerhalb des sichtbaren Bereichs, zeigte der Screenshot nicht immer die richtige Scrollposition. Ein dokumentiertes Problem mit bestimmten React-Konfigurationen wiederholte bei einer ganzseitigen Aufnahme den Seitenkopf mehrfach, statt die Seite einmal zu rendern.

Für jedes dieser Probleme gab es einen Workaround. Das Problem ist die Form des Ergebnisses: Workarounds auf Workarounds. Wenn deine Testsuite so zusammengehalten wird, dient das Framework dem Team nicht mehr.

Wie die Parallelisierung von Cypress zum Geschäftsproblem wurde

Der entscheidende Bruch war kommerziell, nicht technisch. Cypress verkauft Parallelisierung als kostenpflichtigen Service, und das verändert die Rechnung für eine größere Organisation.

In der Selenium-Ära konntest du ein Selenium Grid selbst hosten und selbst parallelisieren oder Grid-Kapazität bei Anbietern kaufen. Cypress ist einen anderen Weg gegangen und hat ein Geschäft um parallele Läufe herum aufgebaut. Das Framework selbst ist kostenlos, aber wer die Testausführung skalieren will, landet beim bezahlten Hosting.

Displate nutzte Currents, eine Alternative zu Cypress Cloud von einem Drittanbieter. Für eine Organisation dieser Größe kam Cypress Cloud etwa 10- bis 20-mal teurer als Currents, weil Cypress Nutzer und Läufe gemeinsam paketierte. Das Team brauchte mehr Nutzer, nicht mehr Läufe, und bei dieser Kombination war Cypress nicht flexibel. Das Cypress-Cloud-Paket, zu dem das Team gedrängt wurde, hätte mehr als das gesamte QA-Budget des Jahres gekostet.

Danach verschlechterte sich die Beziehung. Ab Version 13 blockierte Cypress die Nutzung von Currents. Displate blieb auf Cypress 12, der letzten Version, die Currents unterstützt, und entschied, das Cypress-Ökosystem zu verlassen.

Die Lehre gilt über diesen einen Anbieter hinaus: Wenn ein Toolanbieter dich wie einen Gefangenen behandelt und nicht wie einen Verhandlungspartner, ist das allein schon ein Grund, den Ausstieg zu planen.

Warum eine Tool-Migration viel länger dauert als die Entscheidung

Die Entscheidung, ein Framework zu verlassen, fällt schnell. Die Migration nicht.

Displate beschloss im September 2023, Cypress zu verlassen. Der eigentliche Umzug zog sich über das folgende Jahr und darüber hinaus, weil das Team die ganze Zeit die tägliche Testarbeit weiterträgt. Bestehende Tests pflegen und die Entwicklung unterstützen, das pausiert nicht, nur weil du das Framework tauschst.

Eine Migration, die mit der regulären Auslieferung konkurriert, lässt sich nicht nebenbei über Nacht erledigen. Sie braucht reservierte Kapazität und einen realistischen Zeitplan, sonst verrutscht sie. Behandle den Umzug als langfristiges Projekt mit fest eingeplanter Kapazität, nicht als Sprintziel, das du an ein volles Quartal dranschraubst.

Automatisierungstools bewerten, ohne zu raten

Die Auswahl eines Frameworks beginnt damit, dein aktuelles zu verstehen, nicht damit, dem Marktführer hinterherzulaufen. Schau zuerst, was du tatsächlich nutzt, was dir gefällt und wo es dich im Stich lässt.

Von dieser konkreten Liste gehst du zur allgemeinen Frage: Was willst du von einem Ende-zu-Ende-Framework, und wie sieht dein Testansatz aus? Daraus werden Kriterien, die du bewerten kannst. Displate hat eine Bewertungstabelle gebaut, in der manche Kriterien mehr Gewicht hatten als andere, und das Feld so auf etwa sieben Tools eingegrenzt.

Recherche am Schreibtisch trägt nur bis zu einem gewissen Punkt. Demos und Dokumentation zeigen dir, was der Hersteller dich sehen lassen will, nicht, wie sich das Tool auf deiner eigenen Website verhält.

Der Markt selbst hat das Team überrascht. Im Vergleich mit einer Recherche von 2019 hatte sich bis 2024 kaum etwas grundlegend verändert. Der letzte große Neuzugang war Playwright zu Beginn der Pandemie. Die Welle der Record-and-Play-Tools, die einmal den Markt zu übernehmen schien, blieb eine Nische, brauchbar nur, wenn deine Anforderungen in ihr enges Raster passen.

Warum ein Hackathon mehr zeigt als eine Feature-Checkliste

Ein praktischer Proof of Concept zeigt, was eine Feature-Matrix nicht zeigen kann. Displate veranstaltete einen Hackathon mit Quality Engineers und interessierten Backend- und Frontend-Entwicklern und prüfte die Tools der engeren Wahl an zehn vorbereiteten Testfällen.

Die zehn festen Szenarien hatten zwei Zwecke. Sie schufen eine gemeinsame Basis, sodass nicht jeder andere Tests schrieb, und das Team konnte zählen, wie viele Fälle jedes Tool tatsächlich schaffte.

Der Hackathon brachte Probleme ans Licht, die in keiner Tabelle standen. Ein codebasiertes Tool brachte an einem ganzen Tag keinen einzigen funktionierenden Test zustande, obwohl alle der Dokumentation und dem Quick-Start-Guide folgten. Nach einem kürzlichen Framework-Update war die Dokumentation so veraltet, dass der einzige Weg über GitHub Issues führte. Sich durch Support-Tickets zu wühlen, statt Dokumentation zu lesen, war schon für sich ein Ausschlusskriterium.

Und dann das unbequeme Ergebnis: Nach all der Recherche entschied sich das Team für Playwright, die beliebteste Option und von Anfang an der naheliegende Kandidat. Der Unterschied ist, dass die Wahl jetzt auf Belegen beruhte und nicht auf Annahmen. Genau diese Belege legst du deinem Management vor.

Was die KI-Testerzeugung in der Evaluierung tatsächlich gemacht hat

KI-generierte Tests sehen beeindruckend aus, ersetzen aber noch keine wartbare Testsuite. Eines der evaluierten Tools hatte eine KI-Komponente, die aus einer Beschreibung im BDD-Stil einen Test erzeugte.

Ein Entwickler gab die vorbereitete Anweisung ein: Geh auf die Startseite, wähl das erste Produkt, leg es in den Warenkorb, kauf es. Das Tool scannte die Seite und improvisierte. Es wanderte durch Menüs und Kollektionsseiten, sprang auf eine Markenseite, schloss von sich aus ein Newsletter-Pop-up und landete nach rund sechs Minuten Klickerei schließlich auf einer Produktseite und legte das Produkt in den Warenkorb.

Mit dem vorbereiteten Szenario hatte der Weg des Tools nichts zu tun. Unter der Haube erzeugte ein KI-Agent zuerst einen Pfad und schrieb ihn nach Freigabe als Skript aus. Läuft derselbe Prompt später noch einmal, kommt sehr wahrscheinlich ein völlig anderer Pfad heraus, weil das Sprachmodell die Route jedes Mal neu erzeugt.

Dieser Nichtdeterminismus ist der Haken. Einem Test, der bei jedem Lauf einen anderen Weg nimmt, kann man schwer vertrauen, und warten lässt er sich noch schwerer.

Wie Playwright im selben Hackathon abgeschnitten hat

Im direkten Vergleich lieferte Playwright die stärksten Ergebnisse. Ein Entwickler schrieb mit Cursor und dem Recording-Inspector von Playwright alle zehn Fälle und stabilisierte sie noch während des Hackathons.

Nur ein anderer Ansatz schaffte ebenfalls alle zehn: reines Record-and-Play. Playwright mit KI-Unterstützung beim Code kam auf dieselbe Quote und blieb dabei codebasiert.

Das Ergebnis hat einen Vorbehalt, den man im Kopf behalten sollte. Die erzeugten Tests waren nicht auf Wartbarkeit gebaut. Hätte sich etwas geändert, hättest du den ganzen Test vermutlich neu aufzeichnen müssen, ganz wie bei einem Record-and-Play-Tool. Der Hackathon hat bewiesen, dass die Tests möglich sind, nicht, dass sie halten.

Das größere Team kam in einer abschließenden Demo, in der alle ihr Tool und ihre Meinung zeigten, zum selben Schluss. Ein paar Optionen schnitten gut ab. Mit Playwright konnte keine mithalten.

Beim Wechsel von Cypress zu Playwright zuerst die kritischen Pfade

Migriere die kritischsten Tests zuerst, denn sie müssen am schnellsten laufen und schneiden vertikal durch das ganze System. Displate teilt seine Ende-zu-Ende-Tests in drei Stufen ein, und die Reihenfolge der Migration folgt dieser Struktur.

Die Top 10 sind die kritischen Geldpfade, sie laufen gegen die Produktion. Sie sind nicht die einfachsten Tests, aber wer sie zuerst umzieht, hat früh ein funktionierendes Sicherheitsnetz im neuen Framework und muss die schwierigen Integrationsfragen gleich am Anfang klären.

Danach geht es schrittweise weiter. Neue Funktionalität wird nur noch in Playwright geschrieben. Bestehende Cypress-Tests ziehen um, wenn eine echte Änderung an der Logik ansteht; einen trivialen Locator-Fix kann man in Cypress flicken, bis der Test an der Reihe ist.

Was bei der Migration trotz gründlicher Recherche überrascht

Auch eine sorgfältige Evaluierung übersieht Dinge, weil Frameworks dieselbe Aufgabe unterschiedlich lösen. Das Session-Handling hat das Team kalt erwischt.

Displate fährt viele A/B-Tests und speichert Daten im Local Storage, im Session Storage, im Cache und in Cookies. Die Tests laufen gegen die Produktion ebenso wie gegen Testumgebungen, nach dem Prinzip, dass keine Testumgebung so nah an der Produktion ist wie die Produktion selbst. Also müssen die Tests zuerst die Analyse-Cookies entfernen, sonst verfälschen sie echte Daten.

Das Risiko ist nicht hypothetisch. Eine Posterseite, die in der Automatisierung viel genutzt wurde, kam auf so viele tägliche Besuche, dass jemand im Unternehmen vorschlug, die Künstlerin oder den Künstler wegen einer Werbeaktion anzusprechen. Der Testverkehr wurde als echtes Interesse gelesen, das nur nicht zu Käufen führte.

Das Abfangen von API-Requests galt als gleichwertig in allen Frameworks. War es nicht. In Cypress brauchte das Abfangen eines Autorisierungs-Requests etwa zwei Zeilen. In Playwright musste das Team das richtige Setup in verstreuter Dokumentation zusammensuchen. Hosts zu blockieren ging in Cypress über eine Konfigurationsoption; in Playwright musste das Team die Logik dafür selbst schreiben. Nichts davon stand in der Bewertungstabelle, weil alle davon ausgingen, dass “Request-Handling” das abdeckt.

Eine subtilere Falle: umschreiben statt umdenken. Das Team hatte vereinbart, Cypress-Code nicht Zeile für Zeile zu portieren, sondern die Tests aus der Logik heraus neu aufzubauen. Unter Termindruck und mit einem Tool, das noch nicht ganz beherrscht war, rutschten die Leute trotzdem wieder dahin, Cypress-Muster nach Playwright zu übersetzen. Das ist, als wollte man einen eckigen Klotz durch ein rundes Loch drücken. Und es ist ein ganz normales Fehlermuster, an dem niemand schuld ist.

Kapazität für die Migration im laufenden Betrieb finden

Kapazität für die Migration entsteht durch Priorisierung und Timing, nicht durch Überstunden. Displate nutzte den größten Teil des Dezembers, weil in der Weihnachtszeit wenig neue Features entstehen. Die Wochen vor dem Black Friday bis Weihnachten sind die umsatzstärkste Zeit des Unternehmens, große Features bleiben draußen, und im Kalender ist Platz für Aufräumen und Migration.

Das Team arbeitet wie ein Plattformteam und nicht mit einem Tester pro Lieferteam. Die meisten Entwicklerinnen und Entwickler testen ihre eigene Arbeit, die Quality Engineers unterstützen: Sie recherchieren etwa, wie man Zahlungen in einem neuen Markt testet, oder finden heraus, wie sich etwas abdecken lässt, bei dem ein Team keine Ahnung hat, wie es das testen soll. Dieses Modell schafft Zeit für Wartung, aber nur, wenn die Roadmap es zulässt.

Ehrliche Kapazitätsplanung gibt ihre Grenzen zu. Mit Blick nach vorn rechnete das Team in manchen Monaten mit wenig Zeit für Automatisierung und hat dafür einen Teil der Kapazität im Backlog fest reserviert, statt so zu tun, als würde die Arbeit schon irgendwie reinpassen. Derzeit sorgt eine Rotation dafür, dass zwei Leute die Teams unterstützen, während eine Person Automatisierung schreibt. So bleibt jeder am neuen Tool dran.

Wo KI in die Migration selbst passt

KI kann den Umzug beschleunigen, die Wartbarkeit bleibt aber die offene Frage. Ein Entwickler hat mit Cursor experimentiert, um Tests von Cypress nach Playwright zu übersetzen. Er gab dem KI-Agenten das Cypress-Repository, die Playwright-Dokumentation und den Playwright-Zielcode und bat ihn dann, einen bestimmten Test zu erzeugen.

Nach ein paar Anläufen kamen Tests heraus, die funktionierten. Der Haken ist derselbe, der sich durch das ganze Thema zieht: Ob die übersetzten Tests wartbar sind, ist noch nicht bewiesen. Die Demo vor dem größeren Team ging an diesem Tag schief, obwohl frühere Versuche im stillen Kämmerlein geklappt hatten.

Realistisch betrachtet werden bessere Prompts und mehr Routine im Team mit dem Tool das Schreiben und Übersetzen von Tests mit der Zeit schneller machen. Sieh die KI-Übersetzung als Werkzeug, das man lernen muss, nicht als Schalter, der die Migration für dich erledigt.

Der Gewinn nebenher: Frontend-Entwickler kommen in die Automatisierung. Mit Playwright arbeiten die Entwickler an Pull Requests mit, und der Plan ist, dass sie ihre eigenen Tests schreiben und pflegen, sobald die Top 10 stabil sind. Dieser Wandel war lange gewünscht und ist mit Playwright leichter als mit Cypress. Vielleicht ist er sogar wichtiger als die Wahl des Frameworks selbst.

Häufig gestellte Fragen

Ist das am häufigsten verwendete Test-Framework normalerweise die sicherste Wahl?

Nein. Beliebtheit sagt nichts über die Eignung aus. Cypress ist schnell zu erlernen, aber seine eigenwillige domänenspezifische Sprache bestimmt weitgehend, wie Assertions aussehen und wie Tests strukturiert sind. Wenn der Testansatz eines Teams von diesem Stil abweicht, muss es gegen das Framework programmieren. Tausende von Plugins schließen Lücken, und die Aufrechterhaltung der Kompatibilität dieser Plugins über verschiedene Versionen hinweg wird dann zu einem eigenen Aufwand für die Wartung.

Wie kann das Preismodell eines Anbieters eine Framework-Migration erzwingen?

Parallelisierung wird als kostenpflichtiger Service verkauft, sodass die Skalierung der Testdurchführung eher zu einer Lizenzfrage als zu einer Infrastrukturfrage wird. Displate führte parallele Läufe über Currents durch, eine Alternative eines Drittanbieters; das Cypress-Cloud-Paket, das ihnen angeboten wurde, war etwa 10- bis 20-mal teurer und hätte das gesamte jährliche QA-Budget verschlungen. Cypress blockierte Currents dann ab Version 13.

Wie lange dauert es realistisch gesehen, eine End-to-End-Suite auf ein anderes Framework umzustellen?

Weitaus länger als die Entscheidung selbst. Displate beschloss im September 2023, Cypress zu verlassen, und die eigentliche Umstellung erstreckte sich über das gesamte folgende Jahr und darüber hinaus, da die tägliche Arbeit zum Testen und die Entwicklungsunterstützung nie unterbrochen wurden. Plane es als ein langfristig angelegtes Projekt mit reservierten Kapazitäten und nicht als Sprint-Ziel in einem arbeitsreichen Quartal.

Was zeigt ein praktischer Proof of Concept, was ein Funktionsvergleich übersieht?

Das tatsächliche Verhalten an deinem eigenen Produkt. Displate hat etwa sieben Tools in die engere Wahl gezogen und dann einen eintägigen Hackathon mit Qualitätsingenieuren und interessierten Entwicklern anhand von zehn vorbereiteten Testfällen durchgeführt. Ein codebasiertes Tool lieferte den ganzen Tag über überhaupt keinen funktionierenden Test: Ein kürzlich durchgeführtes Update hatte die Dokumentation so veraltet gemacht, dass der einzige Weg nach vorne über GitHub-Issues führte.

Können KI-generierte Ende-zu-Ende-Tests handgeschriebene ersetzen?

Nicht zuverlässig, wegen des Nichtdeterminismus. In einer Bewertung führte eine Anweisung im BDD-Stil, das erste Produkt zu kaufen, dazu, dass der Agent durch Menüs, eine Sammelseite und eine Markenseite wanderte, ein Newsletter-Popup schloss und erst nach etwa sechs Minuten eine Produktseite erreichte. Das Modell generiert den Pfad bei jedem Durchlauf neu, sodass dieselbe Eingabe wahrscheinlich zu einem anderen Pfad führt.

Welche Tests sollten beim Wechsel des Frameworks zuerst migriert werden?

Die kritischsten. Displate unterteilt Ende-zu-Ende-Tests in vollständige Regressionstests, eine Smoke-Suite nach jedem Deployment und eine „Top 10“, die in der Hochsaison alle 10 Minuten und ansonsten alle 30 Minuten gegen die Produktionsumgebung läuft. Wenn man diese wichtigen Pfade zuerst migriert, schafft man ein funktionierendes Sicherheitsnetz im neuen Framework und zwingt sich frühzeitig dazu, schwierige Integrationsfragen zu klären.

Was überrascht Teams oft nach einer gründlichen Tool-Evaluierung?

Details, von denen man annahm, sie seien gleichwertig. Das Session-Handling unterschied sich stark, da Tests, die die Produktionsumgebung erreichen, Analyse-Cookies entfernen müssen, um echte Daten nicht zu verfälschen. Das Abfangen eines Autorisierungs-Requests erforderte in Cypress etwa zwei Zeilen; in Playwright musste man sich durch verstreute Dokumentation wühlen, und das Blockieren von Hosts musste von Hand geschrieben werden, anstatt es über eine Konfigurationsoption einzustellen.

Woher kommt die Kapazität für eine Migration, wenn die Auslieferung weiterläuft?

Durch Priorisierung und gute Zeitplanung, nicht durch Überstunden. Displate nutzte den größten Teil des Dezembers, da große Features während der umsatzstarken Wochen vom Black Friday bis Weihnachten nicht veröffentlicht werden. Die Qualitätsingenieure arbeiten als Plattformteam, das Entwickler dabei unterstützt, ihre eigene Arbeit zu testen, und dank eines Rotationssystems sind immer zwei Personen im Support, während eine Person die Testautomatisierung schreibt.