Was macht einen guten Bugreport aus, und was ist der Unterschied zwischen Severity und Priority?

Ein guter Report lässt jemand anderen das Problem reproduzieren, ohne dich etwas fragen zu müssen: ein spezifischer Titel, exakte Schritte ab einem bekannten Ausgangszustand, erwartetes gegen tatsächliches Ergebnis, Umgebung und Build sowie Belege wie Video, Logs oder Netzwerk-Trace. Severity ist die technische Auswirkung des Defekts; Priority ist, wie bald er behoben wird. Ein kosmetischer Bug kann niedrige Severity und hohe Priority haben.

Mein Prüfstein für einen Bugreport ist, ob ein Entwickler, der nie mit mir gesprochen hat, ihn allein aus dem Report reproduzieren kann. Der Titel sagt also, was wo bricht, konkret, nicht so etwas wie Checkout kaputt. Dann Vorbedingungen, also der exakte Ausgangszustand und Accounttyp, nummerierte Schritte, denen man wörtlich folgen kann, erwartetes Ergebnis, tatsächliches Ergebnis und die Umgebung samt Buildnummer, denn ein gegen den Build von letzter Woche gemeldeter Bug kostet alle einen Nachmittag. Belege kommen jedes Mal dazu: Bildschirmaufnahme, Request und Response aus dem Netzwerk und die relevanten Logzeilen mit Zeitstempeln. Zu Severity gegen Priority: Severity ist, wie schlimm das System kaputt ist, und Priority ist, wie bald wir es beheben, und sie werden von verschiedenen Leuten aus verschiedenen Gründen gesetzt. Ein Datenkorruptionsbug in einem Feature, das zwei Leute nutzen, hat hohe Severity und niedrige Priority. Ein Tippfehler im Firmennamen auf der Landingpage ist trivial in der Severity und wird heute Vormittag behoben. Ich achte darauf, die Auswirkung genau zu beschreiben, wie viele Nutzer, ob es einen Workaround gibt, ob Geld oder Daten in Gefahr sind, und lasse dann den Product Owner die Priority setzen, denn das ist seine Entscheidung.