Screenshot-Diffing vs. Intent-Based Verification: Was fängt echte Bugs?

Screenshot-Diffing-Tools wie Percy und Chromatic fangen jede Pixel-Änderung — aber die meisten davon sind keine Bugs. Intent-Based Verification mit Aletiq fragt stattdessen: „Funktioniert die Software noch wie beabsichtigt?" Der Unterschied: weniger False Positives, mehr echte Bugs gefunden, kein manuelles Approval-Rauschen.

Dieser Artikel vergleicht beide Ansätze mit konkreten Zahlen: was sie finden, was sie übersehen, was sie kosten — und wann welcher Ansatz der richtige ist.

Was ist Screenshot-Diffing und wie funktioniert es?

Screenshot-Diffing vergleicht zwei Bilder derselben Seite: eine Baseline (der akzeptierte Zustand) und einen neuen Screenshot (nach einer Code-Änderung). Jeder Pixel-Unterschied wird markiert.

Die bekanntesten Tools:

• Percy (BrowserStack) — Macht Screenshots in verschiedenen Browsern und Viewports, vergleicht gegen die Baseline und zeigt Diffs im Dashboard. Ab 399 Dollar pro Monat für 25.000 Snapshots.
• Chromatic (Storybook) — Spezialisiert auf Component-Level-Screenshots in Storybook. Vergleicht jede Story gegen ihre Baseline. Ab 149 Dollar pro Monat für 35.000 Snapshots.
• Applitools — AI-unterstütztes Visual Testing mit „Visual AI" für intelligentere Diff-Erkennung. Enterprise-Pricing.

Der Workflow ist bei allen ähnlich:

1. CI-Pipeline macht Screenshots der aktuellen Version
2. Tool vergleicht gegen gespeicherte Baseline
3. Diffs werden im Dashboard angezeigt
4. Ein Teammitglied reviewed jeden Diff: „Akzeptieren" oder „Ablehnen"
5. Akzeptierte Screenshots werden zur neuen Baseline

Das Prinzip ist simpel und intuitiv. Das Problem liegt nicht im Konzept, sondern im Signal-to-Noise-Ratio.

Warum liefern Screenshot-Diffs so viele False Positives?

Weil nicht jede Pixel-Änderung ein Bug ist — aber Screenshot-Diffing keinen Unterschied kennt. Typische False-Positive-Rate bei Visual Regression Testing: 15 bis 30 Prozent aller Diffs sind keine echten Bugs.

Die häufigsten Ursachen für False Positives:

• Font-Rendering-Unterschiede — Verschiedene Betriebssysteme und Browser rendern Schriften minimal unterschiedlich. Sub-Pixel-Rendering auf macOS vs. Windows erzeugt Diffs, die kein Mensch mit bloßem Auge sehen würde.
• Anti-Aliasing-Variationen — Kanten von Elementen, abgerundete Ecken und Schatten werden je nach GPU und Rendering-Engine unterschiedlich geglättet. Jedes CI-Update kann neue Diffs erzeugen.
• Dynamische Inhalte — Datum, Uhrzeit, zufällige Avatare, personalisierte Empfehlungen, Werbebanner. Alles, was sich bei jedem Seitenaufruf ändert, erzeugt einen Diff — obwohl es korrekt funktioniert.
• Layout-Shift bei identischer Funktion — Ein AI-Agent refactored eine Komponente und ändert den Abstand zwischen zwei Elementen um 2 Pixel. Das Layout hat sich geändert, die Funktion nicht. Trotzdem: Diff.
• Gewollte Änderungen — Du änderst den Button-Text von „Start Free" zu „Get Started". Screenshot-Diffing meldet das als Abweichung von der Baseline. Du musst es manuell als „gewollt" akzeptieren.

Das Ergebnis: Ein Dashboard voller gelber und roter Markierungen, von denen die Mehrheit kein echter Bug ist. Jeder Diff will reviewed und approved werden — von einem Menschen.

Was passiert wenn das Team Diff-Fatigue bekommt?

Genau das, was bei jedem Alarm-System mit zu vielen Fehlalarmen passiert: Das Team hört auf hinzuschauen.

Der typische Verlauf:

1. Monat 1: Das Team reviewed jeden Diff sorgfältig. Jede Abweichung wird diskutiert. Die Motivation ist hoch.
2. Monat 3: Von 200 Diffs pro Woche sind 150 False Positives. Das Team beginnt, Diffs in Batches zu akzeptieren, ohne jeden einzeln zu prüfen.
3. Monat 6: Ein Teamkollege ist der designierte „Diff-Approver". Die Aufgabe wird als lästig empfunden. Die Approval-Zeit pro Diff sinkt auf unter 2 Sekunden.
4. Monat 9: Ein echter Bug rutscht durch, weil er in einem Batch von 40 Diffs akzeptiert wurde. Niemand hat den Diff mit dem kaputten Checkout gesehen, weil er zwischen Font-Rendering-Artefakten versteckt war.

Diff-Fatigue ist kein Edge Case — es ist der Regelfall bei Teams, die Screenshot-Diffing im Produktionsalltag einsetzen. Das Tool funktioniert technisch einwandfrei. Aber es produziert so viel Rauschen, dass das Signal untergeht.

Und in Codebases mit AI-generierten Änderungen verschärft sich das Problem: Jeder AI-Rewrite erzeugt Dutzende visuelle Diffs, von denen die allermeisten gewollte oder irrelevante Änderungen sind.

Was ist Intent-Based Verification?

Intent-Based Verification prüft nicht, wie eine Seite aussieht, sondern ob sie das tut, was sie soll. Statt Pixel zu vergleichen, bewertet sie Verhalten gegen einen definierten Zweck.

Aletiq implementiert diesen Ansatz mit einer dreistufigen Architektur:

• Planner — Übersetzt deinen Intent in natürlicher Sprache in einen Ausführungsplan und definiert Bewertungskriterien.
• Runner — Führt den Plan aus: navigiert die Seite, macht Screenshots, sammelt DOM-Daten, klickt Buttons, folgt Links. Deterministisch, keine AI-Entscheidungen.
• Judge — Eine Multi-Model-Jury aus drei LLMs (Claude, Gemini, GPT) bewertet die Beobachtungen einstimmig gegen den Intent. Ergebnis: PASS, UNCLEAR oder FAIL.

Ein Beispiel:

aletiq verify "The checkout flow should be completable from the product page" --url https://myshop.com/product/123

Aletiq navigiert zur Produktseite, klickt „Add to Cart", geht zum Checkout, prüft ob alle Schritte erreichbar sind und ob der Flow funktional komplett ist. Ob der Button dabei blau oder grün ist, ob der Font 2 Pixel größer gerendert wird oder ob ein AI-Agent das Layout komplett umgebaut hat — ist egal. Solange der Checkout funktioniert: PASS.

Die technischen Details — Gewaltenteilung, Verification Levels, Benchmark-Ergebnisse — beschreiben wir ausführlich im Vergleich von Playwright und Aletiq.

Wie unterscheidet Aletiq einen Bug von einer gewollten Änderung?

Durch Kontext — konkret durch das Profile, das du für dein Projekt definierst. Das Profile beschreibt, was deine Software ist und was sie tun soll. Es ist der Maßstab, gegen den alles bewertet wird.

Beispiel ohne Profile:

aletiq verify "The hero section should have a visible CTA" --url https://myapp.com

Der Judge prüft nur: Gibt es einen sichtbaren CTA im Hero? Ja oder nein.

Beispiel mit Profile:

Das Profile sagt: „Diese App ist ein SaaS-Tool für Projektmanagement. Die Landing Page soll Besucher zur kostenlosen Testversion führen."

Jetzt prüft der Judge nicht nur, ob ein CTA existiert, sondern ob er im Kontext sinnvoll ist. Ein CTA, der zu einer 404-Seite führt: FAIL. Ein CTA, dessen Text von „Start Free Trial" zu „Try Free for 14 Days" geändert wurde: PASS — die Intention ist erfüllt, auch wenn sich der Text geändert hat.

Screenshot-Diffing hätte bei der Textänderung einen Diff gemeldet. Aletiq erkennt: Das ist eine Verbesserung, kein Bug. Kein Approval nötig, kein Rauschen im Dashboard.

Bei einem kaputten Link dagegen hätte Screenshot-Diffing keinen Diff angezeigt — visuell sieht die Seite identisch aus. Aletiq erkennt: Der CTA führt ins Leere. FAIL.

Welche Bugs findet Screenshot-Diffing nicht?

Alle Bugs, die visuell unsichtbar sind — und das sind oft die teuersten. Screenshot-Diffing vergleicht Bilder, nicht Verhalten.

Funktionale Fehler hinter korrektem Layout:

• Toter Link — Der Button sieht perfekt aus, hat die richtige Farbe und den richtigen Text. Aber das href-Attribut ist leer oder zeigt auf eine 404. Visuell: kein Diff. Funktional: komplett kaputt.
• Falscher Redirect — „Pricing" verlinkt auf „/about" statt „/pricing". Der Link sieht identisch aus. Screenshot-Diffing sieht die Seite, auf die navigiert wird, nicht.
• Button ohne Click-Handler — Ein AI-Agent refactored eine Komponente und vergisst den onClick-Handler. Der Button rendert korrekt, tut aber nichts. Pixel-perfekt, funktional tot.
• Fehlende Daten hinter korrektem Layout — Das Dashboard zeigt „0" für alle Metriken, weil der API-Call fehlschlägt. Das Layout ist korrekt, die Daten fehlen komplett. Screenshot-Diffing meldet keinen Diff, weil das Layout der Baseline entspricht — die Baseline hatte auch Zahlen, aber der Diff-Algorithmus prüft nicht den semantischen Inhalt.
• Falsche Formularberechnung — Der Warenkorb zeigt „Gesamt: 0,00 €" statt der korrekten Summe. Das Layout stimmt, die Zahl ist falsch. Ein Pixel-Vergleich sieht eine Zahl an der richtigen Stelle — Diff nur wenn die Baseline eine andere Zahl hatte.

Diese Kategorie von Bugs — visuell korrekt, funktional kaputt — macht einen erheblichen Anteil realer Produktionsfehler aus. Intent-Based Verification findet sie, weil sie Verhalten prüft, nicht Pixel.

Welche Bugs findet Intent-Verification nicht?

Ehrliche Einschätzung: Intent-Verification ist bei rein visuellen Problemen schwächer als Screenshot-Diffing.

• Subtile Farbabweichungen — Dein Brand-Blau (#1a73e8) wurde durch einen AI-Rewrite zu einem leicht anderen Blau (#2979ff). Funktional irrelevant, aber ein Brand-Guideline-Verstoß. Aletiq erkennt das nur, wenn dein Intent explizit Farbe thematisiert — Screenshot-Diffing findet es automatisch.
• Pixel-perfekte Design-Compliance — 2 Pixel Abstand statt 4 Pixel zwischen Elementen. Für einen Designer ein Fehler, für Intent-Verification unsichtbar.
• Typografie-Fehler — Falscher Font-Weight (400 statt 600), falscher Line-Height. Funktional irrelevant, visuell störend. Screenshot-Diffing fängt das, Intent-Verification nicht.
• Cross-Browser-Rendering — Wenn deine App auf Chrome anders aussieht als auf Safari, findet Percy das durch parallele Screenshots. Aletiq verifiziert Verhalten, nicht Rendering-Konsistenz.

Die True Negative Rate von Aletiq liegt im Benchmark bei 78,7 Prozent — subtile visuelle Abweichungen sind der häufigste Grund für verpasste Fehler. Das Ziel für den Launch liegt bei 99,9 Prozent, aber rein visuelle Probleme ohne funktionale Auswirkung bleiben eine Schwäche des Intent-basierten Ansatzes.

Wenn Pixel-Perfektion und Design-System-Compliance dein primäres Ziel sind, ist Screenshot-Diffing das bessere Werkzeug.

Was kostet visuelles Testen mit Percy oder Chromatic?

Mehr als nur die Tool-Kosten — die versteckte Zeitinvestition für Approvals ist oft der größere Posten.

Tool-Kosten:

Versteckte Kosten bei Screenshot-Diffing:

• Approval-Zeit — Bei 200 Diffs pro Woche und 15 bis 30 Prozent False Positives muss ein Teammitglied 30 bis 60 irrelevante Diffs pro Woche reviewen und akzeptieren. Bei 2 Minuten pro Diff: 1 bis 2 Stunden pro Woche nur für False-Positive-Approval.
• Baseline-Management — Jeder akzeptierte Diff wird zur neuen Baseline. Bei 10 Browsern und 5 Viewports pro Seite wächst die Baseline-Bibliothek schnell. Veraltete Baselines müssen regelmäßig aufgeräumt werden.
• CI-Pipeline-Zeit — Screenshots machen dauert. Bei 50 Seiten × 10 Browser/Viewport-Kombinationen sind das 500 Screenshots pro Pipeline-Run. Das verlängert die CI-Pipeline um Minuten bis zweistellige Minutenbereiche.

Aletiq hat keine Approval-Schleife. Das Verdict ist PASS, UNCLEAR oder FAIL — keine Baseline, die approved werden muss, kein Dashboard voller Diffs, kein wöchentlicher Approval-Marathon.

Kann ich Screenshot-Diffing und Intent-Verification kombinieren?

Ja — und für viele Teams ist die Kombination besser als jeder Ansatz allein.

Screenshot-Diffing für:

• Design-System-Compliance — Storybook-Komponenten gegen Design-Spezifikation prüfen
• Cross-Browser-Konsistenz — Sicherstellen, dass Chrome und Safari dasselbe rendern
• Brand-Guidelines — Farben, Fonts, Abstände automatisch gegen den Styleguide validieren

Aletiq für:

• Funktionale Verification — „Funktioniert der Checkout?", „Kommt der User zur Pricing-Seite?"
• AI-generierte Code-Changes — Intents bleiben stabil, auch wenn ein AI-Agent die gesamte UI umschreibt
• CI/CD-Gates — Blockiere Merges bei funktionalen Regressionen, nicht bei visuellen Abweichungen
• Schnelle Iteration — Kein Approval-Overhead, Ergebnis in 4,5 Sekunden

Die Faustregel: Screenshot-Diffing antwortet auf die Frage „Sieht es noch richtig aus?" Aletiq antwortet auf „Funktioniert es noch richtig?" Beides sind legitime Fragen — aber bei AI-generiertem Code ist die zweite die dringendere.

Wie starte ich mit Intent-Based Verification?

Ein Befehl, kein Dashboard-Setup, keine Baseline-Konfiguration:

aletiq verify "The main navigation should lead to all major sections" --url https://myapp.com

In 4,5 Sekunden bekommst du ein Verdict mit Begründung und Evidenz. Kein Diff zum Reviewen, kein Approval-Button, keine Baseline zum Akzeptieren.

Drei Schritte zum Start:

1. Definiere deine kritischen Intents — Was muss deine App auf jeden Fall können? Checkout funktioniert, Signup ist erreichbar, Pricing-Seite zeigt aktuelle Preise. Starte mit 5 bis 10 Intents.
2. Integriere in deinen Workflow — CLI im Dev-Loop, MCP-Integration für AI-Agents, oder CI-Gate in GitHub Actions. Aletiq passt sich deinem Workflow an, nicht umgekehrt.
3. Skaliere nach Bedarf — Der Free Tier bietet 50 Verifications pro Monat. Pro (99 Dollar/Monat) gibt dir 500, Team (299 Dollar/Monat) gibt dir 2.000. Starte kostenlos und skaliere, wenn du den Wert siehst.

Wenn du bereits Percy oder Chromatic nutzt, musst du nicht wechseln. Füge Aletiq als funktionale Verification-Schicht hinzu — neben dem visuellen Testing, das du bereits hast. Screenshot-Diffing für Pixel, Aletiq für Intent.

Probiere Aletiq jetzt aus: aletiq verify auf deinem Projekt — in 5 Sekunden weißt du, ob deine Software noch das tut, was sie soll.