FAQ Visuelles Testen: Antworten auf die 20 häufigsten Fragen
Sie haben Fragen zum automatisierten visuellen Testen? Hier finden Sie die Antworten auf die Fragen, die uns am häufigsten gestellt werden, thematisch geordnet.
Allgemeine Fragen
1. Was ist automatisiertes visuelles Testen?
Automatisiertes visuelles Testen (auch Visual Regression Testing genannt) ist eine Technik, die automatisch Screenshots Ihrer Anwendung vergleicht, um unbeabsichtigte visuelle Änderungen zu erkennen.
Die Schritte eines visuellen Tests sind folgende: Vereinfachter Prozess:
- Referenz-Screenshot (Baseline)
- Neuer Screenshot nach Code-Änderung
- Pixel-für-Pixel-Vergleich
- Warnung bei erkannten Unterschieden
2. Was ist der Unterschied zu E2E-Tests?
| E2E-Tests | Visuelle Tests |
|---|---|
| Überprüfen das funktionale Verhalten | Überprüfen das Erscheinungsbild |
| „Sendet der Button das Formular ab?" | „Ist der Button richtig positioniert?" |
| Assertions auf Daten | Assertions auf Pixel |
| Können visuelle Bugs übersehen | Erkennen jede visuelle Änderung |
Ideal: Beide kombinieren für eine vollständige Abdeckung.
3. Muss ich programmieren können, um visuelle Tests durchzuführen?
Die Antwort hängt vollständig vom gewählten Tool ab. Die Mehrheit der Lösungen auf dem Markt erfordert Entwicklungskenntnisse, was eine erhebliche Einstiegshürde für QA-Teams darstellt.
| Tool | Erforderliche Kenntnisse | Zugänglichkeit |
|---|---|---|
| Playwright / Cypress | TypeScript oder JavaScript, Projektkonfiguration, Abhängigkeitsverwaltung | Nur für Entwickler |
| Percy / Applitools | Integration in bestehenden Code, CI/CD-Konfiguration | Erfordert ein technisches Profil |
| Delta-QA | Keine Programmierkenntnisse | Für das gesamte Team zugänglich |
Code-basierte Tools (Playwright, Cypress) bieten große Flexibilität, erfordern aber, dass Tests von Entwicklern geschrieben, gewartet und debuggt werden. Das bedeutet, dass QA-Mitarbeiter von den Entwicklern abhängig sind, um ein Szenario zu erstellen oder zu ändern, was einen Engpass im Testprozess erzeugt.
SaaS-Lösungen wie Percy oder Applitools vereinfachen bestimmte Schritte, erfordern aber dennoch eine Integration in den Quellcode und eine technische Konfiguration.
Delta-QA verfolgt einen anderen Ansatz: Die grafische Benutzeroberfläche ermöglicht es jedem Teammitglied — QA, Product Manager, Designer — visuelle Tests zu erstellen, auszuführen und zu warten, ohne eine einzige Zeile Code zu schreiben. Die Szenarien werden visuell aufgebaut, die Baselines lassen sich mit wenigen Klicks verwalten, und die Ergebnisse sind sofort lesbar. Dies ermöglicht QA-Teams, autonom zu arbeiten und nicht mehr vom Zeitplan der Entwickler für ihre Testkampagnen abhängig zu sein.
4. Wie lange dauert es, visuelle Tests einzurichten?
| Ansatz | Ersteinrichtung | Erste 10 Tests | Geschätzte Gesamtdauer |
|---|---|---|---|
| Playwright (Code) | 1-2 Tage | 1 Tag | 2-3 Tage |
| SaaS mit Code (Percy) | 4-8 Stunden | 4 Stunden | 1-2 Tage |
| No-Code (Delta-QA) | 30 Minuten | 2-3 Stunden | 3-4 Stunden |
5. Welche Arten von Bugs erkennen visuelle Tests?
Visuelle Tests erkennen unter anderem:
- Kaputtes Layout (CSS)
- Falsch positionierte Elemente
- Abgeschnittener oder überlaufender Text
- Falsche Farben
- Fehlende oder falsch dimensionierte Bilder
- Responsive-Probleme
- Nicht geladene Schriftarten
- Falsche Z-Index-Werte (Überlappungen)
- Fehlerhafte Abstände/Paddings
- Regressionen nach Abhängigkeitsaktualisierungen
Technische Fragen
6. Was ist eine Baseline?
Die Baseline (oder Referenz) ist der "korrekte" Screenshot, mit dem zukünftige Aufnahmen verglichen werden.
Der Lebenszyklus einer Baseline umfasst vier Phasen:
- Erste Ausführung — die Baseline wird automatisch erstellt
- Folgende Ausführungen — jede Aufnahme wird mit der Baseline verglichen
- Gewollte Änderung — die Baseline wird aktualisiert, um die neue Version widerzuspiegeln
- Bug erkannt — der Code wird korrigiert, die Baseline bleibt unverändert
7. Wie geht man mit dynamischem Inhalt um?
Dynamischer Inhalt (Daten, Avatare, Werbung) verursacht Fehlalarme. Drei Hauptlösungen:
- Ausschlusszonen: Dynamische Bereiche (Daten, Zähler) beim Vergleich maskieren, damit sie ignoriert werden
- Inhalte mocken: Dynamische Daten fixieren (festes Datum, Standard-Avatar), um bei jeder Ausführung identische Aufnahmen zu erhalten
- CSS-Maskierung: Dynamische Elemente während der Aufnahme über ein injiziertes Stylesheet unsichtbar machen
8. Welche Toleranz sollte man verwenden?
| Kontext | Empfohlene Toleranz |
|---|---|
| Kritische Seiten (Checkout, Zahlung) | 0-0,5% |
| Standardseiten | 1-2% |
| Cross-Browser (Chrome vs Firefox) | 2-3% |
| Mit Anti-Aliasing | Anti-Aliasing-Option aktivieren, dann 1% |
9. Wie funktionieren Pixel-für-Pixel-Vergleiche?
Der grundlegende Algorithmus funktioniert in fünf Schritten:
- Baseline-Bild (Referenz) laden
- Aktuelles Bild (Test) laden
- Für jeden Pixel die Farbwerte (R, G, B, A) vergleichen und als unterschiedlich markieren, wenn die Abweichung den Schwellenwert überschreitet
- Den Prozentsatz der unterschiedlichen Pixel berechnen
- Wenn dieser Prozentsatz die definierte Toleranz überschreitet, schlägt der Test fehl
Fortgeschrittene Algorithmen (pHash, SSIM) fügen eine wahrnehmungsbasierte Toleranz hinzu, die dem menschlichen Sehen nahekommt.
10. Kann ich mehrere Browser testen?
Ja, die meisten Tools ermöglichen das gleichzeitige Testen in mehreren Browsern. Es genügt, die Zielbrowser (Chrome, Firefox, Safari) in der Tool-Konfiguration festzulegen.
Achtung: Jeder Browser erzeugt ein leicht unterschiedliches Rendering, daher müssen separate Baselines pro Browser gepflegt werden.
11. Wie testet man Responsive Design?
Es genügt, die zu testenden Viewports zu definieren und die Aufnahmen für jeden einzelnen auszuführen:
| Viewport | Auflösung | Verwendung |
|---|---|---|
| Desktop | 1920×1080 | Standard-Bildschirm |
| Tablet | 768×1024 | iPad, Tablets |
| Mobile | 375×812 | iPhone, Smartphones |
Jeder Viewport generiert seine eigenen Baselines, was es ermöglicht, bildschirmgrößenspezifische Probleme zu erkennen.
Fragen zu den Tools
12. Welche sind die wichtigsten visuellen Test-Tools?
| Tool | Typ | Besonderheit |
|---|---|---|
| Percy (BrowserStack) | SaaS | CI-orientiert, sehr beliebt |
| Applitools | SaaS | Fortgeschrittene KI, Enterprise-Angebot |
| Chromatic | SaaS | Spezialisiert auf Storybook |
| Delta-QA | SaaS/Desktop und On-Premise | No-Code |
| Playwright | Open Source | Im Framework integriert, kostenlos |
| Cypress | Open Source | Über dediziertes Plugin |
| BackstopJS | Open Source | Spezialisiert auf visuelles Testen |
| reg-suit | Open Source | Leichtgewichtig und einfach |
13. Wie wählt man das richtige Tool?
| Situation | Empfohlenes Tool |
|---|---|
| Kein Budget + erfahrene Entwickler | Playwright oder BackstopJS |
| Begrenztes Budget + gemischtes Team (Devs und Nicht-Devs) | Delta-QA |
| Enterprise-Budget + KI erforderlich | Applitools |
| Team zu 100% auf Storybook | Chromatic |
| Fortgeschrittenes CI/CD + technische Devs | Percy |
14. Wie viele visuelle Tests braucht man?
| Anwendungstyp | Empfohlene Anzahl der Szenarien |
|---|---|
| Unternehmenswebsite (10-20 Seiten) | 15-30 Szenarien |
| Mittlerer E-Commerce | 40-60 Szenarien |
| SaaS-Anwendung | 50-100 Szenarien |
Goldene Regel: Beginnen Sie damit, die kritischen Pfade abzudecken — die Seiten, die von 80% Ihrer Benutzer besucht werden, die Conversion-Pfade (Checkout, Registrierung) und die Funktionen mit hohem Business-Wert.
15. Wer sollte die visuellen Tests verwalten?
| Teamgröße | Wer macht was |
|---|---|
| Startup (kleines Team) | Die Entwickler kümmern sich um alles, von der Erstellung bis zur Wartung |
| Scale-up (mittleres Team) | Die QA-Mitarbeiter erstellen und warten die Tests, die Entwickler beheben die gefundenen Bugs |
| Enterprise (großes Team) | Der QA-Lead definiert die Strategie, die QA-Engineers erstellen die Tests, die Entwickler integrieren sie in ihren Workflow, und das Product-Team validiert die beabsichtigten Änderungen |
Praktische Fragen
16. Wie aktualisiert man die Baselines?
Die Aktualisierung der Baselines variiert je nach Tool:
- Mit grafischer Benutzeroberfläche (Delta-QA): Es genügt, für jede Änderung auf „Als neue Baseline akzeptieren" zu klicken
- Mit einem Kommandozeilen-Tool: Ein dedizierter Befehl ermöglicht es, alle Baselines in einem einzigen Durchlauf neu zu generieren
Wichtig: Überprüfen Sie immer die visuellen Änderungen, bevor Sie eine neue Baseline akzeptieren, um nicht versehentlich einen Bug zu validieren.
17. Wie verwaltet man Baselines im Team?
Vier Best Practices für die Verwaltung von Baselines im Team:
- Baselines mit dem Code versionieren — sie im selben Repository committen, um die Konsistenz zwischen Code und visuellen Referenzen zu bewahren
- Mit Branches arbeiten — jeder Feature-Branch hat seine eigenen Baselines, um Konflikte mit dem Hauptbranch zu vermeiden
- Baseline-Änderungen reviewen — Baseline-Änderungen wie Code behandeln: sie in Pull Requests zur Validierung einbeziehen
- Einen Verantwortlichen pro Bereich benennen — einen Eigentümer pro Testgruppe zuweisen, um Aktualisierungskonflikte zu vermeiden
18. Kann ich Anwendungen mit Authentifizierung testen?
Ja, mehrere Ansätze sind möglich:
- Programmatischer Login — der Test meldet sich vor jeder Aufnahme automatisch an, indem er das Login-Formular ausfüllt
- Gespeicherter Authentifizierungsstatus — der Session-Status wird einmal gespeichert und dann für alle folgenden Tests wiederverwendet, was die Ausführung erheblich beschleunigt
- Test-Token im Staging — in der Testumgebung ermöglicht ein dediziertes Authentifizierungstoken das Umgehen des Logins, ohne die Sicherheit zu gefährden
19. Ersetzen visuelle Tests die manuellen Tests?
Nein, sie ergänzen sie:
Automatisierte visuelle Tests sind hervorragend darin, Regressionen zu erkennen, mit einer bekannten Referenz zu vergleichen und schnelle, wiederholbare Überprüfungen zu bieten. Allerdings erkennen sie keine Probleme mit der Benutzererfahrung und überprüfen nicht, ob das Design der „Intention" des Designers entspricht.
Manuelle Tests bleiben daher notwendig für die Erkundung neuer Funktionen, Usability-Tests, komplexe Grenzfälle und die Validierung des allgemeinen Eindrucks der Anwendung.
20. Welche Zukunftstrends gibt es im visuellen Testen?
Künstliche Intelligenz ist zweifellos der stärkste Trend auf dem QA-Markt von heute. Allerdings verdient eine wichtige Nuance hervorgehoben zu werden: Der Nicht-Determinismus von KI-Agenten kann dem grundlegenden Auftrag von QA-Ingenieuren zuwiderlaufen, der darin besteht, das korrekte Verhalten einer Anwendung mit Sicherheit zu garantieren.
Ein Regressionstest muss reproduzierbar und vorhersagbar sein. Wenn man eine nicht-deterministische KI direkt in den Prozess der visuellen Regressionserkennung integriert, führt man eine Unsicherheitsvariable genau dort ein, wo man Zuverlässigkeit sucht. Das Ergebnis eines Tests könnte von Ausführung zu Ausführung variieren, was mit dem Anspruch auf absolutes Vertrauen, den eine Deployment-Pipeline erfordert, unvereinbar ist.
Der wahre Trend liegt unserer Meinung nach darin, KI vorgelagert einzusetzen: nicht um die Tests auszuführen, sondern um die Algorithmen der Tools zu verbessern, die den Ingenieuren zur Verfügung gestellt werden. Mit anderen Worten: KI soll dazu dienen, noch deterministischere, noch zuverlässigere Testsoftware zu entwickeln, die QA-Teams mit der Gewissheit begleitet, dass die ausgelieferte Software von hoher Qualität ist.
Genau das ist die Philosophie von Delta-QA. Anstatt eine KI in die Testschleife zu integrieren, investiert Delta-QA in die Robustheit seiner Vergleichsalgorithmen. Tausende von Kombinationen von HTML-Seitenkonfigurationen — komplexe Strukturen, tiefe Verschachtelungen, dynamische Inhalte, Rendering-Unterschiede zwischen Browsern — werden systematisch getestet, um die Zuverlässigkeit der Erkennung zu stärken. Jede Version des Algorithmus wird gegen eine Matrix von Stresstests validiert, die mehr als 425 reale Seiten abdeckt, mit einem klaren Ziel: null Fehlalarme, null übersehene Fehler.
Dieser Ansatz garantiert QA-Ingenieuren ein Tool, auf das sie sich bei jedem Deployment verlassen können, ohne Überraschungen und ohne Unsicherheit.