Bug Tracking heißt, jeden bekannten Defekt an einem Ort zu halten, in einer Form, die es übersteht, wenn die Person, die ihn gefunden hat, in den Urlaub fährt. Das ist die ganze Idee. Die Software, die Leute meinen, wenn sie “Bug Tracker” sagen, ist nur der Aktenschrank, der das möglich macht.

Der Unterschied, auf den es ankommt, ist der zwischen einem Eintrag und einer Nachricht. Eine Nachricht ist das, was man schickt, wenn einem etwas auffällt: eine Chatzeile, eine E-Mail, eine mündliche Bemerkung im Vorbeigehen. Sie ist an eine Person gerichtet, sie wird einmal gelesen, und dann ist sie weg. Ein Eintrag ist an niemanden im Besonderen gerichtet und wird gelesen, wann immer jemand die richtige Frage stellt. Bug Tracking ist die Praxis, das erste in das zweite zu verwandeln.

Was ein Tracker leisten muss

Vier Dinge. Alles andere ist Bequemlichkeit.

  • Einen Eintrag pro Problem halten, damit zwei Leute, die dasselbe finden, einander finden statt zweimal zu melden.
  • Sagen, wo jeder steht - offen, in Arbeit, behoben, verifiziert, geschlossen - und zwar so, dass es stimmt statt nur gut gemeint zu sein.
  • Einen Verantwortlichen nennen, denn ein Defekt, der dem Team gehört, gehört niemandem.
  • Später durchsuchbar sein, was beim Auswählen übersprungen und im vierten Monat bereut wird.

Eine Tabelle erledigt die ersten drei schlecht und das vierte gar nicht. Ein Chatkanal erledigt keines davon, was kein Vorwurf an den Chat ist: er ist ein Nachrichtenmedium und tut genau das, wofür er da ist.

Was in einen Eintrag gehört

Weniger, als die meisten Vorlagen verlangen, und mehr, als die meisten Meldungen mitbringen.

Die Teile, die ihren Platz verdienen, sind die, die jemand anderes zum Handeln braucht: was passiert ist, was stattdessen erwartet wurde, wie man wieder dorthin kommt, und wo es passiert ist - Browser, Build, Konto, URL. Unser Leitfaden zum Schreiben eines Fehlerberichts ist die lange Fassung dieser Liste, und er bringt eine Vorlage mit, die Sie in ein Formular einfügen können.

Alles andere in einem typischen Formular sind Metadaten für den Prozess statt für das Problem: Schweregrad, Priorität, Komponente, Meilenstein, die zuständige Person. Nützlich, aber es gehört zu dem, der das Defektmanagement betreibt, nicht zu der Person, der aufgefallen ist, dass der Knopf kaputt ist. Das beim Melden zu verlangen, ist der häufigste Weg, das Melden so teuer zu machen, dass die Leute damit aufhören.

Drei Fehlerbilder

Fast jeder Tracker, dem nicht mehr vertraut wird, ist auf einem von drei Wegen dorthin gekommen.

Der Friedhof. Nichts wird je geschlossen, also wächst die Zahl nur, also liest niemand die Liste, also kommen echte Defekte an und werden nie gesehen. Ein Rückstand von achthundert Vorgängen, die in diesem Jahr niemand geöffnet hat, ist kein Verzeichnis von irgendetwas; es ist ein Ort, an den Dinge gehen.

Status, die lügen. Jeder Eintrag sagt “offen”, weil das Weiterschieben jemandes Aufgabe ist und niemand sie hat. An diesem Punkt ist das Statusfeld Dekoration, und der einzige Weg zu erfahren, wo etwas steht, ist eine Person zu fragen - also genau das, was der Tracker ersetzen sollte.

Der Duplikatstapel. Derselbe Defekt sechsmal gemeldet, weil Suchen schwerer ist als Tippen. Das wird meist den Meldern angelastet und ist meist ein Suchproblem: findet eine Suche nach den Wörtern, die ein normaler Mensch benutzen würde, den bestehenden Eintrag nicht, hat der Tracker ihnen beigebracht, noch einmal zu melden.

Woher die Einträge kommen, zählt mehr als welches Werkzeug sie hält

Teams verbringen lange damit, zwischen Trackern zu wählen, und fast keine Zeit mit dem Schritt davor: wie ein Defekt überhaupt von der Person, die ihn gesehen hat, in den Tracker gelangt.

Auf diesem Weg sterben die Meldungen. Jemandem fällt ein Problem auf, und zwischen dem Auffallen und einem brauchbaren Eintrag klafft eine Lücke: welcher Browser war das, was stand in der Konsole, welche URL war es, worauf habe ich zuerst geklickt. Die meisten Menschen schreiben meistens zwei Sätze und machen weiter, denn die Alternative sind fünfzehn Minuten Spurensuche für einen Fehler, der nicht ihrer ist.

Alles, was diese Lücke verkürzt, hebt die Qualität von allem, was danach kommt. Ein Formular auf der Seite, auf der der Fehler passiert ist, schlägt einen Link zum Tracker. Eine Erfassung, die die technische Hälfte automatisch einsammelt, schlägt es, einen Support-Mitarbeiter zu bitten, die Entwicklerwerkzeuge zu öffnen. Die Meldung dort erfassen, wo der Fehler ist ist dasselbe Problem vom anderen Ende gesehen.

Session Replay

Kostenlose Chrome-Erweiterung. Ein Klick auf der Seite, die sich falsch verhält, erfasst den Screenshot, die Konsole und das Netzwerkprotokoll und gibt Ihnen einen Link, den Sie ins Ticket einfügen können.

Erweiterung holen

Einen auswählen

Der ehrliche Rat lautet, dass die Wahl weniger zählt als die Gewohnheit. Jira, Linear, GitHub Issues, Bugzilla, Trello mit einer Spalte namens Bugs: alle vier Dinge von oben sind in jedem davon erreichbar, und keines davon erledigt sie für Sie.

Zwei Fragen lohnen sich bei einem Kandidaten, und es sind nicht die von den Vergleichsseiten:

Schwache Frage
Welches hat die meisten Integrationen und die besten Auswertungs-Dashboards?
Bessere Frage
Kann jemand, der nicht im Entwicklungsteam ist, ohne Hilfe darin melden, und findet jemand einen zwei Jahre alten Eintrag anhand der Wörter, an die er sich erinnert?

Wenn das Melden ein Konto, ein Projekt, eine Komponente und einen Vorgangstyp braucht, werden die Leute, die Ihren Kunden am nächsten sind - Support, Vertrieb, QA, der Kunde selbst - nicht melden. Ihre Fehler kommen stattdessen als Nachrichten an, und der Unterschied zwischen einem Eintrag und einer Nachricht ist genau das, was Sie kaufen wollten.

Tracking, Testen und der Rest

Bug Tracking sitzt flussabwärts von allem, was Fehler findet, und deshalb sammelt es das Vokabular von allem. Ein Testplan benennt, wie Defekte gemeldet werden und wer entscheidet, ob einer ein Release aufhält. Regressionstests gibt es, weil ein Tracker voller geschlossener Einträge eine Liste von Dingen ist, die früher funktionierten. Flaky Tests sind das, was passiert, wenn das, was verfolgt wird, sich nicht entscheiden kann, ob es ein Defekt ist.

Ein Tracker verbessert keine Software. Er verhindert, dass derselbe Nachmittag zweimal draufgeht.