Was sind die Gründe für die Änderung der Status von Schweregrad und Priorität im Testprozess?

Die Änderung der Status von Severity und Priority eines Fehlers im Testprozess kann aus mehreren Gründen erfolgen:

1. Änderung des Verständnisses der Auswirkung des Fehlers auf das Produkt: Anfangs wurde die Auswirkung möglicherweise unterschätzt (z.B. wurde es als UI-Problem angesehen, das sich jedoch auf eine kritische Geschäftslogik auswirkt) oder überschätzt.
2. Änderung der Geschäftsanforderungen oder Prioritäten: Wenn der Fehler eine Funktion betrifft, die für das Geschäft wichtiger oder weniger wichtig geworden ist, kann seine Priorität angepasst werden.
3. Entdeckung eines Workarounds: Wenn eine einfache Möglichkeit gefunden wird, den Fehler zu umgehen, ohne wesentliche Verluste für den Nutzer, kann seine Priority gesenkt werden. Severity bleibt in der Regel gleich, da der Workaround das Problem selbst nicht behebt.
4. Abhängigkeit von anderen Fehlern: Die Behebung eines Fehlers kann die Auswirkungen eines anderen verschärfen oder mildern, was eine Neubewertung ihrer Status erfordern kann.
5. Änderung der Anzahl der betroffenen Nutzer: Wenn ein zunächst unbedeutender Fehler bei einer großen Anzahl von Nutzern entdeckt wird, kann seine Priority erhöht werden.
6. Fehlerhafte Anfangseinschätzung: Der Tester könnte Severity oder Priority falsch eingeschätzt haben, aufgrund unzureichender Kenntnisse des Kontexts, der Funktionalität oder der Geschäftsprozesse.
7. Änderung der Entwicklungs-/Testphase: In verschiedenen Phasen (z.B. Unit-Tests, Integration, System, Abnahme) kann die Wahrnehmung des gleichen Fehlers unterschiedlich sein.
8. Entscheidung des Teams oder Managers: Die endgültige Entscheidung über Severity und Priority wird oft gemeinsam mit dem Teamleiter, Projektmanager oder Product Owner getroffen, insbesondere bei strittigen Fällen.
9. Entdeckung neuer Nutzungsszenarien: Wenn der Fehler in mehr Szenarien auftritt als ursprünglich angenommen, können Severity oder Priority erhöht werden.

Statusänderungen sollten stets begründet und im Fehlerverfolgungssystem dokumentiert werden.