Behebe fehlgeschlagene E2E-Tests, indem du den echten Browser beobachtest

## Lege vor dem Test fest, wie Erfolg im Browser aussieht Übersetze das angeforderte Verhalten vor einer Ende-zu-Ende-Prüfung in Bedingungen, die sich im echten Browser beobachten lassen. Halte die Start-URL oder Route, den erforderlichen Konto- oder Prüfdatenzustand, gegebenenfalls die Ansichtsgröße, die Benutzeraktionen und das genaue sichtbare Erfolgsergebnis fest. Beziehe Barrierefreiheitszustand, Navigation, gespeicherten Zustand und netzwerkgestützte Inhalte ein, wenn sie zum Verhalten gehören. - Bevorzuge stabile benutzersichtbare Rollen, Beschriftungen und eigens vorgesehene Prüfkennungen gegenüber Darstellungsklassen oder der Position im Dokumentobjektmodell. - Unterscheide die Oberfläche des Testausführungssystems von der geprüften Anwendung; Belege aus einer Oberfläche beschreiben nicht automatisch die andere. - Definiere sowohl positive Belege, etwa eine sichtbare Bestätigung oder einen geänderten Wert, als auch negative Belege, etwa das Fehlen eines Fehlerhinweises. - Formuliere Zeiterwartungen anhand einer beobachtbaren Bereitschaftsbedingung und nicht als willkürliche Verzögerung. Schwäche eine Prüfaussage nicht ab, nur damit die Prüfung besteht. Ist das erwartete Verhalten mehrdeutig, halte an und kläre die Abnahmevereinbarung, bevor du Prüf- oder Produktcode änderst. ## Starte den Test im echten Browser und sichere Screenshots und Logs Starte das engste relevante Ende-zu-Ende-Szenario in einem tatsächlich unterstützten Browser über den normalen Anwendungspfad. Halte Konfiguration, Prüfdaten, Authentifizierungszustand, Ansichtsgröße und Funktionsschalter so eindeutig fest, dass die Ausführung wiederholbar ist. Falls ein sichtbarer Browsermodus oder Fehlersuchmodus verfügbar ist, verwende ihn, wenn der visuelle Zustand oder die Browserinteraktion entscheidend ist. Sichere bei einem Fehlschlag Belege, bevor du etwas änderst: - das fehlgeschlagene Szenario und die genaue Prüfaussage oder den genauen Befehl; - ein Bildschirmfoto oder eine Zustandsaufnahme des Browsers zum Fehlerzeitpunkt; - das Dokumentobjektmodell der Anwendung im Umfeld des Zielelements einschließlich barrierefreier Bezeichnung und Zustand; - relevante Fehler der Browserkonsole sowie fehlgeschlagene oder unerwartete Netzwerkanfragen; - die aktuelle URL, Weiterleitungen, Ladeanzeigen und in der Anwendung sichtbare Fehlermeldungen; - Zeitstempel oder Ausführungskennungen, die bei Verfügbarkeit zur Zuordnung von Serverprotokollen benötigt werden. Untersuche gezielt, statt zusammenhanglose Zustände vollständig auszugeben. Reproduziere den Fehler bei Bedarf einmal unter denselben Bedingungen, um einen beständigen von einem vorübergehenden Fehler zu unterscheiden, aber beginne keine unbegrenzte Wiederholungsschleife. ## Ordne die Fehlerursache zu: Test, Code oder Umgebung Ordne den beobachteten Fehler einer Prüfursache, einer Implementierungsursache oder einer Umgebungsursache zu. Die Einordnung muss durch Browserbelege und, falls nötig, durch die kleinstmögliche relevante Quelltext- oder Protokollprüfung gestützt sein. - Prüfursache: Das Produkt verhält sich gemäß der Abnahmevereinbarung, aber die Prüfung verwendet eine veraltete Auswahlregel, eine falsche Prüfaussage, ungültige Prüfdaten, eine falsche Reihenfolge oder eine unzureichende Bereitschaftsbedingung. - Implementierungsursache: Das benutzersichtbare Verhalten verletzt die Abnahmevereinbarung, beispielsweise weil ein Steuerelement nicht reagiert, Zustand oder Navigation falsch sind, die Barrierefreiheit zurückgefallen ist oder eine durch den Produktcode verursachte Anwendungsanfrage fehlschlägt. - Umgebungsursache: Prüfung und Implementierung können korrekt sein, aber eine Voraussetzung fehlt oder ist gestört, etwa ein nicht verfügbarer Dienst, ungültige Zugangsdaten, ein inkompatibler Browser, fehlende Ausgangsdaten, eine falsche Konfiguration oder erschöpfte Ressourcen. Wenn die Belege uneindeutig sind, formuliere konkurrierende Hypothesen und führe jeweils nur eine unterscheidende Prüfung aus. Bezeichne nicht jede Zeitüberschreitung als Prüfproblem und ändere Produktcode nicht allein deshalb, weil eine Prüfung fehlgeschlagen ist. Behalte die Einordnung als vorläufig bei, bis die Belege die naheliegendsten Alternativen ausschließen. ## Mache die kleinste Korrektur, ohne Assertions abzuschwächen Wähle die Korrektur, die die eingeordnete Ursache ohne umfassende Umgestaltung behebt. Bewahre die Abnahmevereinbarung und das bestehende Benutzerverhalten außerhalb des fehlerhaften Pfads. - Aktualisiere bei einer Prüfursache nur die Auswahlregel, Prüfaussage, Prüfdaten, Handlungsfolge oder Bereitschaftsbedingung, die dem beobachteten Browserzustand widerspricht. - Füge bei einer Implementierungsursache nach Möglichkeit eine fehlgeschlagene Regressionsprüfung hinzu oder behalte sie bei und ändere anschließend nur die engste Produktlogik, die zur Wiederherstellung des festgelegten Verhaltens nötig ist. - Behebe oder dokumentiere bei einer Umgebungsursache die fehlende Voraussetzung; verdecke sie nicht durch längere Wartezeiten, abgeschaltete Prüfaussagen oder bedingungslose Wiederholungen. - Bevorzuge eindeutige Signale wie sichtbare Bereitschaft, abgeschlossene Anfragen oder einen stabilen Zustand gegenüber festen Wartezeiten. - Halte Änderungen zur Prüfbarkeit für Benutzer neutral: Ergänze stabile Kennzeichnungen oder barrierefreie Beschriftungen, ohne die Prüfungen an eine zufällige Anordnung zu koppeln. Halte vor Änderungen an geschützten, erzeugten, produktiven, zerstörerischen oder mit Zugangsdaten versehenen Ressourcen an und hole die erforderliche Genehmigung ein. Lege niemals Geheimnisse in Prüfungen, Protokollen, Bildschirmfotos, Prüfdaten oder Berichten offen. ## Wiederhole dasselbe Szenario und höre bei wiederholten Fehlschlägen auf Führe nach der Korrektur genau das fehlgeschlagene Szenario unter denselben Browserbedingungen und mit derselben Abnahmevereinbarung erneut aus. Ein Bestehen zählt nur, wenn der Browser sichtbar den festgelegten Erfolgszustand erreicht und das Testausführungssystem keinen verborgenen Fehler meldet. Bestätige außerdem, dass Konsolen- und Netzwerkbelege den ursächlichen Fehler nicht mehr zeigen, sofern diese Signale Teil der Diagnose waren. Führe anschließend den kleinsten direkt betroffenen Regressionsprüfumfang aus: das umgebende Szenario, die Funktionsdefinitionsdatei oder die eng gekoppelte Prüfgruppe. Erweitere die Prüfung nicht auf eine unverbundene vollständige Prüfsammlung, außer die Änderung hat weitreichende Auswirkungen oder der Benutzer verlangt dies ausdrücklich. Wenn die Wiederholung auf andere Weise fehlschlägt, kehre zur Belegsicherung und Einordnung zurück, statt spekulative Änderungen aufeinanderzuschichten. Begrenze wiederholte Versuche. Bewerte die Diagnose nach zwei wirkungslosen Korrekturen mit demselben Ansatz neu und wähle eine andere unterscheidende Prüfung. Halte nach drei aufeinanderfolgenden Fehlschlägen ohne neue Belege an und melde die Blockade, statt den Quellbestand weiter zu verändern. ## Melde zuerst bestanden, fehlgeschlagen oder blockiert, mit Belegen Beende die Arbeit nur dann erfolgreich, wenn die ursprüngliche browserbeobachtbare Abnahmevereinbarung erfüllt ist, der direkt betroffene Regressionsprüfumfang besteht und kein relevanter ursächlicher Fehler verbleibt. Halte ebenfalls an, wenn der Fortschritt fehlende Befugnisse, Zugangsdaten, nicht verfügbare Infrastruktur, eine zerstörerische Handlung oder eine Produktentscheidung erfordert, die sich nicht sicher ableiten lässt. Berichte das Ergebnis mit genügend Belegen, damit eine andere Person es überprüfen kann: - das verwendete Szenario und die Browserbedingungen; - den beobachteten Fehler und seine Einordnung; - die Belege, welche die Einordnung stützen; - die vorgenommene minimale Änderung oder die ungelöste Voraussetzung; - die genauen Wiederholungsprüfungen und ihre Ergebnisse; - verbleibende Risiken, ausgelassene umfassendere Prüfungen und die nächste erforderliche Handlung. Beginne mit „bestanden“, „fehlgeschlagen“ oder „blockiert“. Behaupte keinen Abschluss allein aufgrund einer Quelltextprüfung, einer bestandenen Einzelprüfung oder eines simulierten Dokumentobjektmodells, wenn die Erfolgsbedingung von einem echten Browser abhängt.