Antwort.

Geschichte der Frage:

Seit der Einführung von Fehlerverfolgungssystemen stehen Tester vor der Herausforderung, wie Bugs so übermittelt werden können, dass ein Entwickler sie ohne weitere Fragen reproduzieren und beheben kann. Genau hier entstand die Kultur der klaren Festlegung von Schritten, Umgebung, Bedingungen für das Auftreten und dem tatsächlichen Ergebnis.

Problem:

Ein schlecht formulierter Bug-Report ist der Grund für langwierige Diskussionen und Missverständnisse im Team. Oft geht ein Bug verloren, wird nicht reproduziert und wird mit "nicht reproduzierbar" geschlossen, wodurch der Defekt im System bestehen bleibt.

Lösung:

Strikt der Struktur folgen: Schritte zur Reproduktion, erwartetes und tatsächliches Ergebnis, Umgebung, Schweregrad, bei Bedarf — Anhänge wie Screenshots oder Protokolle.
Bugs „mit sauberen Händen“ überprüfen: mit einem neuen Benutzer, leerem Cache, sauberem Browser.
Vorlagen für Bug-Reports und Checklisten für die Selbstüberprüfung verwenden.

Schlüsselfunktionen:

Notwendigkeit der Klarheit der Schritte (historisch — damit jeder den Bug reproduzieren kann).
Angabe des minimalen Informationssatzes: Umgebung (Softwareversion, Browser, OS).
Veranschaulichung der Bugs (Screenshots, Protokolle, Videos).

Fangfragen.

Kann man einen Bug nur mündlich dokumentieren, wenn alle im Team "es sowieso verstehen"?

Nein. Selbst in etablierten Teams ist es immer wichtig, Bugs formal festzuhalten: Die Historie der Änderungen, die Rotation im Team und das Gedächtnis an Bugs sind nicht endlos.

Muss jeder Bug aus einem "nullen" Zustand (Login/Logout usw.) geschrieben werden?

Wenn die Schritte zum Bug trivial sind (Standard-Login) — können sie weggelassen werden, aber wenn die Sitzung, Profilierung oder Einstellungen spezifisch sind — ist eine vollständige Reproduktion entscheidend.

Müssen alle Bugs mit Screenshots/Videos versehen werden?

Nicht immer. Wenn der Bug aus der Beschreibung offensichtlich ist (Rechtschreibfehler), ist ein Screenshot hilfreich, aber nicht zwingend erforderlich. Wenn der Bug jedoch mit visuellen Darstellungen/Layout zu tun hat, ist es erforderlich, visuelle Bestätigungen beizufügen.

Typische Fehler und Anti-Pattern

Unklare oder unvollständige Bug-Beschreibungen („irgendetwas funktioniert nicht“)
Fehlende Informationen zur Umgebung
Fehlende Schritte zur Reproduktion

Beispiel aus dem Leben

Negativer Fall

Der Tester erstellt einen Bug „Der Knopf funktioniert nicht“ ohne Schritte und Umgebung. Der Entwickler kann den Fehler nicht reproduzieren.

Vorteile:

Zeitersparnis bei der Erstellung des Tickets.

Nachteile:

Der Bug bleibt offen oder wird an den Tester zurückgesendet, die Kommunikation leidet.

Positiver Fall

Der Tester formalisiert den Bug: gibt Schritte, Anwendungsversion, Browser an, fügt einen Screenshot und das Systemprotokoll hinzu.