Redakcja
Tester zawsze musi pamiętać, że defekt defektowi nie równy. Mówiąc, że w oprogramowaniu mamy 100 defektów może być informacją zarówno o bardzo złej, jak i całkiem niezłej jakości. Aplikacja z setką poważnych defektów nie może zostać wydana, ale już aplikacja, która zawiera setkę trywialnych defektów bez problemu może trafić na produkcję.
W każdej organizacji klasyfikacja defektów wygląda inaczej i różnie się do nich podchodzi. Czasami są definiowane samodzielnie, a czasami przychodzą wraz z narzędziem zarządzania defektami. Prezentujemy jedną z prostszych klasyfikacji, która z powodzeniem może zostać użyta w większości projektów informatycznych.
| Kategoria | Opis |
|---|---|
| Krytyczny (ang. critical), Blokujący (ang. blocker) | Awaria systemu i/lub brak możliwości uruchomienia pewnych części aplikacji. Czasami „krytyczny” i „blokujący” mogą być traktowane jako osobne kategorie. Rekomendacje: produkt nie może zostać wydany. Przykład: aplikacja wyłącza się w czasie uruchomienia ważnego procesu biznesowego. |
| Poważny (ang. major) | Produkt niezgodny z wymaganiami lub tylko zaimplementowany jedynie w części. Rekomendacje: może być używany ale z poważnymi ograniczeniami. Przykład: defekt w krytycznym obszarze aplikacji, ale z możliwością obejścia. |
| Średni (ang. medium) | Pomniejsze i czasami akceptowalne problemy. Rekomendacje: produkt może być używany bez restrykcji. Przykład: Niepoprawne działanie w mniej ważnym obszarze aplikacji, które w niewielkim zakresie utrudnia pracę, ale jej nie blokuje. |
| Trywialny (ang. trivial), Niski (ang. minor lub low) | Defekty, które może wypatrzyć jedynie wprawne oko. Funkcje działają poprawnie mogą być jedynie niepoprawnie opisane, umieszczone lub graficznie zaprezentowane. Rekomendacje: produkt może zostać wydany. Przykłady: Literówki, niepoprawne kolory na ekranie. |
Krytyczności defektów nie należy mylić z priorytetami. Różnicę opisaliśmy w artykule "Ważność i priorytet. Ocena defektów".
Czasami w raportach defektów może pojawić się zgłoszenie, które nie jest defektem, ale nie jest też pomyłką testera. Może to być rozszerzenie (ang. enhancement), usprawnienie (ang. improvement) lub nowa funkcja (ang. new feature). Wynikają one zazwyczaj z tego, że specyfikacja nie precyzuje jak dokładnie ma działać aplikacja, a osoba testująca dostrzega, że coś mogłoby działać lepiej. Przy wartościowaniu krytyczności zgłoszenia takie zgłoszenia zazwyczaj wpadają na koniec listy już po defektach trywialnych.
