Nach dem Deployment ist vor dem Fehler: Warum wir Websites visuell absichern

Ein CMS-Update, ein kleines CSS-Refactoring - in der Entwicklungsumgebung sieht alles gut aus. Dann meldet sich der Kunde: Auf der Karriereseite hat sich das Bewerbungsformular verschoben und die Abstände stimmen nicht mehr. Niemand hatte diese Seite nach dem Deployment geprüft, denn die Änderung betraf eine ganz andere Stelle.

Das ist kein Ausnahmefall - das ist der Normalfall, wenn Websites eine gewisse Größe erreichen.

Was das Auge nicht prüft, fällt nicht auf

Moderne Websites bestehen aus Dutzenden, oft hunderten Seiten, und nach einem Update klickt niemand jede einzelne durch. Bei einem CMS-Update, das zehn Seitentypen betrifft, müsste jemand jede betroffene Seite auf Desktop und Mobil öffnen, scrollen und mit dem vorherigen Zustand vergleichen - nach jedem Release.

Das passiert nicht. Stattdessen prüft das Team die Seiten, an denen aktiv gearbeitet wurde, und der Rest bleibt ungeprüft. Genau dort entstehen die Probleme: Ein CSS-Refactoring verschiebt einen Abstand drei Seiten weiter, ein Widget-Update verändert die Darstellung auf einer Unterseite, die seit Monaten niemand angefasst hat.

Das Problem ist nicht Nachlässigkeit, sondern Komplexität.

Ein automatischer Vorher-Nachher-Vergleich

Visual Regression Testing löst dieses Problem mit einem einfachen Prinzip: einem automatisierten Vorher-Nachher-Vergleich.

Bevor ein Update live geht, speichert das Tool den visuellen Zustand der wichtigsten Seiten als Referenz - eine sogenannte Baseline. Das sind pixelgenaue Screenshots, die in einem echten Browser auf Desktop und Mobil aufgenommen werden.

Nach dem Update entstehen neue Screenshots, die das Tool automatisch mit der Baseline vergleicht. Wenn sich etwas verändert hat, schlägt es Alarm, und ein visueller Bericht zeigt exakt, was sich wo geändert hat.

Dabei baut das Tool nichts und deployed auch nichts - es bekommt eine URL und prüft, was dort zu sehen ist. Die gesamte Prüfung läuft in wenigen Minuten, ohne dass jemand einen Browser öffnen muss.

Warum das schwieriger ist, als es klingt

Eine lebendige Website ist kein statisches Dokument - sie verändert sich bei jedem Aufruf, und genau das macht automatisierte visuelle Vergleiche zur Herausforderung.

Cookie-Banner etwa erscheinen beim ersten Besuch und verschieben den gesamten Seiteninhalt. Wenn das Tool den Banner nicht kontrolliert behandelt, sieht jeder Screenshot anders aus - nicht weil sich tatsächlich etwas geändert hat, sondern weil der Banner mal da ist und mal nicht.

A/B-Testing-Skripte wiederum verändern Inhalte gezielt und zufällig. In einem unserer Projekte zeigten Screenshots desselben Seitenaufrufs unterschiedliche Varianten, weshalb diese Skripte beim Testen gezielt nicht geladen werden, damit der Vergleich stabil bleibt.

Dynamische Elemente wie wechselnde Teaser-Bilder, aktuelle Preise oder personalisierte Inhalte erzeugen ebenfalls falsche Alarme. Solche Bereiche werden automatisch maskiert, sodass das Tool weiß, dass sich dort etwas ändern darf, und diese Regionen beim Vergleich ignoriert.

Und dann gibt es die Fälle, die niemand auf dem Schirm hat: In einem Projekt stand uns die eigene Bot-Erkennung im Weg, weil das Test-Tool als automatisierter Zugriff erkannt und blockiert wurde.

Deterministische Screenshots auf einer lebendigen Website sind kein Feature, das man einmal aktiviert - sie sind eine laufende ingenieurtechnische Leistung.

Drei Projekte, drei Anforderungen

Visual Regression Testing gehört bei uns zum Standard-Setup und läuft in mehreren Projekten mit ganz unterschiedlichen Anforderungen.

In einem kleineren Projekt mit drei kritischen Seiten dient es vor allem der Absicherung nach regelmäßigen CMS-Updates - drei Seiten definieren, Baseline erstellen, fertig. Die Laufzeit liegt bei unter zwei Minuten.

In einem anderen Projekt mit elf Seiten setzt der Kunde A/B-Testing ein, das bei jedem Aufruf andere Inhalte zeigt. Ohne gezielte Gegenmaßnahmen wäre jeder Testlauf ein Fehlalarm gewesen.

Das umfangreichste Setup umfasst über dreißig Seiten, Cookie-Banner und eine Bot-Challenge bei einer Laufzeit von rund sieben Minuten. Es zeigt, dass der Ansatz auch bei größerem Umfang funktioniert und die Laufzeiten überschaubar bleiben.

Je nach Projekt lässt sich das Tool direkt in die bestehende Deployment-Pipeline einbetten oder als eigenständiges Prüfwerkzeug betreiben - beides setzen wir ein.

Was andere Tests nicht abdecken

In der Softwareentwicklung gibt es verschiedene Ebenen von Tests: Unit Tests prüfen, ob einzelne Funktionen korrekt arbeiten, und Integrationstests prüfen, ob Komponenten zusammenspielen. Beide sind unverzichtbar, aber beide sind blind für das, was der Nutzer tatsächlich sieht.

Ein Button kann technisch einwandfrei funktionieren und trotzdem unter einem anderen Element verschwinden. Ein Formular kann alle Eingaben korrekt verarbeiten und trotzdem so verschoben sein, dass es auf dem Smartphone nicht mehr bedienbar ist. Kein Unit Test fängt das ab.

Visual Regression Testing schließt diese Lücke: Es prüft nicht, ob der Code funktioniert - das tun die anderen Tests. Es prüft, ob das Ergebnis so aussieht, wie es aussehen soll, und ist damit die letzte Prüfinstanz vor dem echten Nutzer.

Reicht manuelles Testen nicht?

Für drei Seiten vielleicht, aber für dreißig nicht - und schon gar nicht nach jedem Update, jedem Hotfix, jedem CMS-Patch.

Manuelle Prüfung findet, was man sucht. Automatische Prüfung findet, was man übersieht.

Visual Regression Testing ersetzt kein manuelles QA, sondern ergänzt es dort, wo Menschen systematisch blind sind: auf den Seiten, die niemand nach dem Deployment öffnet, auf den Breakpoints, die niemand manuell prüft, und bei den Änderungen, die niemand beabsichtigt hat.

Software-Qualität zeigt sich nicht in dem, was man testet - sondern in dem, was man auffängt, bevor es jemand sieht.