Wann hast du das letzte Mal einen Designfehler gefunden, der zuvor noch in Ordnung war?

Zwar sind traditionelle Testmethoden bei der Softwareentwicklung wichtig – sie sind aber oft zu eingeschränkt, um alle Probleme und Fehler zu erkennen. Viele Methoden konzentrieren sich häufig nur auf die Funktionalität und übersehen dabei subtile visuelle Regressionen, die die User Experience beeinträchtigen können.

Eine falsch platzierter CTA, ein schief ausgerichteter Text oder eine unerwartete Farbänderung: Solche Details mögen zwar klein erscheinen, sie können aber das Vertrauen der Nutzer:innen beeinträchtigen, Frustration hervorrufen und Zweifel an der Zuverlässigkeit der Software schüren. In einem Wettbewerbsumfeld, in dem reibungslose Prozesse wichtig für Kaufentscheidungen sind, können solche Details entscheidend sein.

Genau an diesem Punkt setzt visuelles Testen an. Durch den automatischen Vergleich von Screenshots unserer Plattform auf verschiedenen Bildschirmgrößen und in unterschiedlichen Browsern erkennen wir visuelle Abweichungen, bevor sie die Nutzer:innen erleben. Dieser Ansatz minimiert das Risiko fehlerhafter Softwareoberflächen und sichert die Qualität, die unsere Kund:innen erwarten. 

Allerdings entwickelt sich unsere Plattform ständig mit neuen Features weiter. Wie stellen wir also sicher, dass dieser Testprozess effizient und zuverlässig ist? Dafür benutzen wir zwei Instrumente: Playwright und Happo.

Playwright: robuste End-to-End-Tests

Unsere End-to-End-Teststrategie (E2E) basiert auf Playwright. Das Tool funktioniert browserübergreifend. Mit den Automatisierungsfunktionen können wir kritische Abläufe und Funktionen gründlich testen. So stellen wir sicher, dass die Kernfunktionen zuverlässig funktionieren. Das schafft eine stabile Grundlage für unsere gesamte Teststrategie.

Für verlässliche End-to-End-Tests sind wir auf zwei Dinge angewiesen: Einerseits das Commitment unseres Teams, sämtliche Flaky-Tests schnell zu beheben. Andererseits die präzisen Assertions von Playwright, die automatisch eine erneute Prüfung durchführen und auf Statusänderungen warten. Das hat die Zuverlässigkeit unserer Testsuite erheblich gesteigert.

Die Kombination hat nicht nur unsere Ausfallsicherheit verbessert, sondern macht unsere Tests zu einem unverzichtbaren Bestandteil unseres Softwareentwicklungsprozesses, auf die wir uns jederzeit verlassen können. Schließlich will sich keine Entwicklerin und kein Entwickler auf ein Tool verlassen, das ständig unbegründet Alarm schlägt. Deshalb ist es für uns entscheidend, dass unsere End-to-End-Tests schnell und zuverlässig sind. Aktuell streben wir an, die gesamte Testsuite in weniger als 5 Minuten auszuführen.

Happo: visuelles testen auf neuem Level

Neben unseren Playwright E2E-Tests nutzen wir Happo für visuelle Regressionstests. Happo fügt sich nahtlos in unseren Workflow ein und erstellt Screenshots an verschiedenen Punkten der E2E-Tests. Diese werden mit einer Baseline verglichen, um visuelle Unterschiede schnell zu erkennen. So entdecken wir ungewollte Änderungen und können sie schnell korrigieren, um ein konsistentes Benutzererlebnis über alle Anwendungen hinweg zu gewährleisten. 

Anstatt Feature-Branches kontinuierlich mit dem ständig wechselnden HEAD des Main-Branches zu vergleichen, nutzt Happo ein Commit-basiertes Baselinesystem. Bei Änderungen im Main-Branch werden Baseline-Berichte erstellt. Der Bericht, der an der Git-Merge-Basis des Feature-Branches entsteht, dient als Grundlage für Vergleiche und hebt alle visuellen Abweichungen hervor. Weitere Builds des Feature-Branches werden weiterhin mit dieser Baseline verglichen, wodurch Entwickler:innen die Auswirkungen ihrer Änderungen isoliert betrachten können – ohne durch andere, nicht verwandte Updates im Main-Branch gestört zu werden. 

Mit jedem Build entwickeln sich die Screenshots des Feature-Branches weiter. Sobald dieser mit dem Main-Branch zusammengeführt wird, dienen die Screenshots des zusammengeführten Branches als neue Baseline für den Main-Branch. 

Dieser Ansatz gewährleistet, dass Vergleiche stets mit dem relevantesten Stand der Codehistorie durchgeführt werden und präzise die visuellen Unterschiede aufzeigen. Er vermeidet die Verwirrung, die durch den ständigen Vergleich eines sich schnell ändernden Main-Branches mit einem Feature-Branch entstehen würde. Jeder Feature-Branch hat eine eigene visuelle Historie, die von Happo getrackt wird. Das vereinfacht die Identifikation und das Management visueller Regressionen.

Eng mit GitHub verknüpft

Happo-Checks sind als Status-Checks nahtlos in GitHub integriert. Bei re:cap sind sie so eingestellt, dass sie keine Deployments blockieren – im Gegensatz zu fehlgeschlagenen E2E-Tests, die genau das tun würden. Dennoch sind sie auffällig genug, um Entwickler:innen davon abzuhalten, ihren Pull Request zu mergen, wenn Happo einen unerwarteten Unterschied zwischen dem Main-Branch und dem Feature-Branch anzeigt.

Ein Praxisbeispiel: Das Problem der ausufernden Meldungen

Doch wie sieht das in der Praxis aus? Neulich sind wir bei der Entwicklung einer neuen Funktion von Happo auf einen fehlerhaft eingefärbten Text und ein Problem mit zu vielen Benutzerbenachrichtigung aufmerksam gemacht worden. Unsere Playwright E2E-Tests liefen ohne Probleme durch, da die Funktionalität der App nicht beeinträchtigt war. Doch Happo identifizierte die unerwünschten Farb- und Layoutänderungen, die für Nutzer:innen auffällig und störend gewesen wären. 

Mit dem visuellen Vergleich von Happo haben wir das Problem frühzeitig erkannt und behoben, noch bevor es ausgerollt wurde. So konnten wir eine negative Benutzererfahrung vermeiden. Das ist nur eines von vielen Beispielen, wie Happo uns dabei hilft, ein hohes Qualitätsniveau zu wahren, während wir neue Funktionen schnell ausrollen.

"Happo gewährleistet, dass in unseren Pull-Requests keine unerwünschten visuellen Änderungen auftreten – etwas, das reine End-to-End-Tests nicht immer abdecken können", sagt Adrian Burkhart, Fullstack Engineer bei re:cap

Dank der Kombination aus Playwright für funktionale Tests und Happos visuellen Testmöglichkeiten haben wir eine robuste Teststrategie entwickelt. Wir können neue Funktionen schnell und zuverlässig bereitstellen. Davon profitieren unsere Nutzer:innen und unser Team. Es gibt unseren Entwickler:innen die Sicherheit, sich auf die Entwicklung neuer Funktionen zu konzentrieren – immer im Wissen, dass visuelle Regressionen abgefangen werden, bevor sie Auswirkungen auf unsere Software und die User Experience haben.