Antwort.

Hintergrund: Schwer fassbare, intermittierende Bugs sind seit langem ein großes Problem für Tester: Sie treten nicht immer auf und sind häufig unzureichend dokumentiert, was ihre Reproduktion und Analyse erschwert, und folglich auch die Behebung.

Problem:

Das Hauptproblem bei intermittent-Bugs ist die Unmöglichkeit, ein klares Reproduktionsszenario zu erstellen. Oft können instabile Umgebungen, Reaktionszeiten, Daten-Synchronisierungsfehler oder Konflikte bei gleichzeitiger Nutzung durch mehrere Benutzer die Ursache sein. Entwicklern fällt es schwer, etwas zu beheben, das sie nicht zuverlässig reproduzieren können. Wenn Tester begleitende Bedingungen nicht dokumentieren, bleiben die Bugs ungelöst.

Lösung:

Verwendung eines erweiterten Berichtsformats: Dokumentation von Zeit, Umgebung, Schritten bis zum Bug, Logs, Videos/Screenshots.
Analyse von Trends: Unter welchen Bedingungen trat der Bug auf? (Zum Beispiel: "bei massiven Lasten tagsüber" oder nur bei bestimmten Handlungskombinationen.)
Enge Zusammenarbeit mit Entwicklern, um die Umgebung zu aktualisieren und technische Details zu klären.
Wiederholte Versuche zur Reproduktion auf verschiedenen Geräten und OS.

Schlüsselmerkmale:

Immer selbst kleinste Unterschiede zwischen erfolgreichen und nicht erfolgreichen Versuchen dokumentieren.
Häufigkeit des Auftretens und Versuche zur Reproduktion angeben.
Medienmaterialien (Screenshots, Videos) beifügen.

Trickfragen.

Kann man einen Bug als "nicht bug“ schließen, wenn er vom Support-Ingenieur nicht reproduziert werden konnte?

Nein. Wenn der Verdacht auf einen Bug besteht, sollte das Ticket lieber offen bleiben mit dem Hinweis "reproducibility: low" und bei neuen Informationen aktualisiert werden.

Liegt das Problem immer im Code, wenn der Bug intermittierend auftritt?

Nein. Mögliche Fehler können im Netzwerk, in der Umgebungskonfiguration, im veralteten Browser-Cache, in der Art und Weise, wie Drittanbieterdienste oder Peripheriegeräte funktionieren, liegen.

Sollte man die Priorität von intermittent-Bugs herabsetzen, wenn sie nicht jedes Mal reproduziert werden können?

Nicht immer. Die Auswirkungen sind manchmal kritisch für den Benutzer (z. B. doppelte Abbuchung von Geld), daher sollte die Priorisierung die Geschäftsrisiken berücksichtigen.

Typische Fehler und Anti-Patterns

Dokumentation von Bugs ohne begleitende Informationen zu Zeit, Umgebung, Version.
Versuch einer formalen "Schließung" der Komplexität als non-reproducible.
Ignorierung intermittierender Bugs, wenn sie außerhalb der Testumgebung nicht reproduziert werden konnten.

Beispiel aus dem Leben

Negativer Fall

Der Tester entdeckte einen Bug bei der Entsperrung des Profils, aber der Bug trat nicht mehr als bei 1 von 10 Versuchen auf. Die Dokumentation beschränkte sich auf einen Screenshot des Fehlers – der Bug wurde geschlossen, da der Entwickler ihn nicht reproduzieren konnte.

Vorteile:

Schnelles Schließen der Aufgabe.

Nachteile:

Der Bug trat in der Produktion bei realen Benutzern auf, und es musste hektisch behoben werden, was die Unternehmensreputation gefährdete.

Positiver Fall

Der Tester dokumentierte sorgfältig alle Bedingungen: Browser, Tageszeit, Anmeldemethode, fügte kurze Videos und Logs bei, pflegte regelmäßigen Kontakt zu den Entwicklern, um ein stabiles Szenario zu erhalten.