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.

Definicje rodzajów błędów w testowaniu aplikacji

  • Error: niezgodność pomiędzy dostarczonym przes funkcję, zaobserwowanym lub zmierzonym rezultatem jej wykonania, a oczekiwaną wartością. Błędy mogą być powodowane celowo w procesie testowania aplikacji.
  • Failure: niemożność komponentu lub systemu do wykonania operacji w np. określonym w wymaganiach czasie
  • Exeption:  nieobsługiwany wyjątek, który powoduje zawieszenie lub przerwanie działania programu. Wyjątek może pojawić się w związku z adresowaniem pamięci, danymi, wykonaną operacją, przepełnieniem zmiennej, itp.
  • Defect, bug, fault: wada modułu lub systemu, która może spowodować, że moduł lub system nie wykona zakładanej czynności. Defekt, który wystąpi podczas uruchomienia programu, może spowodować awarię modułu lub systemu. (za słownikiem terminów testowych 2.0)
  • deviation, incident – każde zdarzenie występujące w procesie testowania, które wymaga zbadania (IEEE 1008)