Antwort.

Geschichte der Frage:

In den frühen Phasen des Testens wurden Fehler häufig ohne Systematisierung behoben. Mit der zunehmenden Komplexität der Software, einer steigenden Anzahl von Aufgaben und Bug-Trackern wurde die Notwendigkeit einer sinnvollen Priorisierung deutlich – damit Ressourcen zuerst auf kritische Probleme und nicht auf unwesentliche aufgewendet werden.

Problem:

Ohne Priorisierung können Tester, Manager und Entwickler Zeit mit kleinen Fehlern verschwenden und dabei kritische Fehler übersehen, die zu finanziellen oder rufschädigenden Verlusten und zu Ausfällen des Produkts führen können.

Lösung:

Einführung eines Prioritätensystems:

Die Priorität von Fehlern wird in "Kritisch", "Hoch", "Mittel", "Niedrig" (oder ähnliche Stufen) unterteilt
Die Priorität wird auf Basis des Einflusses des Fehlers auf das Geschäft, den Nutzer und die Gesamtheit des Systems festgelegt
In großen Teams geschieht dies gemeinsam mit dem Produktmanager

Wesentliche Merkmale:

Zeit- und Ressourcengewinn durch Fokussierung auf die für das Geschäft wichtigsten Defekte
Vermeidung von Konflikten zwischen QA-Team, Entwicklung und Geschäft
Flexibilität zur Überprüfung der Prioritäten, während sich die Situation ändert

Fangfragen.

Von was hängt die Priorität eines Fehlers ab – von der Schwere des Defekts oder von den Geschäftsprioritäten?

Von beiden Faktoren. Es gibt Fehler mit geringer technischer Schwere, die aber für das Geschäft kritisch sind (zum Beispiel ein Fehler im Preis eines Produkts auf der Zahlungsseite).

Sollten alle Fehler mit der gleichen Schwere die gleiche Priorität haben?

Nein, es ist wichtig, den Nutzungskontext, die Häufigkeit des Auftretens und den Einfluss auf die wichtigsten Geschäftskennzahlen zu berücksichtigen.

Kann sich die Priorität eines Fehlers im Laufe der Zeit ändern?

Ja, mit der Entwicklung des Projekts, der Änderung von Release-Plänen, dem Auftreten neuer Anforderungen oder dem Feedback von Nutzern können sich die Prioritäten verschieben.

Typische Fehler und Anti-Patterns

Gleichmäßige Festlegung eines hohen Prioritätsniveaus für alle Fehler
Diskussion der Prioritäten nur innerhalb von QA ohne Beteiligung des PO/Geschäfts
Ignorierung von Fehlern mit "niedriger" Priorität, die tatsächlich kritisch sind

Beispiel aus dem Leben

Negativer Fall

Auf einer E-Commerce-Website wurden kleine Fehler im visuellen Erscheinungsbild mit maximaler Priorität im Bug-Tracker erfasst, während Fehler im Zusammenhang mit Zahlungsintegrationsausfällen mit minimaler Priorität behandelt wurden.

Vorteile:

Schnelle Behebung der visuellen Probleme der Website

Nachteile:

Einnahmeverluste aufgrund nicht funktionierender Zahlungen, trotz "perfektem äußeren Erscheinungsbild" des Shops

Positiver Fall

Im Team wurden die Prioritäten gemeinsam festgelegt: Fehler, die die Zahlung und das Funktionieren von lebenswichtigen Funktionen behindern, wurden als "Kritisch" gekennzeichnet und zuerst bearbeitet.