Bug Best Practices

Bug-Tracking Best Practices

Warum

Obwohl eigentlich einleuchtend und selbstverständlich haben “ordentliche” Bug-Tracking best practices eine Reihe entscheidender Vorteile:

• Transparenz: Alle Mitarbeiter haben einen genauen Überblick über den Stand des Projekts / der einzelnen Komponenten
• Milestones und wesentliche Entwicklungsschritte über Komponenten hinweg können besser erreicht werden, das gesamte Projekt sich schneller entwickeln
• Genauigkeit: Durch die Transparenz und das Wegfallen von “Flüsterpost-Ketten” ist es wesentlich einfacher sich gemeinsam zu koordinieren
• Genaue Rückgabe: Es ist zu jedem Zeitpunkt klar, was man den Philsophen gegenüber geliefert hat / was noch aussteht / wer gerade woran arbeitet.
• Vererbbarkeit: Wenn sich die Zusammensetzung der Teams ändert, können nachfolgende Entwickler sich schnell und klar einen Überblick über die ausstehenden Probleme und bisherigen Lösungen verschaffen.

Wie

Im folgenden eine Beschreibung der Konventionen und Vorgänge, wie bugs gehandhabt werden sollen.

Konventionen

Bugs sollen ordentlich dokumentiert werden und getagged werden.

Taggen erlaubt es, die offenen bugs zu sortieren, filtern und damit besser im Überblick behalten zu können.

Ordentlich dokumentieren bedeutet, dass ein nachfolgender genau nachvollziehen kann, wie/wann/wer mit einem Bug umgegangen wurde.

Dazu gehören:

• taggen: priorisieren (siehe unten, Prioritäten)
• taggen: Status (siehe unten, Workflow)
• dokumentieren: Wenn sich der Status eines Bugs ändert, am besten einen Kommentar im Bug-Verlauf hinterlassen, am besten so:
  • Beispiel: [Issued -> Analyze]. Dies würde bedeuten, dass sich Person Foo mit dem Bug auseinandersetzt und den tag Issued entfernt und durch den tag Analyze ersetzt hat. Dies bedeutet für alle anderen, dass:
    • sich bereits jemand um den Bug kümmert
    • andere können die noch offenen bugs bequem filtern und sehen, was als nächstes zu tun ist
  • Beispiel: [p1 -> p2].
    • Bedeutet: Person Foo hat den Bug herunterpriorisiert von P1 nach P2
  • Beispiel: [+p1]
    • Bedeutet: Person hat P1-tag an den Bug hinzugefügt

Prioritäten

Bugs sind am besten Priorisiert von “P1” bis “P4”.

Die Prioritäten entsprechen ungefähr folgenden Ideen:

• P1: Showstopper. Muss sofort behoben werden. Kritischer Bug.
• P2: Wichtiger Bug. Sollte ebenfalls schnellstmöglich behoben werden. Wichtiger Bug.
• P3: Durchaus wichtiger Bug, aber nicht unbedingt wesentlich solange noch P1 und P2 Bugs vorliegen. Können auch Feature Requests sein, die dann zumeist zu P4-Bugs werden.
• P4: Nicht so wichtiger Bug. Meist “Nice To Have” Feature Requests oder wird häufig vergeben für “Next Release/Milestone”, d.h. dieses Feature wird wohl erst im nächsten Milestone umgesetzt werden.

Workflow

• Issued
• Worked-on
• Fixed
• Review
• Verify
• Closed

Szenarien

1. Externe Person öffnet Bug (Issued)
2. Jemand bearbeitet den bug (Analyze)
3. Maintainer macht den Fix (Fixed)
4. Anderer Maintainer macht review (Review)
5. Bug wird an den Originator zurückgeschickt (Verify)
   1. Originator leht ab: zurück auf 1.
   2. Originator akzeptiert: Closed

Git Best Practices

siehe auch: Git Best Practices