Bug priority vs. bug severity

Zgłaszając błąd aplikacji, oprócz jego opisu, wersji środowiska, zrzutu ekranu czy załączników, określamy również jego priorytet i wpływ na działanie aplikacji.

Defect severity – określa jak bardzo krytyczny dla aplikacji jest zgłaszany błąd.
Defect priority – oznacza jak pilne jest poprawienie błędu.

Opis na przykładzie:
1. High Severity and Low Priority : Testujemy aplikację bankową generującą raporty tygodniowy, miesięczny i roczny. W raporcie rocznym jest błąd, który powoduje generowanie niewłaściwych danych. Jest to błąd krytyczny (high severity) jednak może zostać poprawiony w następnej wersji aplikacji (low priority).

2. Low Severity and High Priority : Błąd ortograficzny na głównej stronie popularnego serwisu internetowego. Pomimo, że nie ma on wpływu na funkcjonowanie strony, może przyczynić się do obniżenia wizerunku witryny.

3. High Severity and High Priority : Ponownie aplikacja bankowa. Tym razem błąd występuje w raporcie tygodniowym. Oprócz zagrożenia dla poprawności generowanych wyników, decydujący jest czas od zgłoszenia do naprawy błędu.

4. Low Severity and Low Priority : Błąd ortograficzny występuje na podstronie o oglądalności kilku wejść na miesiąc.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *