In der Ergebnisliste steht „Fehlgeschlagen“. Daneben hängt ein Screenshot mit der Meldung „Verbindung unterbrochen“. Beim Nachtesten bekommt die Entwicklung dieselbe Meldung – genau so, wie sie bei einem Netzabbruch aussehen soll. Was ist hier eigentlich fehlgeschlagen?
Bei einem Wiederholungsversuch zählt der Zustand nach der Meldung. Das Beispiel „Doppelte Anfragen beim Wiederholen verhindern“ aus dem fiktiven ServiceDesk-Projekt macht den Unterschied sichtbar: Nach einer unterbrochenen Antwort und einem erneuten Versuch soll es für denselben Vorgang genau eine Anfrage geben.
Ein Befund, den ein zweites Team nachstellen kann
So könnte ein erfundenes fehlgeschlagenes Ergebnis aussehen. Die Referenzen und der Buildname sind Beispieldaten:
Build RC2, Testmandant, Kundenrolle. Eine Anfrage mit dem Titel „Demo-Drucker“ abgesendet. Im Testnetz die Antwort unterbrochen, Verbindung wiederhergestellt und genau einmal auf „Erneut versuchen“ geklickt. Nach Neuladen standen zwei Referenzen in der Übersicht: DEMO-41 und DEMO-42. Erwartet war eine Anfrage. In drei getrennten Versuchen trat die Doppelung zweimal auf.
Dieser Text trennt Bedienung, Beobachtung und Erwartung. Aus dem Ergebnis lässt sich noch nicht ableiten, ob der Browser zweimal gesendet oder der Server dieselbe Nachricht zweimal verarbeitet hat. Halten Sie die Ursache offen, bis sie untersucht ist.
Nur das anhängen, was die Beobachtung belegt
Hier hilft ein Ausschnitt der neu geladenen Liste mit beiden Referenzen mehr als das Bild der Verbindungswarnung. Ein bereinigter Netzwerkauszug kann die Zahl der Requests zeigen, falls das Team diese Frage untersucht. Prüfen Sie ihn vor der Ablage auf Zugangstoken, Cookies und personenbezogene Daten. Als Ausgangspunkt für einen eigenen Befund können Sie diese fünf Zeilen kopieren:
Build, Umgebung und Rolle: Ausgangszustand und Testdaten: Aktion, Unterbrechung und Wiederholung: Erwartet / tatsächlich nach dem Neuladen: Beleg und Häufigkeit:
Nach der Korrektur
Führen Sie denselben Ablauf mit neuen Testdaten auf dem korrigierten Build aus. Prüfen Sie zusätzlich den normalen Weg ohne Netzunterbrechung. Ein einzelner erfolgreicher Versuch ist bei einem sporadischen Fehler wenig aussagekräftig. Halten Sie fest, wie oft Sie wiederholt haben und was die Liste jeweils zeigte. Das ursprüngliche Ergebnis bleibt dem alten Build zugeordnet, die Wiederholungsprüfung dem neuen.
In Zeta Test Management finden Sie die protokollierten Beobachtungen und Anhänge am Laufergebnis. Eine Fehlerverknüpfung ergänzt den Befund, wenn die Anbindung eingerichtet ist. Wie Sie Ergebnisse im Browser wiederfinden und auswerten, zeigt das Handbuch zur Ergebnisauswertung.