Ideen, Tutorials und Updates von unserem Team.
Die meisten Teams sind nicht langsam darin, zu entscheiden, welche Bugs wichtig sind. Langsam sind sie bei allem drumherum. Ein Workflow für die Bug-Triage, der die Navigation abschafft, statt von dir zu verlangen, schneller zu denken.
Warum der eine Fehlerbericht zu einem Fix führt und der andere als „nicht reproduzierbar“ geschlossen wird: Aufbau, Kontext und eine Checkliste für die Praxis.
Eine UAT-Runde liefert eine Tabelle mit sechzig Zeilen, und mit der Hälfte davon kann niemand etwas anfangen. Selten liegt es an den Testpersonen. Es liegt am Meldekanal, der die Belege genau in dem Moment wegwirft, in dem es sie gibt.
„Nicht reproduzierbar“ ist keine Eigenschaft des Bugs. Es ist eine Aussage über den Unterschied zwischen zwei Rechnern. Solche Unterschiede gibt es nur etwa acht, und jeder hinterlässt einen eigenen Fingerabdruck.
Jedes Team schreibt irgendwann eine Vorlage für Fehlerberichte. Die meisten werden nach einem Monat ignoriert, weil sie Leuten Arbeit abverlangen, die ein Browser für sie erledigen könnte. Hier ist eine Vorlage, die sich zu behalten lohnt, und warum du drei Viertel davon streichen solltest.
Berichte und Aufgaben zu trennen ist eine kleine strukturelle Entscheidung. Sie verhindert, dass dein Bug-Eingang zum Friedhof wird, und macht doppelte Berichte zu deinem besten Werkzeug fürs Debugging.