Bugs: Severity vs. PriorityErfahrungen aus der Praxis

Alexei Vinogradov

Alexei Vinogradovfreiberuflicher IT-BeraterTest, Testmanagement, Testautomatisierung,Coaching

email: alexei@vinogradov-it.de skype: alexejvtwitter: @i_vinohttps://www.softwerkskammer.org/groups/testing

Severity vs. Priority Umfrage

SeverityDeutsch: Schwere, Schweregrad, Fehlerschweregrad (ISTQB)

„Der Grad der Auswirkungen, den ein Fehlerzustand auf Entwicklung oder Betrieb einer Komponente oder eines Systems hat“ (ISTQB)

„Wie schwer wird Betrieb beeinträchtigt, falls der Fehler nicht behoben wird“ (/me)

Severity

1-Hoch, Programmfunktion kann nicht mehr genutzt werden

2-Mittel, es existiert ein Workaround

3-Niedrig, keine Beeinträchtigung der Programmfunktionen

Severity

0-Blocker - Test der Komponente ist verhindert

Kein Muss für Sofort-Behebung

Priority

Die Stufe der Wichtigkeit, die einem Objekt (z.B. Fehler) zugeordnet worden ist (ISTQB)

Definiert eine Reihenfolge mit der Defekte behoben werden sollen. (/me)

Priority

1-High

2-Medium

3-Low

Priority

0-Alarm - Alles andere liegen lassen, sofort beheben (/me), analog zu Andon-Cord (Toyota)

Nicht zu viele offene Defekte mit Priority 1 lassen

Priority-Klassen anders als Severity-Klassen benennen

Severity vs. Priority

von Testteam vergeben

für Testberichte

von Entwicklung vergeben

für Planungsberichte

The End. Questions?

skype: alexejvemail: alexei@vinogradov-it.de twitter: @i_vino