Einstufung der Bug-Prioritäten

Im letzten Jahr haben wir das Thema „Bug-Triage“ beschrieben, und dort festgestellt, dass die Bug-Triage bei der Beurteilung von Bugtickets darauf angewiesen ist, dass die Priorisierung („priority“) und der Schweregrad („severity“) richtig gesetzt wurde.

Wenn man nun in der Flut von Bug-Tickets „ertrinkt“, woher weiß das Triage-Team denn nun, was wichtig ist, und was nicht?

Sicherlich hat der Schweregrad meistens einen direkten Einfluss auf die Priorität besitzt.

Die meisten Fehler werden von der Software Qualitätssicherung im Rahmen des Testzyklus gefunden werden. Es ist jedoch auch möglich, dass durch Testautomatisierung Fehler gefunden und eingestellt werden. Außerdem werden aus dem Feld Fehler von aktiven Benutzern gemeldet.

Bei den Fehlern, die von Benutzern gemeldet werden, sieht man häufig, dass die Fehler für relativ wichtiger gehalten werden, als wenn der Fehler im Testzyklus auftritt. Ein Kunde, der sich die Mühe macht, einen Fehler zu melden, muss schon einen hohen Leidensdruck verspüren.

Um so wichtiger ist es daher, dass man eine einheitliche, absolute Skala für die Klassifizierung von Softwarefehlern nutzt. Vom ISTQB – dem International Software Testing Qualification Board – wird eine Einteilung wie folgt empfohlen:

  • Critical – Dieser Fehler kann zu einem Totalausfall oder Teilausfall des Systems führen. Es kommt zu Datenverlust / Datenzerstörung. Es gibt keinen Weg, dies zu vermeiden.
    Als Beispiel sei hier das Überschreiben eines Dokuments beim Öffnen genannt.
  • Major – Die Folgen entsprechen im Wesentlichen den unter „Critical“ beschriebenen Folgen, aber es gibt einen Workaround.
    Um im Beispiel zu bleiben: Der Benutzer öffnet das Dokument nicht aus dem Programm heraus, sondern über den Windows-Explorer
  • Moderate – Das System produziert fehlerhafte Ergebnisse. Es kommt nicht zum Programmabbruch.
    Ein mögliches Beispiel hier: Eine Funktion, um einen automatischen Seitenumbruch zu erzeugen, ist fehlerhaft. Wenn man die Seitenumbrüche manuell setzt, sind Dokumente dennoch druckbar.
  • Minor – Die Folgen entsprechen im Wesentlichen den unter „Moderate“ beschriebenen Folgend. Das System liefert teilweise fehlerhafte Ergebnisse. Es kommt nicht zum Programm-Abbruch. Es gibt eine Möglichkeit, die Fehler zu umgehen.
    Als Beispiel sei hier genannt: Das nachträgliche Ändern der Größe einer Grafik in ein
  • Cosmetic – Das Aussehen bzw. das Verhalten der Software sollte verbessert werden (Logo ersetzen, Reaktion auf einen einfachen Klick anstatt eines Doppelklicks etc.)

Die Priorität definiert die Reihenfolge, in der Fehler behoben werden sollen.

  • High – Dieser Fehler muss schnellstmöglich behoben werden, da das System sonst nicht nutzbar ist. Der Fehler muss auf jeden Fall behoben werden, bevor das Produkt reif zur Auslieferung ist. Häufig bedeuten diese Fälle auch einen Stillstand im Software Testing. Daher ist es erforderlich, eine Zwischenversion zu erstellen, damit die Tests fortgeführt werden können.
  • Medium – Der Fehler muss vor Auslieferung des Produkts behoben werden. Das Testing Team wird in seiner Arbeit aber nicht behindert, so dass der Fehler im normalen, vereinbarten Entwicklungszyklus gelöst werden kann.
  • Low – diese Fehler sollten zuletzt betrachtet werden, wenn die schwerwiegenderen Fehler behoben sind.

Wenn alle Beteiligten im Entwicklungs-Umfeld sich auf diese Regeln einigen, ist es dem Triage-Team möglich, eine saubere Einteilung der Arbeit vorzunehmen. Wenn mit zweierlei oder dreierlei Maß gemessen wird, bedient man vielleicht die größten „Schreihälse“, aber nicht die wichtigsten Fehler.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.