Visuelles Testen in einem Scrum-Workflow bezeichnet die systematische Integration automatisierter Überprüfungen der Benutzeroberfläche — durch Vergleich von Screenshots mit validierten Referenzen — in jeder Sprint-Phase, von der Entwicklung bis zur Sprint Review.
Seien wir direkt: Die meisten Scrum-Teams testen nicht visuell. Sie haben Unit-Tests, Integrationstests, manchmal End-to-End-Tests. Sie haben einen Product Owner, der User Stories in der Sprint Review auf seinem 27-Zoll-Bildschirm validiert. Und sie liefern visuelle Regressionen in die Produktion, die niemand gesehen hat, weil niemand danach gesucht hat.
Das ist kein Kompetenzproblem. Es ist ein Prozessproblem. Visuelles Testen hat keinen definierten Platz im Scrum-Workflow. Es steht weder in den Akzeptanzkriterien noch in der Definition of Done noch in den Zeremonien. Es schwebt in einem methodischen Niemandsland, eingeklemmt zwischen „das ist die Aufgabe des Entwicklers" und „die QA kümmert sich darum".
Ergebnis: Niemand kümmert sich darum. Und wenn ein visueller Bug in die Produktion gelangt, fragt sich jeder, wie er durchs Netz schlüpfen konnte.
Dieser Leitfaden zeigt Ihnen eine konkrete Integration des visuellen Testens in jede Phase Ihres Sprints. Keine abstrakte Theorie. Präzise Maßnahmen, klare Verantwortlichkeiten und eine klare Überzeugung: „Visueller Test bestanden" muss in Ihrer Definition of Done stehen.
Warum Scrum einen visuellen blinden Fleck hat
Scrum ist ein außerordentlich effektives Framework für die iterative Wertlieferung. Aber es wurde in einer Zeit konzipiert, als Benutzeroberflächen weniger komplex, weniger dynamisch und weniger entscheidend für die wahrgenommene Qualität durch den Endnutzer waren.
Der Sprint fokussiert auf Funktionalität, nicht auf Erscheinung
Wenn Sie eine User Story schreiben, beschreiben Sie ein Verhalten: „Als Nutzer möchte ich Ergebnisse nach Datum filtern können." Die Akzeptanzkriterien beziehen sich auf die Funktionsweise: Der Filter funktioniert, die Ergebnisse sind korrekt, Grenzfälle werden behandelt.
Niemand schreibt: „Der Filter muss auf Mobilgeräten korrekt angezeigt werden, den angrenzenden Inhalt nicht verschieben, das Design System einhalten und das Layout der Seitenleiste nicht beeinträchtigen." Das ist implizit. Und was implizit ist, wird nicht getestet.
Die Sprint Review ist eine visuelle Falle
Die Sprint Review soll der Moment sein, in dem das Team zeigt, was erledigt wurde, und der Product Owner validiert. Theoretisch ist es die Gelegenheit, visuelle Probleme zu erkennen.
In der Praxis ist es der schlechteste Zeitpunkt dafür.
Die Demonstration findet in einer bestimmten Umgebung statt, mit einem bestimmten Browser und einer bestimmten Auflösung. Der PO betrachtet den funktionalen Ablauf, nicht die visuellen Details. Das Team zeigt die funktionierenden Fälle, nicht die Seiten, die es nicht angefasst hat, die aber durch Seiteneffekte betroffen sein könnten.
Die Sprint Review ist ein funktionaler Filter, kein visueller Filter. Sich darauf zu verlassen, um visuelle Regressionen zu erkennen, ist wie sich auf eine Flughafensicherheitskontrolle zu verlassen, um die Qualität Ihres Koffers zu prüfen.
Klassische automatisierte Tests sehen nicht, was der Nutzer sieht
Ihre Cypress- oder Playwright-Tests prüfen, ob Elemente im DOM existieren und Interaktionen funktionieren. Sie prüfen nicht, ob der Button sichtbar ist, ob der Text das Bild überlagert oder ob eine CSS-Variablenänderung einen unerwünschten Effekt auf zehn Komponenten verbreitet hat.
Der Unit-Test validiert die Logik. Der Integrationstest validiert die Verbindungen. Der End-to-End-Test validiert die Abläufe. Keiner validiert, was der Nutzer sieht.
Wann visuell getestet werden sollte: Der visuelle Shift-Left
Das Shift-Left-Konzept — so früh wie möglich im Entwicklungszyklus testen — lässt sich perfekt auf visuelles Testen anwenden. Aber „so früh wie möglich" bedeutet nicht „irgendwann".
Während der Entwicklung: die erste Verteidigungslinie
Der ideale Zeitpunkt, um eine visuelle Regression zu erkennen, ist, wenn der Entwickler noch im Kontext seiner Änderung arbeitet. Er kennt den Code, den er angefasst hat, weiß, welche Komponenten betroffen sind, und kann sofort korrigieren.
Der visuelle Test muss bei jedem Push auf den Entwicklungsbranch automatisch ausgelöst werden. Nicht in drei Tagen beim Merge. Nicht in der Sprint Review, wenn der Entwickler schon bei etwas anderem ist. Jetzt, während er programmiert.
Konkret bedeutet das, visuelles Testen in Ihre CI/CD-Pipeline zu integrieren, sodass es bei jedem Pull Request oder Merge Request ausgeführt wird. Der Entwickler pusht seinen Code, der visuelle Test vergleicht die Screenshots des Branches mit den validierten Referenzen, und das Ergebnis erscheint direkt im Merge Request.
Wenn ein visueller Unterschied erkannt wird, sieht der Entwickler ihn sofort. Er kann ihn validieren (es ist eine beabsichtigte Änderung) oder korrigieren (es ist eine Regression). Die Korrekturkosten sind quasi null, weil er noch im Kontext ist.
Beim Merge in den Hauptbranch: das Sicherheitsnetz
Selbst mit Tests auf jedem Branch kann der Merge in den Hauptbranch visuelle Regressionen erzeugen. Zwei individuell korrekte Branches können nach der Kombination ein visuell fehlerhaftes Ergebnis liefern.
Der visuelle Test muss auch nach jedem Merge in den Hauptbranch ausgeführt werden. Das ist Ihr Sicherheitsnetz. Wenn eine Regression die Branch-Tests übersteht, aber beim Merge auftritt, wird sie erkannt, bevor sie Staging- oder Produktionsumgebungen erreicht.
Vor der Sprint Review: die abschließende Überprüfung
Die Sprint Review sollte nicht der Moment sein, in dem Sie visuelle Probleme entdecken. Sie sollte der Moment sein, in dem Sie bestätigen, dass alles sauber ist.
Führen Sie vor jeder Sprint Review eine vollständige Suite visueller Tests in der Demonstrationsumgebung durch. Wenn Unterschiede erkannt werden, behandelt das Team sie vor der Review. Der Product Owner sieht ein visuell validiertes Produkt, keinen Entwurf.
Wer visuell testet: klare Verantwortlichkeiten
Einer der Gründe, warum visuelles Testen in den meisten Scrum-Teams nicht durchgeführt wird, ist, dass niemand weiß, wer dafür zuständig ist. Klären wir das.
Der Entwickler: erster Verantwortlicher
Der Entwickler ist verantwortlich für die Qualität dessen, was er liefert. Das schließt die visuelle Qualität ein. Wenn ein Entwickler eine User Story abschließt, muss er sicherstellen, dass seine Änderungen keine visuelle Regression eingeführt haben.
Mit einem No-Code-Tool für visuelles Testen, das in die Pipeline integriert ist, erfordert diese Verantwortung keinen zusätzlichen Aufwand. Der Test wird automatisch ausgeführt. Der Entwickler prüft das Ergebnis in seinem Merge Request. Bei einer beabsichtigten visuellen Änderung aktualisiert er die Referenz. Bei einer Regression korrigiert er sie.
Der Entwickler muss keine manuellen visuellen Tests schreiben oder Szenarien skripten. Das Tool erledigt das. Seine Verantwortung ist es, die Ergebnisse zu prüfen und zu handeln.
Der QA: Hüter des Prozesses
Der QA führt die visuellen Tests nicht durch — die Automatisierung erledigt das. Der QA stellt sicher, dass der Prozess funktioniert.
Seine Rolle ist es, die visuellen Test-Suites zu konfigurieren und zu pflegen: welche Seiten getestet werden, welche Auflösungen, welche Browser. Er definiert die Toleranzschwellen (welcher Prozentsatz visueller Unterschiede ist akzeptabel). Er analysiert die zweideutigen Fälle — ist ein erkannter visueller Unterschied eine echte Regression oder ein False Positive durch dynamischen Inhalt?
Der QA ist der Hüter der visuellen Teststrategie, nicht ihr Ausführender.
Der Product Owner: finaler Validierer
Der Product Owner hat eine oft unterschätzte Rolle beim visuellen Testen. Er weiß, wie das Produkt aussehen soll. Er hat die Vision der Nutzererfahrung. Er kann sagen, ob eine visuelle Änderung akzeptabel ist oder nicht.
In Fällen, in denen der visuelle Test eine beabsichtigte Änderung erkennt — eine Komponentenüberarbeitung, eine Designänderung — muss der Product Owner validieren, dass das neue Erscheinungsbild seinen Erwartungen entspricht. Moderne visuelle Test-Tools ermöglichen diese Validierung über eine einfache Oberfläche: Der PO sieht Vorher und Nachher und genehmigt oder lehnt ab.
Dieser Workflow gibt dem Product Owner eine Transparenz, die er nie zuvor hatte. Anstatt visuelle Änderungen in der Sprint Review zu entdecken (oder schlimmer, in der Produktion), sieht er sie im Laufe des Sprints, in einem klaren und verwertbaren Format.
Visuelles Testen in der Definition of Done: unsere Position
Die Definition of Done (DoD) ist der Qualitätsvertrag Ihres Scrum-Teams. Es ist die Liste der Kriterien, die eine User Story erfüllen muss, um als abgeschlossen zu gelten. Wenn ein Kriterium nicht in der DoD steht, ist es optional. Und was optional ist, wird vergessen.
Warum „visueller Test bestanden" in die DoD gehört
Stellen Sie sich die Frage: Würden Sie eine User Story liefern, deren Unit-Tests nicht bestehen? Nein. Würden Sie eine User Story liefern, die die Anzeige der Startseite beschädigt? Auch nicht. Warum steht dann das zweite Kriterium nicht in Ihrer DoD?
„Visueller Test bestanden" in der Definition of Done bedeutet, dass jede gelieferte User Story automatisiert visuell überprüft wurde. Keine nicht-validierte visuelle Regression besteht fort. Jeder erkannte visuelle Unterschied wurde entweder korrigiert (es ist eine Regression) oder genehmigt (es ist eine beabsichtigte Änderung).
Es ist ein binäres, messbares, automatisierbares Kriterium. Es hängt nicht vom subjektiven Urteil eines unter Zeitdruck stehenden Menschen in der Sprint Review ab. Es basiert auf einem objektiven Pixelvergleich.
Wie man das Kriterium in der DoD formuliert
Hier ist die Formulierung, die wir empfehlen:
„Visueller Test bestanden: Keine nicht genehmigte visuelle Regression auf den von der User Story betroffenen Seiten und Komponenten erkannt."
Diese Formulierung ist aus drei Gründen wichtig. Sie präzisiert „nicht genehmigt", was bedeutet, dass beabsichtigte visuelle Änderungen akzeptabel sind, sofern sie explizit validiert wurden. Sie präzisiert „betroffene Seiten und Komponenten", was bedeutet, dass der Test sich nicht auf direkt modifizierte Bildschirme beschränkt, sondern auch potenziell durch Seiteneffekte betroffene Bildschirme einschließt. Und sie ist messbar: Entweder gibt es nicht genehmigte Regressionen, oder es gibt keine.
Die häufigsten Einwände (und warum sie nicht standhalten)
„Das wird unsere Sprints verlangsamen." Nein. Der automatisierte visuelle Test läuft parallel zu Ihren anderen Tests in der CI/CD-Pipeline. Er fügt keine Zeremonie, kein Meeting, keinen manuellen Prozess hinzu. Was Ihre Sprints verlangsamt, sind visuelle Bugs, die in der Produktion entdeckt werden und einen Hotfix im Eilverfahren erfordern.
„Wir haben nicht die Kompetenzen." No-Code-Tools für visuelles Testen wie Delta-QA erfordern keine Programmierkenntnisse. Sie definieren die zu testenden Seiten, die Zielauflösungen, und das Tool erledigt den Rest. Wenn Ihr Team einen Webbrowser bedienen kann, kann es ein No-Code-Tool für visuelles Testen verwenden.
„Unsere Designer validieren bereits das Rendering." Ihre Designer validieren das initiale Rendering. Sie überprüfen nicht jede Seite nach jeder Codeänderung. Der automatisierte visuelle Test prüft kontinuierlich, bei jeder Änderung, auf allen konfigurierten Seiten. Kein Mensch kann diese Abdeckung erreichen.
„Wir haben zu viele False Positives." False Positives sind ein reales Thema, aber es ist ein Konfigurationsproblem, kein grundsätzliches Problem. Dynamische Inhalte (Daten, Werbung, Echtzeitdaten) müssen in der Testumgebung maskiert oder stabilisiert werden. Ein gut konfiguriertes Tool liefert zuverlässige Ergebnisse.
Sprint-für-Sprint-Integration: Der vollständige Workflow
So integriert sich visuelles Testen konkret in die Zeremonien und Aktivitäten eines Sprints.
Sprint Planning
Während des Sprint Plannings, wenn das Team User Stories in Aufgaben zerlegt, identifiziert es die visuell betroffenen Seiten und Komponenten. Diese Identifikation erfordert keinen erheblichen Aufwand — es ist eine natürliche Erweiterung der technischen Analyse.
Wenn eine User Story die Navigationskomponente modifiziert, notiert das Team, dass alle Seiten, die diese Komponente verwenden, in den visuellen Testumfang einbezogen werden müssen. Diese Information wird in der User Story dokumentiert.
Tägliche Entwicklung
Während der Entwicklung wird der visuelle Test automatisch bei jedem Push ausgeführt. Der Entwickler prüft die Ergebnisse in seinem Merge Request. Im Daily Standup erwähnt der Entwickler visuelle Unterschiede, die besprochen werden müssen (beabsichtigte Änderungen, die eine PO-Validierung erfordern, oder komplexe Regressionen, die Hilfe benötigen), falls vorhanden.
Visuelles Testen schafft keinen neuen Workflow. Es fügt sich in den bestehenden Workflow von Merge Request und Code Review ein.
Sprint Review
Die Sprint Review wird flüssiger, weil visuelle Probleme während des Sprints behandelt wurden. Der Product Owner hat bereits beabsichtigte visuelle Änderungen über das visuelle Test-Tool validiert. Die Demonstration ist eine Bestätigung, keine Entdeckung.
Beabsichtigte visuelle Änderungen verwalten
Nicht jede visuelle Änderung ist eine Regression. Eine Komponentenüberarbeitung, eine Farbänderung im Design System, ein neues Layout — das sind beabsichtigte Änderungen, die der visuelle Test erkennen wird.
Der Schlüssel liegt darin, beabsichtigte Änderungen schnell von unbeabsichtigten Regressionen zu unterscheiden. Moderne visuelle Test-Tools erleichtern diese Unterscheidung, indem sie das Referenzbild und den neuen Screenshot nebeneinander darstellen, mit klar hervorgehobenen Unterschieden.
Der Workflow ist einfach. Der visuelle Test erkennt eine Änderung. Der Entwickler oder QA untersucht den Unterschied. Wenn es beabsichtigt ist, aktualisiert er die Referenz (der neue Screenshot wird zur Referenz für nachfolgende Tests). Wenn es eine Regression ist, korrigiert er den Code.
Im Scrum-Kontext sollte die Validierung signifikanter beabsichtigter Änderungen (Seitenüberarbeitung, Designänderung) den Product Owner einbeziehen. Kleinere Änderungen (Margenanpassung, Hinzufügen eines geplanten Elements) können vom Entwickler oder QA validiert werden.
Wo morgen anfangen
Wenn visuelles Testen noch nicht in Ihren Scrum-Workflow integriert ist, so können Sie im nächsten Sprint starten.
Schritt 1: Schlagen Sie die Aufnahme in die DoD vor. Schlagen Sie in Ihrer nächsten Retrospektive vor, „visueller Test bestanden" in die Definition of Done aufzunehmen. Erklären Sie warum, teilen Sie diesen Artikel, diskutieren Sie die Modalitäten.
Schritt 2: Konfigurieren Sie ein No-Code-Tool für visuelles Testen. Wählen Sie ein Tool, das sich in Ihre CI/CD-Pipeline integriert und keine Skripte erfordert. Delta-QA beispielsweise ermöglicht die Konfiguration visueller Test-Suites in wenigen Minuten, ohne eine einzige Zeile Code.
Schritt 3: Fangen Sie klein an. Testen Sie nicht alle Ihre Seiten im ersten Sprint. Beginnen Sie mit den fünf kritischsten Seiten (Startseite, Produktseite, Conversion-Tunnel, Login-Seite, Dashboard). Fügen Sie die anderen Seiten schrittweise hinzu.
Schritt 4: Iterieren Sie an der Konfiguration. Passen Sie die Toleranzschwellen an, um False Positives zu reduzieren. Maskieren Sie dynamische Inhalte. Verfeinern Sie die getesteten Auflösungen. Wie alles in Scrum verbessert sich die visuelle Teststrategie durch Iteration.
Schritt 5: Messen und teilen Sie die Ergebnisse. Stellen Sie nach zwei oder drei Sprints die Metriken zusammen. Wie viele visuelle Regressionen wurden erkannt? Wie viele hätten die Produktion erreicht? Wie viel Zeit wurde eingespart? Diese Zahlen sprechen für sich.
FAQ
Ersetzt visuelles Testen die End-to-End-Tests in Scrum?
Nein. Visuelles Testen und End-to-End-Tests sind komplementär. End-to-End-Tests prüfen, ob funktionale Abläufe korrekt funktionieren (ein Klick auf einen Button löst die richtige Aktion aus). Visuelles Testen prüft, ob die Oberfläche korrekt angezeigt wird (der Button ist sichtbar, gut positioniert und lesbar). Sie brauchen beides.
Wie viel Zeit fügt visuelles Testen einem Sprint hinzu?
Automatisiertes visuelles Testen fügt dem Sprint keine signifikante Zeit hinzu. Die Ausführung erfolgt in der CI/CD-Pipeline, parallel zu den anderen Tests. Die einzige menschliche Zeit ist die Überprüfung der erkannten Unterschiede, die einige Minuten pro Merge Request dauert. Die eingesparte Zeit durch das Vermeiden visueller Bugs in der Produktion ist hingegen beträchtlich.
Braucht man einen dedizierten QA, um visuelles Testen in Scrum zu verwalten?
Nein. Ein dedizierter QA ist ein Plus, aber keine Notwendigkeit. Mit einem No-Code-Tool kann die initiale Konfiguration von jedem technischen Teammitglied durchgeführt werden. Die tägliche Überprüfung der Ergebnisse ist Teil des Merge-Request-Prozesses und wird von den Entwicklern übernommen. Der QA greift bei der Strategie, den Schwellenwerten und komplexen Fällen ein.
Wie verwaltet man False Positives, ohne den Sprint zu verlangsamen?
False Positives werden durch Konfiguration verwaltet, nicht durch menschlichen Aufwand. Maskieren Sie Bereiche mit dynamischem Inhalt (Daten, Zähler, Werbung). Stabilisieren Sie die Testdaten. Passen Sie die Toleranzschwellen an, um winzige Rendering-Unterschiede zu ignorieren (z. B. Font-Antialiasing). Ein gut konfiguriertes Tool generiert weniger als 5 % False Positives.
Muss der Product Owner jeden erkannten visuellen Unterschied validieren?
Nein. Nur signifikante visuelle Änderungen erfordern die Validierung des PO: Seitenüberarbeitung, größere Komponentenänderung, Modifikation des Corporate Designs. Kleinere Anpassungen (Marge, Abstand, Hinzufügen eines in der User Story geplanten Elements) werden vom Entwickler oder QA validiert. Definieren Sie klare Regeln darüber, was zum PO eskaliert wird und was vom technischen Team behandelt wird.
Funktioniert visuelles Testen mit kurzen Sprints von einer Woche?
Absolut. Kurze Sprints machen visuelles Testen noch relevanter. Mit weniger Zeit für manuelle Tests wird die Automatisierung des visuellen Testens unverzichtbar. Der Shift-Left ist umso kritischer, je kürzer der Sprint ist: Sie können es sich nicht leisten, einen visuellen Bug am letzten Tag eines einwöchigen Sprints zu entdecken.
Weiterführende Lektüre
- Regressionstests in Agile: Wie Sie Testen, Ohne Ihre Sprints zu Bremsen
- Checkliste Visueller Test Vor Release: 15 Punkte Vor Jedem Deployment Pruefen
- Visuelles Testen fuer EdTech-Plattformen: Fehlerfreie Erfahrung vom Hoersaal bis zum Smartphone
Ihre Definition of Done ist ohne visuelles Testen unvollständig. Visuelle Regressionen sind Bugs — und wie alle Bugs müssen sie vor der Produktion erkannt werden.