Visueller Komponententest (Component Visual Testing): automatisiertes Prüfverfahren, bei dem Komponenten der Benutzeroberfläche isoliert (außerhalb des Kontexts der vollständigen Seite) gerendert und ihr Aussehen mit einem freigegebenen Referenzzustand verglichen wird, um visuelle Regressionen auf Ebene des Design Systems zu erkennen, bevor sie sich auf die Seiten in Produktion auswirken.
Es gibt eine Frage, die Front-End-Teams sorgfältig vermeiden: „Unsere Komponenten werden in Storybook visuell getestet, aber werden auch unsere Seiten in Produktion getestet?“ In den meisten Fällen lautet die Antwort Nein. Und diese Lücke ist teuer, denn die visuellen Bugs, die Ihre Nutzer erreichen, leben nicht in Storybook, sondern in den realen Seiten, mit realen Daten, realen Interaktionen und realen Kombinationen von Komponenten.
Chromatic ist ein hervorragendes Werkzeug, um isolierte Komponenten zu testen. Delta-QA wurde dafür entwickelt, vollständige Seiten zu testen. Eine Einführung in visuelle Tests finden Sie in unserem Leitfaden zur visuellen Regression. Es sind keine Konkurrenten im strengen Sinn, sondern Werkzeuge, die dasselbe Problem aus unterschiedlicher Flughöhe betrachten. Wenn Sie sich aber für eines entscheiden müssen oder verstehen wollen, was jedes davon leistet, kommt dieser Vergleich direkt auf den Punkt.
Alle unsere Vergleiche, anhand überprüfbarer Kriterien: Alternativen und Vergleiche.
Chromatic prüft isolierte Komponenten. Wer testet Ihre realen Seiten in Produktion? Delta-QA deckt sie ab, ohne Code zu schreiben, mit einem kostenlosen Konto und ohne Kreditkarte. Delta-QA kostenlos testen →
Chromatic: der Wächter des Design Systems
Chromatic, entwickelt von den Maintainern von Storybook, ist die natürliche Erweiterung des Storybook-Ökosystems für visuelle Tests. Einen Überblick über visuelle Tests für Design Systems finden Sie in unserem eigenen Leitfaden. Das Konzept ist in seiner Logik brillant: Sie haben Ihre Komponenten in Storybook bereits mit ihren verschiedenen Zuständen (Stories) definiert. Chromatic erstellt bei jedem Commit einen Screenshot jeder Story, vergleicht ihn mit der Baseline und meldet Änderungen.
Für Teams, die mit Design Systems arbeiten, ist das ein perfekt integrierter Workflow. Ihr Designer definiert einen Button mit vier Varianten (primary, secondary, disabled, loading). Ihr Entwickler setzt diese Varianten um und erstellt die passenden Stories. Chromatic prüft bei jeder Codeänderung, dass die vier Varianten visuell nicht regrediert sind. Ändert sich der border-radius des Buttons versehentlich, erkennt Chromatic das, bevor überhaupt jemand ein Code-Review macht.
Das Werkzeug bietet außerdem eine UI-Review-Funktion, mit der Designer und Entwickler Änderungen vor dem Merge visuell freigeben können. Im Kern ist das ein visuelles Code-Review, und es ist wirklich nützlich, um die Konsistenz eines Design Systems zu wahren.
Stand 10/2026 beschränkt sich Chromatic nicht mehr auf Stories: Es führt auch Interaktions- und Barrierefreiheitstests aus, nutzt vorhandene Playwright-, Cypress- oder Vitest-Tests und rendert die Aufnahmen in vier Browsern (Chrome, Firefox, Safari, Edge). Es positioniert sich außerdem als Schutzgeländer für Oberflächen, die von KI-Agenten geschrieben werden, mit einem dokumentierten MCP-Server, der ihnen den Kontext der freigegebenen Komponenten liefert.
Der blinde Fleck von Chromatic: die reale Welt
Hier ist das Problem, das Chromatic nicht löst (nicht aus mangelnder Qualität, sondern aufgrund einer architektonischen Entscheidung): Isolierte Komponenten verhalten sich nicht wie zusammengesetzte Seiten.
Ein in Storybook isoliert getesteter Button wird in einer kontrollierten Umgebung gerendert: festes Viewport, keine Nachbarn, kein vererbter CSS-Kontext, keine dynamischen Daten, keine Interaktion mit anderen Komponenten. Genau das macht den Test auf Komponentenebene zuverlässig. Es macht ihn aber auch blind für Probleme beim Zusammenbau.
Was geht in Produktion visuell kaputt? Selten eine isolierte Komponente. Kaputt geht die Kombination. Eine Header-Komponente, die eine Navigationskomponente überlagert, weil sich ein z-index geändert hat. Ein Produktraster, das aus der Ausrichtung gerät, weil eine Karten-Komponente ein zusätzliches margin erhalten hat. Ein Formular, das aus seinem Container herausläuft, weil ein Label in einer anderen Sprache länger ist als geplant. Ein Footer, der in den Hauptinhalt hineinrutscht, weil ein dazwischenliegender Abschnitt seine Mindesthöhe verloren hat.
Diese Bugs sind in Storybook unsichtbar. Jede Komponente für sich ist visuell korrekt. Ihr Zusammenspiel ist das Problem. Und Chromatic testet konstruktionsbedingt nicht das Zusammenspiel: Es prüft die Bausteine, nicht das Gebäude.
Delta-QA testet das Gebäude. Sie zeichnen einen Ablauf auf Ihrer Website auf, ohne Code, und das Werkzeug spielt ihn bei jeder Version in einem echten Browser ab, mit allen zusammengesetzten Komponenten, ihren vererbten Stilen, ihren Interaktionen und ihren Daten. Jede Seite wird mit ihrer Referenz verglichen, so wie es das menschliche Auge tun würde: Der Bericht sagt, welches Element sich geändert hat (ein Button, der von Blau auf Grün gewechselt ist, ein Abstand, der sich verschoben hat). Das ist der Test der Wirklichkeit, nicht der Test des Architektenplans.
Die Kluft zwischen Storybook und Produktion
Zwischen dem, was Storybook zeigt, und dem, was die Produktion anzeigt, besteht eine strukturelle Lücke, die selten diskutiert wird.
Die Daten. In Storybook erhalten Ihre Komponenten Mock-Daten, sorgfältig so gewählt, dass sie repräsentativ sind und ins Mockup passen. In Produktion erhalten sie reale Daten: einen Produktnamen mit 150 Zeichen, der nicht vorgesehen war, ein Bild mit unwahrscheinlichem Seitenverhältnis, einen Preis mit variabler Anzahl Nachkommastellen, eine Kategorienliste, die drei Zeilen statt einer füllt. Diese realen Daten erzeugen visuelle Situationen, die Storybook nie nachstellt.
Die vererbten Stile. In Storybook wird jede Komponente in einer relativ sauberen CSS-Sandbox gerendert. In Produktion erben Komponenten globale Stile, CSS-Resets, Themes, kontextbezogene Overrides und manchmal Stile von Drittanbietern (Analytics-Widgets, Chatbots, Cookie-Banner). Eine Komponente kann in Storybook perfekt sein und in Produktion visuell kaputt wegen eines Stilkonflikts, den keine Story nachbildet.
Die dynamischen Zustände. Storybook testet vordefinierte Zustände, also diejenigen, die der Entwickler für dokumentierenswert hielt. In Produktion durchlaufen Komponenten Zwischenzustände, unvorhergesehene Fehlerzustände und Zustandskombinationen, an deren Test niemand gedacht hat. Das Formular mit laufender Validierung, der Button in einem Flex-Container, der seine Größe ändert, die Produktkarte mit einer Aktion, die ein Badge hinzufügt: Jede Kombination ist ein visueller Test, den Storybook nicht abdeckt.
Delta-QA testet, was Ihre Nutzer tatsächlich sehen. Nicht das, was Storybook ihnen verspricht.
Ohne Code vs. Storybook: die Frage der Zielgruppe
Chromatic richtet sich an Front-End-Entwickler, die mit Storybook arbeiten. Das ist eine legitime und wichtige Zielgruppe. Aber es ist eine begrenzte Zielgruppe.
Um Chromatic zu nutzen, brauchen Sie im Code geschriebene Tests: Storybook-Stories oder Playwright-, Cypress- oder Vitest-Tests. Sie müssen sie schreiben können. Sie müssen das Konzept von Baseline und visuellem Snapshot verstehen. Sie müssen sich mit einem Workflow auf Basis von Pull Requests und Continuous Integration wohlfühlen. Kurz: Sie müssen Front-End-Entwickler sein.
Ihr QA-Manager, der vor dem Release eine Seite prüfen will? Er kann Chromatic nicht direkt nutzen. Ihr Product Owner, dem in der Abnahme ein visuelles Problem auffällt? Er kann keinen Test starten. Ihre Designerin, die das Mockup mit dem Ergebnis in Produktion vergleichen möchte? Sie hat ohne Entwickler keinen Zugang zum Chromatic-Workflow.
Delta-QA öffnet den visuellen Test für das gesamte Team. Kein Storybook nötig. Kein Code. Keine CI/CD-Pipeline, die man verstehen müsste. Sie navigieren wie ein Nutzer durch Ihre Website, Delta-QA zeichnet das Szenario auf, spielt es bei der nächsten Version erneut ab, und Sie lesen den Bericht. Die QA prüft den Bestellablauf vor der Produktivsetzung. Der Product Owner kontrolliert, dass eine Änderung nirgendwo sonst etwas kaputt gemacht hat. Jeder ist eigenständig.
Für Entwickler, die ihre Seiten aus ihren Playwright-Tests in der CI prüfen lassen wollen, hat Delta-QA inzwischen ein SDK, das SDK Vision: eine Zeile pro zu prüfender Seite, und eine nicht bewertete Abweichung lässt den Test fehlschlagen.
Das ist keine technologiefeindliche Haltung. Es ist die Anerkennung, dass visuelle Qualität alle angeht und dass Werkzeuge diese Realität widerspiegeln sollten.
Komponenten vs. Seiten: zwei komplementäre Testebenen
Statt Chromatic und Delta-QA gegeneinander auszuspielen, ist es treffender, sie als zwei Ebenen einer vollständigen Strategie für visuelle Tests zu verstehen.
Komponentenebene (Chromatic): prüfen, dass jeder Baustein des Design Systems visuell seinen Spezifikationen entspricht. Das ist der Unit-Test des Visuellen. Er erkennt Regressionen auf der feinsten Ebene, so früh wie möglich im Entwicklungszyklus (sogar vor dem Merge).
Seitenebene (Delta-QA): prüfen, dass die zusammengesetzten Seiten mit realen Daten und kaskadierenden Stilen visuell korrekt sind. Das ist der Integrationstest des Visuellen. Er erkennt Probleme beim Zusammenbau, Stilkonflikte und Regressionen, die nur im Kontext der vollständigen Seite existieren.
Ein Team, das beides tut, hat eine bemerkenswerte visuelle Abdeckung. Komponentenregressionen werden früh von Chromatic erkannt. Seitenregressionen werden von Delta-QA erkannt. Das Sicherheitsnetz ist doppelt.
Wenn Sie aber nur eines wählen können (aus Budget-, Zeit- oder Ressourcengründen), lautet die Frage: Welche Testebene schützt Ihre Nutzer am besten? Und die Antwort ist eindeutig die Seitenebene. Denn Ihre Nutzer sehen keine Komponenten. Sie sehen Seiten.
Cloud oder On-Premise: wohin gehen Ihre Aufnahmen?
Über das Modell Komponenten/Seiten hinaus gibt es einen Architekturunterschied, der für manche Organisationen schwer wiegt: der Ort, an dem Ihre Screenshots liegen.
Chromatic ist ein Cloud-Dienst. Ihre Screenshots werden an die Infrastruktur von Chromatic gesendet und dort gespeichert; Stand 10/2026 nennt die Preisübersicht kein Self-Hosted-Deployment, auch nicht im Enterprise-Plan (der SSO, SLA und Einstellungen zur Datenaufbewahrung bietet). Für die meisten öffentlichen Projekte ist das kein Problem. Für eine interne Anwendung, ein Back-Office mit Kundendaten oder eine Organisation mit strengen regulatorischen Vorgaben kann allein die Tatsache, dass Screenshots der Oberfläche den Unternehmensperimeter verlassen, ein Ausschlusskriterium sein.
Delta-QA bietet ein On-Premise-Angebot, installiert per Docker auf Ihrer Infrastruktur: Ihre Aufnahmen verlassen Ihr Netzwerk nicht, und das Angebot lässt sich mit einem kostenlosen POC über einen Monat evaluieren. Das ist dieselbe Logik wie die weiter unten beschriebene Datensouveränität, hier auf Architekturebene formuliert: data stays vs. data leaves.
Das Geschäftsmodell: Abrechnung pro Snapshot
Chromatic rechnet nach der Anzahl der Snapshots pro Monat ab. Ein Snapshot = eine Story, ein Browser, eine Auflösung. Bei 200 Komponenten mit je 3 Stories auf 2 Browsern sind das 1.200 Snapshots pro Build. Bei zwanzig Builds pro Tag (ein aktives Team) sind es 720.000 pro Monat.
Stand 10/2026 bietet der kostenlose Plan 5.000 abgerechnete Snapshots pro Monat, genug für einen ersten Umfang, der aber schnell aufgebraucht ist, wenn das Design System wächst. Und dieser kostenlose Plan ist auf Chrome beschränkt: Cross-Browser-Tests (Firefox, Safari, Edge) beginnen beim Starter-Plan, für 179 $/Monat bei 35.000 Snapshots. Der Pro-Plan kostet 399 $/Monat bei 85.000 Snapshots, jeder zusätzliche Snapshot wird mit 0,008 $ berechnet, und Enterprise gibt es auf Anfrage. TurboSnap dämpft die Rechnung: Nur Tests, die von einer Dateiänderung betroffen sind, werden neu aufgenommen, die anderen zählen weniger auf das Kontingent. Konkret: 180 Stories × 3 Auflösungen = 540 Snapshots pro Build, also gerade einmal 9 Builds, bis das kostenlose Kontingent erschöpft ist. Und das erzeugt dieselbe Spannung wie bei Percy: Die Testabdeckung ist umgekehrt proportional zum Budget. Ohne TurboSnap begrenzen Teams am Ende die getesteten Stories oder die Build-Häufigkeit, um im Kontingent zu bleiben.
Delta-QA startet mit einem kostenlosen Konto, ohne Kreditkarte. Die Abdeckung bemisst sich nach Abläufen und geprüften Schritten, nicht nach Stories multipliziert mit Browsern und Auflösungen.
Chromatic testet isolierte Komponenten. Und Ihre vollständigen Seiten? Delta-QA deckt sie ohne Code und ohne Kreditkarte ab. Delta-QA kostenlos testen →
Was Chromatic kann und Delta-QA nicht
Transparenz verlangt, die besonderen Stärken von Chromatic anzuerkennen.
Das kollaborative UI-Review. Der Workflow von Chromatic erlaubt Entwicklern und Designern, Komponentenänderungen im Rahmen eines Pull Requests visuell freizugeben. Das ist ein integrierter Review-Prozess, für den es in Delta-QA keine exakte Entsprechung gibt.
Der Test aller Zustände einer Komponente. Hat Ihr Button 12 Varianten (Größe, Farbe, Zustand, Theme), testet Chromatic sie alle systematisch. Diese 12 Varianten auf Seitenebene zu testen, würde erfordern, 12 verschiedene Seiten zu finden, auf denen sie vorkommen, was nicht immer möglich ist.
Multi-Browser. Chromatic erfasst Ihre Tests in Chrome, Firefox, Safari und Edge (ab dem Starter-Plan). Delta-QA vergleicht heute auf Chromium; Firefox und WebKit sind geplant.
Die native Storybook-Integration. Chromatic stammt von den Machern von Storybook. Die Integration ist so tief wie möglich: automatische Erkennung neuer Stories, minimale Konfiguration, flüssiger Workflow. Das ist ein echter Vorteil, wenn Storybook im Zentrum Ihres UI-Entwicklungsworkflows steht.
Die lebendige visuelle Dokumentation. Chromatic führt eine visuelle Historie jeder Komponente über die Zeit. Das ist eine lebendige Design-Bibliothek, die die Entwicklung jeder Komponente zeigt, eine wertvolle Funktion für Design Systems.
Was Delta-QA bietet und Chromatic nicht abdeckt
Der Test der Wirklichkeit. Die Seiten in Produktion, mit echten Daten, echten vererbten Stilen und echten Interaktionen zwischen Komponenten. Nicht die saubere Idealisierung von Storybook, sondern die Welt, wie sie ist.
Universelle Zugänglichkeit. Jedes Teammitglied kann einen visuellen Test starten. Man muss kein Entwickler sein, Storybook nicht kennen und keinen Zugang zur CI-Pipeline haben. Die Demokratisierung des visuellen Tests.
Technologieunabhängigkeit. Delta-QA funktioniert unabhängig von Ihrem Front-End-Stack. React, Vue, Angular, Svelte, WordPress, Shopify, statische Website, Legacy-Anwendung in jQuery, egal. Wenn es in einem Browser angezeigt wird, testet Delta-QA es. Chromatic stützt sich auf im Code geschriebene Tests (Storybook, Playwright, Cypress, Vitest), also auf ein Front-End-Projekt, das dafür ausgestattet ist.
Datensouveränität. Mit dem On-Premise-Angebot läuft der Vergleich auf Ihrer Infrastruktur, und keine Aufnahme wird an Dritte gesendet. Für interne Anwendungen, sensible Daten und Organisationen mit strengen Vorschriften.
Ein Bericht wie mit dem menschlichen Auge. Jede Abweichung ist einem Seitenelement zugeordnet und im Klartext beschrieben: die Farbe, der Abstand, die Schrift, die Position. Sie wissen, wohin Sie schauen müssen, ohne ein Differenzbild interpretieren zu müssen.
Das ideale Szenario: beide zusammen
Wenn Ihr Team bereits Storybook nutzt und das Budget für Chromatic hat, ist die Kombination beider Werkzeuge die robusteste Strategie.
Chromatic überwacht Ihre Komponenten auf Ebene des Design Systems. Jede Stiländerung, jede Variation, jeder Zustand wird visuell geprüft. Regressionen werden zur Entwicklungszeit erkannt, bevor der Code den Hauptbranch erreicht.
Delta-QA überwacht Ihre Seiten in Produktion (oder im Staging). Probleme beim Zusammenbau, Stilkonflikte und Bugs, die nur im realen Kontext auftreten, werden erkannt, bevor die Nutzer sie sehen.
Zusammen ergibt das eine doppelte Abdeckung: die Bausteine auf der einen Seite, die zusammengesetzten Abläufe auf der anderen.
Das pragmatische Szenario: nur ein Werkzeug
Wenn Sie nur ein Werkzeug wählen können (weil das Budget begrenzt ist, weil das Team klein ist oder weil Sie einfach anfangen möchten), lässt sich die Frage so zusammenfassen: Was schützt Ihre Nutzer am besten?
Ihre Nutzer sehen Ihre Storybook-Komponenten nicht. Sie sehen Ihre Seiten. Sie interagieren mit Ihren Seiten. Sie bilden sich ihre Meinung über Ihr Produkt, indem sie Ihre Seiten betrachten. Eine Komponente, die in Storybook perfekt ist, aber in der zusammengesetzten Seite kaputt, ist aus Nutzersicht eine kaputte Komponente.
Delta-QA testet, was Ihre Nutzer sehen. So einfach ist das.
Bereit, die Seiten zu testen, die Ihre Nutzer wirklich sehen? Starten Sie Ihren ersten Vergleich mit Delta-QA, mit einem kostenlosen Konto und ohne Kreditkarte. Delta-QA kostenlos testen →
FAQ
Funktioniert Chromatic ohne Storybook?
Ja. Stand 10/2026 erfasst Chromatic zusätzlich zu den Storybook-Stories auch die Seiten Ihrer Playwright-, Cypress- oder Vitest-Tests. Es braucht jedoch im Code geschriebene Tests: Sie bestimmen, was aufgenommen wird. Delta-QA geht von einem ohne Code aufgezeichneten Szenario aus, unabhängig vom Stack, der Ihre Seiten erzeugt; für Playwright-Tests bietet es sein SDK Vision.
Genügt es, Komponenten in Storybook zu testen, um visuelle Qualität zu garantieren?
Nein. Isoliert getestete Komponenten bilden die realen Bedingungen einer zusammengesetzten Seite nicht ab: Stilvererbung, dynamische Daten, Interaktionen zwischen Komponenten, Stile von Drittanbietern. Chromatic prüft, dass Ihre Bausteine korrekt sind. Delta-QA prüft, dass der Zusammenbau korrekt ist. Beide Ebenen sind für eine vollständige Abdeckung nötig.
Erkennt Chromatic Responsive-Probleme?
Ja, im Rahmen dessen, was Storybook zeigt. Sie können Ihre Stories für verschiedene Viewport-Größen konfigurieren, und Chromatic testet sie. Responsive-Probleme, die speziell in einer zusammengesetzten Seite auftreten (ein Element, das in Kombination mit anderen überläuft, ein Layout, das mit langen realen Daten bricht), werden jedoch nicht erkannt. Delta-QA dagegen vergleicht die zusammengesetzte Seite in einem echten Browser mit ihren realen Daten.
Was deckt der kostenlose Plan von Chromatic ab?
Stand 10/2026 bietet der kostenlose Plan von Chromatic 5.000 abgerechnete Snapshots pro Monat, nur auf Chrome, was einige Dutzend Komponenten bei gelegentlichen Builds abdeckt. Sobald die Zahl der Komponenten oder die Build-Häufigkeit steigt, ist das Kontingent schnell erreicht. Ein Projekt mit 100 Komponenten, 3 Stories pro Komponente und 2 täglichen Builds verbraucht ohne TurboSnap etwa 18.000 Snapshots pro Monat.
Kann man Delta-QA zum Testen isolierter Komponenten nutzen?
Delta-QA ist für vollständige Seiten optimiert, nicht für isolierte Komponenten. Wenn Sie eine Umgebung haben, in der Ihre Komponenten einzeln unter erreichbaren URLs gerendert werden (etwa ein bereitgestelltes Storybook), können Sie Delta-QA technisch für den Vergleich nutzen. Das ist aber nicht der Hauptanwendungsfall. Für den Test isolierter Komponenten bleibt Chromatic das Referenzwerkzeug.
Wie geht Delta-QA mit Design Systems um, wenn nicht auf Komponentenebene?
Delta-QA prüft die visuelle Konsistenz Ihres Design Systems auf der Ebene, auf der sie am meisten zählt: in den Seiten, die es verwenden. Wenn eine Änderung in Ihrem Design System das Layout von zehn Seiten zerstört, erkennt Delta-QA das direkt. Es ist ein End-to-End-Test des Design Systems, komplementär zum Unit-Test von Chromatic.