Das UI ausliefern, das Sie entworfen haben — nicht das, was unbemerkt durch die CI gerutscht ist

Funktionale Tests beantworten eine Frage gut: „Tut der Button, was er soll, wenn man ihn klickt?“ Alles, was davor passiert, bleibt offen — ob der Button die richtige Farbe hat, die richtige Größe, die richtige Position, auf einem 360-Pixel-Display noch lesbar ist oder nach dem letzten CSS-Refactoring überhaupt noch sichtbar ist. Genau in dieser Lücke leben die meisten Release-Tag-Zwischenfälle.

Echte Regressionen, die wir in der Praxis sehen und für deren Aufdeckung ScanU gebaut ist, folgen wiederkehrenden Mustern:

• Ein CSS-Refactoring lässt das gap eines Flex-Containers auf einem einzelnen Breakpoint kollabieren. Auf dem Desktop sieht das Layout identisch aus; auf einem 768-Pixel-Tablet überlappen sich plötzlich zwei Cards.
• Ein Design-Token-Update verschiebt jeden Spacing-Wert um zwei Pixel. Nichts schlägt fehl; ein Dutzend sorgfältig austarierter Kompositionen sind still und leise nicht mehr austariert.
• Ein Drittanbieter-Widget — ein Cookie-Banner, ein Live-Chat, ein Ad-Slot — veröffentlicht ein stilles Update und verschiebt den ersten Paint. Die Core Web Vitals regressieren über Nacht, ohne dass sich im eigenen Code etwas geändert hätte.
• Ein Framework-Upgrade wechselt den Standard-Font-Feature-Stack. Copy bricht auf Langtext-Seiten um eine halbe Zeile um. Der Hero-CTA rutscht plötzlich unter die Falz.
• Ein Feature-Flag-Rollout ordnet das DOM um. In Safari ändert sich der Stacking-Context eines Modals, und der Schließen-Button wird nicht mehr klickbar. In Chrome sieht alles normal aus.

Keine dieser Änderungen lässt einen Assertion fehlschlagen. Alle führen bei Nutzern zu Problemen. Die Aufgabe von ScanU ist, diese zweite Fehlerklasse genauso sichtbar, prüfbar und blockierbar zu machen wie einen fehlgeschlagenen Unit-Test. Sobald der Diff im Pull Request erscheint, kann eine Designerin ihn genauso kommentieren wie ein Reviewer eine Funktionssignatur — bevor die Änderung gemergt wird, nicht nachdem sie produktiv ist.

Dieser Wechsel — von „hoffentlich merkt es jemand im Staging“ zu „eine visuelle Änderung wird wie Code reviewt“ — ist der eigentliche Mehrwert eines Tools für visuelle Regressionstests in einer modernen Release-Pipeline.

Jeder Durchlauf ist eine dreistufige Pipeline. Zuerst navigiert ScanU in jeder Browser-Engine zur Seite oder Komponente, die getestet werden soll, wartet auf ein konfiguriertes Set an Readiness-Signalen — geladene Schriften, dekodierte Bilder, ruhiges Netzwerk, ein data-ready-Attribut oder eine eigene JavaScript-Probe — und pinnt alle CSS-Animationen auf ihren Endzustand. Anschließend erfasst ScanU die Seite in jedem konfigurierten Viewport im selben Durchlauf — mit Scroll-Stitching bei langen Seiten, damit Sie das vollständige Artefakt erhalten und nicht nur den sichtbaren Bereich. Zuletzt vergleicht die Pipeline die Aufnahme mit der akzeptierten Baseline und liefert pro Browser-Viewport-Paar ein Ergebnis: identisch, innerhalb der Toleranz oder signifikant abweichend.

Der Vergleich selbst ist kein naiver Pixel-Diff. ScanU wendet ein perzeptives Modell an, das Kantenglättung, Subpixel-Rendering und Farbraum-Abweichungen versteht — damit eine Kerning-Eigenheit in WebKit nicht als Bug durchgeht. Für Bereiche, die sich bei jedem Aufruf ändern — Live-Daten, relative Zeitstempel, randomisierte Inhalte, Karussells — lassen sich explizite Masken setzen, sodass diese Zonen null Rauschen zum Diff beitragen.

Wenn eine echte Änderung auftaucht, zeigt die Plattform drei synchronisierte Ansichten: die Baseline, die aktuelle Aufnahme und ein Diff-Overlay, das genau markiert, was sich bewegt hat. Eine einzelne prüfbare Entscheidung — akzeptieren, ablehnen oder Baseline aktualisieren — wird zu jeder Änderung protokolliert, und diese Entscheidung wird Teil der Projekthistorie. Es gibt keinen stillen Drift und kein automatisches Akzeptieren: Die Baseline bewegt sich nur, wenn eine autorisierte Person das ausdrücklich entscheidet.

Dieselbe Pipeline lässt sich über drei Einstiegspunkte steuern: gegen Live-URLs (Produktion, Staging, PR-Previews), gegen eine statische Site oder ein Build-Artefakt und gegen Komponenten-Previews in einer Storybook-ähnlichen Sandbox. Die meisten Teams nutzen den ersten Weg als Release-Gate, den zweiten für Deployment-Artefakte und den dritten für die Arbeit am Design-System — alle drei speisen denselben Baseline-Speicher.

Unabhängig von der Teamgröße führen meist fünf Auslöser zur Einführung von ScanU: ein kürzlicher Produktionsvorfall, den ein visueller Regressionstest abgefangen hätte; eine Design-System-Migration, deren Auswirkungen manuell kaum überprüfbar sind; ein CI/CD-Workflow, der ein Release-Gate jenseits von „Tests bestanden“ braucht; ein kundenorientiertes Deliverable, das Vorher-Nachher-Belege benötigt; oder eine Compliance-Haltung, die EU-gehostete Test-Tools bevorzugt. Eine gemeinsame CI/CD-Integration steht hinter allen fünf — dieselbe Pipeline läuft, ob sie durch einen PR, einen Merge oder einen nächtlichen Zeitplan ausgelöst wird.

ScanU wird in der Europäischen Union entwickelt und betrieben — Speicherung und Verarbeitung erfolgen auf EU-basierter Infrastruktur. Für Teams mit Anforderungen an Datenresidenz — regulierte Branchen, öffentliche Auftraggeber, datenschutz­ sensible B2B-Kunden — ist das häufig eine Beschaffungsvorgabe, keine Präferenz. ScanU erfüllt diese Vorgabe, ohne dass das Produkt an Funktion einbüßt.

Daraus folgen einige bewusst getroffene Designentscheidungen:

• Datensparsamkeit. Die Plattform speichert Screenshots und die Metadaten, die für den Diff nötig sind; sie saugt keinen Seitenquelltext, keine Cookies und keine Request-Bodies ab, die zum Diff nichts beitragen.
• Maskierung in sensiblen Bereichen. Felder, die bekanntlich personenbezogene Daten enthalten — Account-Header, E-Mail-Adressen, Bestellnummern — lassen sich als Masken deklarieren, sodass das erfasste Bild bereits redigiert im Speicher landet.
• Zugriffskontrolle. Wer welchen Diff sehen darf, ist eine erstklassige Berechtigung. Reviewer, Mitwirkende und externe Auditoren bekommen klare Rollen; jede Baseline-Aktualisierung ist mit der freigebenden Person protokolliert.
• Transparenz bei Auftragsverarbeitern. Die Liste der Unterauftragsverarbeiter ist veröffentlicht und versioniert. Keine versteckte Analytics-Pipeline sieht Ihre Screenshots.
• Aufbewahrung, die Sie steuern. Baselines und Diff-Artefakte werden für den Zeitraum vorgehalten, den Sie konfigurieren; alte Durchläufe laufen automatisch ab, statt sich still zu sammeln.

Die vollständige Datenschutz-Haltung — Unterauftragsverarbeiter, regionales Hosting, AVV, Aufbewahrungsfristen — finden Sie in der DSGVO- und Datenverarbeitungs-Dokumentation. Für die meisten Teams zählt die Kurzfassung: Ihre Screenshots bleiben in der EU, und die Plattform ist so gebaut, dass sie dort bleiben.

Visuelle Bugs ballen sich in einer Handvoll wiederkehrender Muster. Jedes wirkt für sich trivial; jedes kann produktiv gehen, ohne einen einzigen roten Test. Alle werden im nächsten ScanU-Durchlauf als Diff sichtbar — bevor der PR gemergt wird.

• Spacing-Verschiebungen. Eine Gap-Utility springt von 16 auf 20 Pixel; ein Card-Grid, das früher ruhig atmete, wirkt auf Mobile plötzlich gedrängt. Das HTML ist unverändert; das Layout nicht.
• Kaputte Layouts nach dem Deployment. Ein Pipeline-Upgrade entfernt ein PostCSS-Plugin, das für das Autoprefixing von backdrop-filter zuständig war. In Safari rendert die Navigation plötzlich deckend, obwohl sie vorher unschärfen sollte.
• CSS-Regressionen durch Spezifitäts-Wechsel. Eine geänderte Tailwind-Klassenreihenfolge, ein neuer Utility-Layer oder eine refaktorierte Kaskade verschieben feinfühlig, welche Regel gewinnt — eine Überschrift verliert ihre Akzentfarbe auf einzelnen Seiten.
• Versagende Responsive-Breakpoints. Ein neuer Nav-Eintrag läuft am Tablet-Breakpoint über und bricht in eine zweite Zeile um, was den Hero auf iPads und großen Android-Telefonen unter die Falz schiebt.
• Rendering-Unterschiede zwischen Browsern. Ein Design, das auf text-wrap: balance setzt, wirkt in Chrome klar, bleibt in Engines, die es noch nicht ausgeliefert haben, jedoch unausgewogen. Ohne einen Cross-Browser-Check ist das auf dem Entwicklerrechner unsichtbar.
• Schrift- und Typografie-Drift. Ein Font-Anbieter tauscht ein Subset, Gewichte verschieben sich um 100 Gramm, und jeder Absatz einer Marketing-Site bricht um ein Viertel Zeile um. Die Textdichte ändert sich; im Code-Repo erklärt das niemand.
• Regressionen bei Drittanbieter-Widgets. Ein Cookie-Banner-Anbieter veröffentlicht ein Update, das den Accept-Button auf dunklen Themes unsichtbar macht. Ihre Conversion-Rate fällt; Ihre Tests bleiben grün.
• Design-System-Drift. Eine Button-Komponente ändert den Offset ihres Focus-Rings. Zwanzig Konsumenten hängen an dieser Komponente. Zwanzig Seiten sehen jetzt dezent anders aus. Niemand reviewt zwanzig Seiten manuell.
• Visuelle Bugs, die in die Produktion entwischen. Alles oben, multipliziert mit den Routen und Breakpoints, die in einer beliebigen Woche niemand öffnet, über die Browser, die im Team täglich niemand benutzt.

Der Funktionsüberblick beschreibt die Erkennungs-Primitive im Detail — perzeptive Toleranzen, maskierte Regionen, Scroll-Capture, Baseline-Branching — und zeigt, welches Primitive welche Kategorie abdeckt. Die Kurzfassung für die meisten Teams: Ändert sich etwas visuell, fällt es ScanU auf; ist es gewünscht, akzeptieren Sie es in einem Klick; ist es ungewünscht, haben Sie es erkannt, bevor andere es bemerken.