Antwort.

Historie:

Ein Bugsbericht ist das zentrale Artefakt eines Testers. Über Jahrzehnte hat die Qualität der Bugsberichte die Kommunikationsgeschwindigkeit zwischen den QA- und DEV-Teams bestimmt, wodurch die Zeit für das Beheben von Bugs verkürzt oder verlängert wurde.

Problem:

Schlecht formulierte Bugsberichte (fehlende klare Schritte, ungenaue Beschreibungen, fehlendes erwartetes Verhalten) führen zu falschen Interpretationen der Aufgabe und fehlerhaften Korrekturen, was Zeit durch zusätzliche Klärungen kostet. Dies ist die Hauptursache für Konflikte zwischen den Teams.

Lösung:

Eine Struktur einhalten: Titel, Priorität/Schweregrad, Umgebung, Reproduktionsschritte, tatsächliches Ergebnis, erwartetes Ergebnis, Screenshots/Videos/Logs.
Eine maximal strukturierte und eindeutige Sprache ohne überflüssige Emotionen und subjektive Bewertungen verwenden.
Den Bericht vor dem Absenden überprüfen — versuchen, die aufgezeichneten Schritte von einem anderen Mitarbeiter nachzuvollziehen.
Die Felder gemäß der in der Firma akzeptierten Vorlage ausfüllen (Jira, DevOps, YouTrack usw.).

Kernmerkmale:

Klare Struktur und Reproduzierbarkeit.
Aktuelle Zuordnung der Bugs zur Umgebung und zur Version der Anwendung.
Begleitung der Bugs durch Fakten, Artefakte, nicht durch subjektive Bewertungen.

Fragen mit einem Haken.

Kann man mehrere ähnliche Bugs (z.B. für verschiedene UI-Elemente) in einem Bugsbericht zusammenfassen?

Nein. Jeder Bug ist ein separater Fehler, da die Behebung eines Bugs andere möglicherweise nicht löst. Ausnahme sind massenhaft auftretende Bugs mit ähnlicher Natur (z.B. globaler Stilverlust).

Ist "Funktioniert nicht"/"Lässt sich nicht öffnen" ein ausreichender Titel für einen Bug?

Nein. Der Titel sollte spezifisch sein (z.B. "[Profil] Die Schaltfläche Speichern ist nach Eingabe gültiger Daten nicht aktiv").

Sollte man die Schritte nur minimal angeben, wenn der Bug offensichtlich ist?

Nein. Auch offensichtliche Bugs sollten klar beschrieben werden – um Missverständnisse und für die Produktgeschichte zu vermeiden.

Typische Fehler und Anti-Patterns

Fehlender erwarteter Ergebnis.
Allgemeine Phrasen ohne Details.
Persönliche Bewertungen oder Emotionen einbringen („schrecklicher Bug“, „muss dringend behoben werden“).

Beispiel aus dem Leben

Negativer Fall

Der Tester hat einen Bugsbericht mit folgendem Text erstellt:

Die Schaltfläche funktioniert nicht.

und ohne Angabe von Schritt, Umgebung und erwarteten Ergebnis. Der Entwickler konnte den Bug nicht reproduzieren, der Bericht wurde als "Nicht reproduzierbar" geschlossen.

Vorteile:

Schnell erstellt.

Nachteile:

Bug verloren, Missverständnisse im Team entstanden.

Positiver Fall

Der Tester hat detailliert beschrieben:

In welchem Browser und welcher Version der Bug auftritt
Detaillierte Liste der Schritte
Erwartetes und tatsächliches Verhalten
Screenshots und Logs beigelegt
Klar auf die Nutzerstory verwiesen