Visuelles Testen Shift-Right: Warum visuelles Testen nicht beim Deployment aufhoert

Kernaussagen

Shift-Right bedeutet, in der Produktion zu testen und zu ueberwachen, nicht nur vor dem Deployment — visuelles Testen in der Produktion prueft, ob die Website unter realen Bedingungen so aussieht, wie sie sollte
Pre-Deployment-Tests (Shift-Left) decken CDNs, A/B-Tests, Drittanbieter-Inhalte, Feature Flags und CMS-Updates nicht ab, die die Website in der Produktion ohne neues Deployment veraendern
Synthetisches visuelles Testen in der Produktion erkennt visuelle Degradationen, die durch Faktoren verursacht werden, die Ihre CI-Pipeline nicht simulieren kann
Shift-Left und Shift-Right stehen nicht im Widerspruch — sie sind komplementaer, und visuelles Testen ist das Bindeglied zwischen beiden — ob im DevOps-Pipeline oder im visuellen Monitoring der Produktion

Visuelles Testen bezeichnet laut der Definition des ISTQB (International Software Testing Qualifications Board) „die Verifikation, dass die Benutzeroberflaeche einer Software gemaess den erwarteten visuellen Spezifikationen angezeigt wird, durch Vergleich von Referenz-Screenshots mit dem aktuellen Zustand der Anwendung" (ISTQB Glossary, Visual Testing).

Es gibt einen tief verwurzelten Glauben in der Software-Entwicklungsgemeinschaft: Testen findet vor dem Deployment statt. Sie schreiben Ihre Unit-Tests, Ihre Integrationstests, Ihre End-to-End-Tests. Sie fuehren sie in der CI aus. Wenn alles gruen ist, deployen Sie. Und nach dem Deployment? Sie ueberwachen Server-Metriken, Fehlerraten, Antwortzeiten. Vielleicht ein APM-Tool wie Datadog oder New Relic. Aber das Testen, das echte Testen, ist vorbei.

Dieser Glaube ist falsch. Und er ist besonders gefaehrlich, wenn es um das visuelle Rendering Ihrer Website geht.

Shift-Right — dieser Ansatz, der Test- und Qualitaetspraktiken ueber das Deployment hinaus direkt in die Produktion ausweitet — hat in den letzten Jahren an Bedeutung gewonnen. Der Begriff wurde von Praktikern wie Noel De Martin und Organisationen wie DORA (DevOps Research and Assessment) von Google Cloud populaer gemacht. Aber die meisten Shift-Right-Implementierungen konzentrieren sich auf Infrastruktur-Monitoring, Canary Deployments und Chaos Engineering. Das visuelle Rendering bleibt ein blinder Fleck.

Dieser Artikel verteidigt eine These, die offensichtlich sein sollte, es aber immer noch nicht ist: Visuelles Testen hoert nicht beim Deployment auf. Wenn sich Ihre Website visuell in der Produktion aendern kann, ohne dass Sie irgendetwas deployen — und das kann sie, wie wir gleich sehen werden — dann brauchen Sie visuelles Testen in der Produktion.

Warum sich Ihre Website in der Produktion aendert, ohne dass Sie deployen

Das ist der Ausgangspunkt jeder Ueberlegung zum visuellen Shift-Right. Wenn sich Ihre Website nur zum Zeitpunkt des Deployments aendern wuerde, wuerde Pre-Deployment-Testen ausreichen. Aber Ihre Website aendert sich in der Produktion aus Dutzenden von Gruenden, die nichts mit Ihrem Code zu tun haben.

Drittanbieter-Inhalte

Ihre Website integriert wahrscheinlich Drittanbieter-Elemente: Werbeskripte, Chat-Widgets, Social-Media-Embeds, YouTube-Videos, Google Maps, Typeform-Formulare, Cookie-Popups. Jeder Drittanbieter kann seinen Code jederzeit aendern, ohne Sie zu benachrichtigen, und dieser Code wird auf Ihren Seiten ausgefuehrt.

Ein Chat-Widget, das 20 Pixel groesser wird, kann einen kritischen Action-Button auf Mobilgeraeten verdecken. Ein Werbeskript, das ein neues Format injiziert, kann Ihren Inhalt verschieben. Ein Social-Media-Embed, das sein Seitenverhaeltnis aendert, kann Ihr Layout beschaedigen. Und all das passiert in der Produktion, ohne jegliches Deployment Ihrerseits.

Ihre Pre-Deployment-Tests koennen diese Aenderungen nicht antizipieren. Sie testen Ihren Code, nicht den Code anderer. Visuelles Testen in der Produktion erfasst den tatsaechlichen Zustand der Seite mit all ihren Drittanbieter-Elementen und erkennt visuelle Aenderungen unabhaengig von ihrer Quelle.

CMS-Updates

Wenn Ihre Website ein CMS verwendet — WordPress, Drupal, Contentful, Strapi oder jedes andere Content-Management-System — aendert sich der Inhalt in der Produktion unabhaengig von technischen Deployments. Ein Redakteur, der einen Artikel mit einem zu breiten Bild veroeffentlicht. Ein Administrator, der ein Navigationsmenue aendert. Ein Marketingmitarbeiter, der den CTA-Text aendert und ihn zu lang fuer seinen Container macht.

Diese Inhaltsaenderungen sind visuelle Aenderungen. Und sie durchlaufen keine Test-Pipeline. Es gibt keine CI, kein Review, keinen automatisierten Test zwischen dem Moment, in dem der Redakteur auf „Veroeffentlichen" klickt, und dem Moment, in dem die Aenderung fuer alle Nutzer sichtbar ist.

Feature Flags und A/B-Tests

Feature Flags und A/B-Tests sind per Definition Aenderungen, die in der Produktion stattfinden. Wenn Sie ein Feature Flag fuer 10 % Ihrer Nutzer aktivieren oder Ihr A/B-Testing-Tool eine andere Variante Ihrer Startseite anzeigt, aendert sich das visuelle Rendering Ihrer Website — aber nicht fuer alle, und nicht in Ihrer Staging-Umgebung.

Ihre CI-Pipeline testet die Basisversion Ihrer Website. Sie testet nicht alle moeglichen Kombinationen von Feature Flags. Sie testet nicht jede A/B-Test-Variante. Nur ein visueller Test in der Produktion, ausgefuehrt mit den verschiedenen Flag- und Variantenkonfigurationen, kann ueberpruefen, ob jede Kombination ein akzeptables visuelles Rendering erzeugt.

CDNs und Caches

Ihr CDN kann eine veraltete Version Ihres CSS oder Ihrer Bilder ausliefern. Ein Cache, der sich nach einem Deployment nicht korrekt leert, kann das alte CSS mit dem neuen HTML ausliefern und einen visuellen Versatz verursachen. Ein CDN, das Ihre Bilder zu aggressiv komprimiert, kann deren visuelle Qualitaet in der Produktion verschlechtern.

Diese Probleme existieren nicht in Ihrer Staging-Umgebung, wo Caches oft deaktiviert oder automatisch geleert werden. Sie existieren nur in der Produktion, mit den realen Caches und CDNs. Visuelles Testen in der Produktion erkennt sie, weil es die Seite so erfasst, wie der Nutzer sie empfaengt, ueber CDN und Caches.

Zertifikate und Netzwerkfehler

Ein abgelaufenes SSL-Zertifikat kann eine Browser-Warnung ausloesen, die Ihre Seite durch einen Fehlerbildschirm ersetzt. Ein falsch konfigurierter DNS kann einige Nutzer auf eine Standardseite umleiten. Ein ausgefallener Drittanbieter-Service kann ein klaffendes Loch auf Ihrer Seite hinterlassen, wo einst ein Widget war.

Das Infrastruktur-Monitoring erkennt einige dieser Probleme (das abgelaufene Zertifikat, den DNS-Ausfall). Aber es erkennt nicht das visuelle Ergebnis. Eine Seite, die einen Status 200 zurueckgibt, kann visuell kaputt sein, wenn ein Drittanbieter-Service ausgefallen ist und Ihr Fallback nicht existiert oder nicht korrekt funktioniert.

Shift-Left reicht nicht: die Illusion der vollstaendigen Abdeckung

Die Shift-Left-Bewegung war ein grosser Fortschritt fuer die Softwarequalitaet. Frueher testen, Tests in der CI automatisieren, Bugs erkennen, bevor sie die Produktion erreichen — all das ist essenziell und muss fortgesetzt werden. Aber Shift-Left basiert auf einer impliziten Annahme: dass die Testumgebung repraesentativ fuer die Produktion ist.

Die Kluft zwischen Staging und Produktion

Ihre Staging-Umgebung ist nicht Ihre Produktion. Sie verwendet wahrscheinlich einen reduzierten Datensatz, Drittanbieter-Services im Sandbox-Modus, kein CDN (oder ein anderes CDN), keine echten Nutzer, keine reale Last. Schriften laden anders. Bilder werden von einem anderen Speicher ausgeliefert. Die DSGVO-Einwilligungs-Cookies sind nicht dieselben.

All diese Unterschiede bedeuten, dass das visuelle Rendering im Staging signifikant vom Rendering in der Produktion abweichen kann. Ein visueller Test, der im Staging besteht, kann in der Produktion aus Gruenden scheitern, die nichts mit Ihrem Code zu tun haben.

Pre-Deployment-Tests erfassen einen Moment

Ihre CI-Tests werden zum Zeitpunkt des Deployments ausgefuehrt. Sie ueberpruefen den Zustand der Website in diesem praezisen Moment. Aber was passiert eine Stunde spaeter? Einen Tag spaeter? Eine Woche spaeter?

Zwischen zwei Deployments ist Ihre Produktions-Website lebendig. Inhalte aendern sich, Drittanbieter entwickeln sich weiter, Caches laufen ab, Zertifikate werden erneuert (oder nicht). Der Pre-Deployment-Test ist eine eingefrorene Momentaufnahme. Visuelles Testen in der Produktion ist eine kontinuierliche Ueberwachung.

Shift-Right ist nicht die Aufgabe von Shift-Left

Um es klar zu sagen: Shift-Right zu uebernehmen bedeutet nicht, Shift-Left aufzugeben. Beide Ansaetze sind komplementaer. Shift-Left erkennt Regressionen in Ihrem Code vor dem Deployment. Shift-Right erkennt Degradationen in der Produktion, die durch externe Faktoren verursacht werden.

Konkret fuer visuelles Testen: Der Test in der CI (Shift-Left) vergleicht Ihre Staging-Seiten mit den Baselines und erkennt Regressionen, die durch Ihre Codeaenderungen eingefuehrt wurden. Der Test in der Produktion (Shift-Right) vergleicht Ihre Produktionsseiten mit den Baselines und erkennt Degradationen durch Drittanbieter-Inhalte, CMS-Updates, CDN-Probleme und alles, was Ihrer CI entgeht.

Synthetisches visuelles Testen in der Produktion

Das Konzept des „Synthetic Monitoring" oder synthetischen Monitorings ist in der Branche gut etabliert. Tools wie Datadog Synthetics, New Relic Synthetics oder Checkly fuehren geskriptete Nutzerszenarien in regelmaessigen Abstaenden gegen Ihre Produktions-Website aus, um zu ueberpruefen, ob alles funktioniert. Visuelles Testen in der Produktion ist die visuelle Erweiterung dieses Konzepts.

Wie es funktioniert

Ein synthetischer visueller Test in der Produktion funktioniert in drei Schritten. Erstens laedt ein Headless-Browser Ihre Produktionsseite in regelmaessigen Abstaenden — stuendlich, alle vier Stunden, einmal taeglich, je nach Ihren Beduerfnissen. Zweitens erfasst der Browser einen Screenshot der Seite, genau so, wie ein Nutzer sie sehen wuerde. Drittens wird der Screenshot mit der Referenz-Baseline verglichen. Wenn ein visueller Unterschied erkannt wird, wird ein Alert gesendet.

Das ist klassisches visuelles Testen, aber kontinuierlich gegen die Produktion ausgefuehrt, anstatt punktuell in der CI. Der fundamentale Unterschied ist, dass Sie kein Build-Artefakt testen — Sie testen die reale Website, mit all ihren Komponenten, Inhalten, Drittanbietern und Caches.

Was synthetisches visuelles Testen erkennt

Die Szenarien, in denen visuelles Testen in der Produktion einen einzigartigen Mehrwert bietet, sind zahlreich und konkret.

Progressive Degradation: Ihre Website bricht nicht auf einmal zusammen. Eine kleine Drittanbieter-Aenderung hier, ein CMS-Inhalt, der etwas zu lang ist, dort, ein Bild, das durch ein qualitativ schlechteres ersetzt wird. Jede Aenderung ist gering, aber die Akkumulation verschlechtert die Erfahrung. Visuelles Testen in der Produktion erkennt diese progressive Abweichung durch Vergleich mit einer stabilen Baseline.

Drittanbieter-Vorfall: Ein Font-Provider faellt aus und Ihre Website zeigt System-Fallback-Fonts an. Ein Bild-CDN verlangsamt sich und Ihre Bilder laden nicht innerhalb der Erfassungszeit. Ein Analytics-Skript injiziert ein Fehlerbanner. Visuelles Testen erkennt das sichtbare Ergebnis dieser Vorfaelle.

Veroeffentlichungsfehler: Ein Redakteur veroeffentlicht Inhalte mit defekter Formatierung, einem fehlenden Bild oder Text, der aus seinem Container ueberlaeuft. Visuelles Testen in der Produktion faengt diese redaktionellen Fehler auf, die keinen technischen Validierungsprozess durchlaufen.

Geografisches Problem: Ihre Website kann je nach Geolokalisierung des Nutzers unterschiedlich gerendert werden, aufgrund regionaler CDNs, lokalisierter Inhalte oder lokaler Vorschriften (DSGVO-Cookie-Banner, eingeschraenkte Inhalte). Ein visueller Test, der von verschiedenen Regionen aus ausgefuehrt wird, erkennt geografische Inkonsistenzen.

Produktions-Baselines definieren

Die Baseline-Frage ist entscheidend fuer visuelles Testen in der Produktion. Im Gegensatz zum CI-Test, bei dem die Baseline die vorherige Version Ihres Codes ist, repraesentiert die Baseline in der Produktion den „erwarteten" visuellen Zustand Ihrer Website.

Sie haben zwei Ansaetze. Der erste ist die feste Baseline: Sie erfassen eine Baseline, wenn die Website in einem validierten Zustand ist, und vergleichen alle nachfolgenden Erfassungen mit dieser Baseline. Dieser Ansatz erkennt jede Abweichung vom validierten Zustand, erfordert aber eine Baseline-Aktualisierung nach jeder beabsichtigten Aenderung.

Der zweite ist die gleitende Baseline: Die Baseline ist der vorherige Screenshot. Jede Erfassung wird mit der vorherigen verglichen. Dieser Ansatz erkennt ploetzliche Aenderungen, kann aber progressive Degradationen uebersehen (jede kleine Aenderung liegt unter der Erkennungsschwelle, aber die Akkumulation ist signifikant).

Die beste Strategie kombiniert beide: eine gleitende Baseline zur Erkennung ploetzlicher Aenderungen (mit niedriger Empfindlichkeitsschwelle) und eine feste Baseline, die periodisch (woechentlich oder monatlich) ueberprueft wird, um progressive Abweichungen zu erkennen.

Konkrete Shift-Right-Szenarien

Wechseln wir von Prinzipien zu realen Situationen, in denen visuelles Testen in der Produktion den Unterschied macht.

Das Freitag-Abend-Deployment

Sie haben am Freitag um 18:00 Uhr deployed. Ihre CI-Tests waren gruen. Am Montagmorgen meldet ein Nutzer, dass die Startseite abgeschnittenen Text anzeigt. Der Bug existiert seit Freitagabend. Drei Tage Degradation fuer Ihre Nutzer.

Mit einem visuellen Test in der Produktion, der alle vier Stunden ausgefuehrt wird, wird das Problem am Freitag um 22:00 Uhr erkannt. Der Alert wird gesendet. Der Bereitschaftsentwickler kann ermitteln und korrigieren — oder zumindest ist das Problem vor Wochenbeginn dokumentiert.

Das Update des DSGVO-Einwilligungs-Widgets

Ihr Einwilligungsmanagement-Anbieter (Cookiebot, OneTrust, Didomi usw.) deployt ein Update seines Widgets. Das Widget ist jetzt 50 Pixel hoeher, was Ihren Inhalt nach unten drueckt. Auf Mobilgeraeten ist der „Akzeptieren"-Button jetzt teilweise vom unteren Bildschirmrand verdeckt.

Kein Pre-Deployment-Test kann dieses Update antizipieren. Visuelles Testen in der Produktion erkennt es sofort durch die Feststellung des Inhaltsversatzes.

Das Ende einer Google Font

Google Fonts beschliesst, eine Schrift zu entfernen oder das Rendering einer bestehenden Schrift zu aendern. Ihre Website, die diese Schrift verwendete, wechselt zur System-Fallback-Schrift. Visuell aendert sich das Layout: Texte sind breiter oder schmaler, Zeilen brechen an anderen Stellen um, Abstaende aendern sich.

Visuelles Testen in der Produktion erkennt diese Schriftaenderung durch ihre visuelle Auswirkung: Die Screenshots zeigen Layout-Unterschiede auf allen Seiten der Website.

Das Ablaufen des Bild-API-Zertifikats

Ihr Bilddienst (Cloudinary, Imgix, Cloudflare Images) hat ein ablaufendes Zertifikat. Browser blockieren Bilder, die ueber HTTPS mit einem ungueltigen Zertifikat ausgeliefert werden. Ihre Seiten zeigen leere Bereiche oder Symbole fuer defekte Links anstelle der Bilder.

Ihr Infrastruktur-Monitoring erkennt das Problem moeglicherweise nicht (Ihr Server gibt immer noch einen 200 zurueck). Ihr funktionales synthetisches Monitoring erkennt es auch nicht (Tests ueberpruefen Klicks und Navigationen, nicht das Vorhandensein von Bildern). Visuelles Testen erkennt es sofort: Die Screenshots zeigen Seiten ohne Bilder.

Visuellen Shift-Right implementieren

Die Implementierung des visuellen Testens in der Produktion ist einfacher, als es scheint, besonders wenn Sie bereits visuelles Testen in Ihrer CI haben.

Mit den kritischen Seiten beginnen

Sie muessen nicht alle Seiten Ihrer Website in der Produktion testen. Beginnen Sie mit den wertschoepfenden Seiten: Startseite, Landing Pages, Conversion-Seiten (Registrierung, Bezahlung), meistbesuchte Produktseiten. Das sind die Seiten, deren visuelle Degradation die staerkste geschaeftliche Auswirkung hat.

Erfassungsfrequenz definieren

Die Erfassungsfrequenz haengt von der Volatilitaet Ihrer Website ab. Eine E-Commerce-Website mit taeglichen Aktionen erfordert haeufigere Erfassungen als eine Unternehmenswebsite, die sich selten aendert. Fuer die meisten Websites ist eine Erfassung alle vier Stunden ein guter Kompromiss zwischen Reaktionsfaehigkeit und Ressourcenverbrauch. Fuer die kritischsten Seiten (Startseite, Bezahlseite) ist eine stuendliche Erfassung gerechtfertigt.

Alerts konfigurieren

Visuelles Testen in der Produktion muss mit Ihrem bestehenden Alerting-System verbunden sein. Wenn eine visuelle Abweichung erkannt wird, sollte der Alert an denselben Kanal wie Ihre Infrastruktur-Alerts gesendet werden (Slack, PagerDuty, Opsgenie, E-Mail). Der Alert sollte den visuellen Diff enthalten, damit das Team die Schwere der Degradation sofort einschaetzen kann.

Rauschen vom Signal unterscheiden

Visuelles Testen in der Produktion kann lauter sein als der Test in der CI, weil sich der Produktionsinhalt legitim aendert. Um False Positives zu reduzieren — ein Thema, das wir in unserem Artikel zu False Positives im visuellen Testen ausfuehrlich behandeln —, verwenden Sie Ausschlusszonen fuer haeufig wechselnde Elemente (Daten, Besucherzaehler, Werbeinhalte). Passen Sie die Empfindlichkeitsschwelle an, um geringfuegige Variationen zu tolerieren (ein Pixel Unterschied im Font-Rendering ist keine Regression). Beginnen Sie mit einer toleranten Schwelle und verschaerfen Sie sie schrittweise.

Visuelles Testen als Bruecke zwischen Shift-Left und Shift-Right

Visuelles Testen ist vielleicht die einzige Art von Test, die sowohl im Shift-Left als auch im Shift-Right gleichermassen natuerlich funktioniert. Unit-Tests sind von Natur aus Pre-Deployment. Performance-Tests haben zwar Sinn in der Produktion, erfordern aber andere Tools. Visuelles Testen verwendet dieselbe Mechanik — erfassen, vergleichen, alarmieren — unabhaengig davon, ob der Kontext die CI oder die Produktion ist.

Diese Kontinuitaet macht visuelles Testen besonders geeignet fuer Shift-Right. Sie uebernehmen kein neues Tool oder eine neue Philosophie. Sie erweitern ein Tool, das Sie bereits verwenden, auf einen neuen Kontext. Ihre CI-Baselines koennen als Ausgangspunkt fuer Ihre Produktions-Baselines dienen. Ihre Expertise bei der Interpretation visueller Diffs ist direkt uebertragbar.

Das Ergebnis ist eine vollstaendige visuelle Abdeckung: Ihr Code wird vor dem Deployment visuell ueberprueft (Shift-Left), und Ihre Website wird nach dem Deployment visuell ueberwacht (Shift-Right). Durch Ihren Code eingefuehrte Regressionen werden in der CI erkannt. Durch externe Faktoren verursachte Degradationen werden in der Produktion erkannt. Kein blinder Fleck.

FAQ

Erzeugt visuelles Testen in der Produktion nicht viele False Positives?

Das ist eine berechtigte Sorge, aber beherrschbar. False Positives in der Produktion stammen hauptsaechlich von dynamischen Inhalten (Daten, Zaehler, Werbung) und geringfuegigen Rendering-Variationen. Die Loesung besteht darin, Ausschlusszonen fuer legitim variable Elemente zu verwenden und eine angepasste Toleranzschwelle einzusetzen. Mit einem gut konfigurierten Tool kann die False-Positive-Rate in der Produktion auf dem gleichen Niveau wie in der CI gehalten werden. Der Schluessel ist, mit einer toleranten Schwelle zu beginnen und sie schrittweise an Ihren Kontext anzupassen.

Was ist der Unterschied zwischen visuellem Testen in der Produktion und Uptime-Monitoring?

Uptime-Monitoring prueft, ob Ihre Website antwortet (HTTP-Status 200, akzeptable Antwortzeit). Visuelles Testen in der Produktion prueft, ob Ihre Website so aussieht, wie sie sollte. Eine Website kann „up" sein (200 OK, normale Antwortzeit) und gleichzeitig visuell degradiert: fehlende Bilder, Fallback-Fonts, verschobene Inhalte, defektes Drittanbieter-Widget. Uptime-Monitoring sagt Ihnen, dass der Server funktioniert. Visuelles Testen sagt Ihnen, dass die Nutzererfahrung intakt ist.

Bedeutet Shift-Right, dass ich meine Pre-Deployment-Tests reduzieren kann?

Nein. Shift-Right ergaenzt Shift-Left, es ersetzt es nicht. Pre-Deployment-Tests erkennen Regressionen in Ihrem Code, bevor sie die Nutzer erreichen. Testen in der Produktion erkennt Degradationen, die durch Faktoren verursacht werden, die Ihre Pre-Deployment-Tests nicht abdecken koennen. Ihre Pre-Deployment-Tests zu reduzieren wuerde die Anzahl der Regressionen erhoehen, die die Produktion erreichen, was dem Qualitaetsziel zuwiderlaufen wuerde.

Wie verwaltet man Baselines, wenn sich der Produktionsinhalt haeufig aendert?

Fuer Websites mit haeufig aktualisierten Inhalten ist die gleitende Baseline-Strategie am besten geeignet: Jede Erfassung wird mit der vorherigen verglichen, um ploetzliche Aenderungen zu erkennen. Fuer beabsichtigte Inhaltsaenderungen aktualisieren Sie die Baseline nach Validierung. Fuer staendig wechselnde Elemente (Nachrichten-Feeds, Preise, Aktionen) verwenden Sie Ausschlusszonen. Das Ziel ist nicht, Ihre Website einzufrieren, sondern unerwartete visuelle Aenderungen zu erkennen.

Ist visuelles Testen in der Produktion DSGVO-konform?

Synthetisches visuelles Testen in der Produktion erhebt keine Nutzerdaten. Es fuehrt einen Headless-Browser aus, der Ihre Website wie ein anonymer Nutzer laedt, ohne persoenliche Cookies, ohne Sitzungsdaten, ohne identifizierende Informationen. Die erfassten Screenshots sind Bilder Ihrer oeffentlichen Seiten. Es findet keine Verarbeitung personenbezogener Daten im Sinne der DSGVO statt. Wenn Ihre Website personenbezogene Daten auf authentifizierten Seiten anzeigt und Sie diese Seiten testen, koennen Screenshots Testdaten enthalten — verwenden Sie dedizierte Testkonten mit fiktiven Daten.

Wie oft sollte man visuelle Tests in der Produktion ausfuehren?

Die optimale Frequenz haengt von drei Faktoren ab: der Kritikalitaet Ihrer Seiten, der Haeufigkeit externer Aenderungen und Ihrer Toleranz gegenueber der Erkennungszeit. Fuer kritische Conversion-Seiten (Bezahlseite, Registrierung) wird eine stuendliche Frequenz empfohlen. Fuer wichtige Inhaltsseiten (Startseite, Landing Pages) sind vier Stunden ein guter Kompromiss. Fuer sekundaere Seiten reichen ein bis zwei Mal taeglich. Beginnen Sie mit einer moderaten Frequenz und passen Sie sie anhand der erkannten Vorfaelle an.

Weiterführende Lektüre

Ihre Website aendert sich in der Produktion, auch wenn Sie nichts deployen. Visuelles Testen in der Produktion erkennt Degradationen, die Ihre CI nicht sehen kann. Delta-QA ueberwacht Ihre Seiten und warnt Sie, wenn das Rendering nicht mehr Ihren Erwartungen entspricht.

Delta-QA Kostenlos Testen →