Priorytet i Ważność błędu

W dzisiejszym artykule spróbuję wyjaśnić, czym jest priorytet i ważność błędu. Wytłumaczę, dlaczego są tak istotne oraz jak poprawnie nadać ich wartości w kontekście defektu w aplikacji. Na koniec dodam przykłady błędów, których priorytet i ważność są przeciwne. Oba pola są jednymi z wielu wartości jakie ustawiamy podczas zgłaszania błędu.

Czym w takim razie jest Ważność błędu?

Ważność (eng. Severity) błędu daje nam informację, jak poważny jest defekt. Co za tym idzie na podstawie ważności dowiadujemy się, na ile wystąpienie błędu wpływa na możliwość korzystania z aplikacji czy funkcjonalności. Dla określenia wartości w polu Ważność stosuje się przeważnie sześciostopniową skalę wartości.

Blocker

Jest to najpoważniejszy błąd. Wartość „blocker” ustawiamy tylko w wypadku, kiedy aplikacja nie nadaje się do dalszych testów czy użytkowania. Innymi słowy proces testowy jest zablokowany i tylko poprawka może go udrożnić. Przy tego typu błędach blokujemy release aplikacji aż do momentu poprawienia usterek (przejścia review, retestu i zamknięcia jako poprawione).

Przykład: Po zalogowaniu do systemu nie jest możliwe wykonanie w nim żadnych czynności.

Critical

Krytyczną ważność otrzymują  defekty, które uniemożliwiają nam korzystanie w pełni z funkcjonalności w systemie, natomiast nie blokują nam procesu testowego. Tak samo jak w przypadku błędów typu „blocker” nie powinniśmy dopuszczać do release produktu przed poprawieniem błędów z tą ważnością.

Przykład: Po zalogowaniu do systemu nie jest możliwe generowanie faktur, ale zakupy i sprzedaż działają i można je testować.

Major

Priorytet „major” otrzymują błędy poważne w kontekście testowanego komponentu. Wpływają one na większą część testowanej funkcjonalności, natomiast nie uniemożliwiają korzystania z niej. To znaczy, że istnieje obejście problemu w ramach funkcjonalności, w której dany defekt występuje.

Przykład: Nie jest możliwe generowanie faktury przez zalogowanego klienta, ale administrator sklepu może to robić.

Normal

Taki błąd nie wpływa w większym stopniu na działanie testowanej funkcjonalności, użytkownik jest w stanie skorzystać z pełnych możliwości aplikacji.

Przykład: Wygenerowana faktura ma na końcu pustą stronę.

Minor

Defekty, które są marginalne z punktu widzenia systemu. Użytkownik nawet jeżeli się na nie natknie to nie powinien odczuwać dyskomfortu podczas używania systemu. Przeważnie są to literówki w głównych częściach aplikacji.

Przykład: Literówka na fakturze w słowie „Lista zakupów”.

Trivial

Jak sama nazwa wskazuje, są to błędy nieistotne z punktu widzenia aplikacji. Tak jak w przypadku wartości „minor”, wartością „triviwal” określamy głównie literówki. Różnica między obiema wartościami polega na tym, że wartość „trivial” ustawiamy dla błędów w częściach aplikacji, które są praktycznie nie używane przez użytkownika.

Przykład: Literówka na stronie z regulaminem sklepu.

Priorytet ustanawia, w jakiej kolejności błędy będą poprawiane

Podając wartość w polu Priorytet (eng. Priority) powinniśmy się zastanowić nad tym jak pilne jest wyeliminowanie defektu z punktu widzenia klienta. Z tego powodu zdarza się, że Priorytet nie jest tożsamy z Ważnością. Podumowując Priorytet stanowi informację na temat tego, które zadanie powinniśmy rozwiązać w pierwszej kolejności, a które w dalszej.
Do dyspozycji mamy następujące wartości.

Natychmiastowy

Wskazuje, że danym defektem powinniśmy się zająć w pierwszej kolejności. Zwykle są to błędy mające duży wpływ na aspekt biznesowy aplikacji.

Przykład: Po zalogowaniu do aplikacji nie można z niej korzystać.

Wysoki

Poprawienie błędu jest istotne z punktu widzenia biznesowego i powinniśmy się nim zająć możliwie jak najszybciej.

Przykład: Ikony umożliwiające udostępnianie treści w mediach społecznościowych działają ale wyglądają jakby były nieaktywne.

Normalny

Priorytet wskazujący, że dany defekt może zostać poprawiony jak już wszystkie bardziej priorytetowe zadania zostaną wykonane.

Przykład: Administrator nie może deaktywować użytkownika bezpośrednio na stronie z listą użytkowników, ale może to zrobić na stronie wyświetlającej szczegóły użytkownika.

Niski

Wskazuje nam, że danym błędem powinniśmy się zająć  jak już wszystkie inne zadania w ramach sprintu zostaną przez nas wykonane i zostanie nam odrobina czasu aby wykonać to zadanie.

Przykład: W wygenerowanej fakturze jest dodatkowa pusta strona.

W jaki sposób określić poprawnie ważność błędu?

Zanim wybierzesz wartość w polu Ważność błędu, odpowiedz sobie na pytania wymienione poniżej.

• Czy błąd wpływa na aspekt biznesowy aplikacji?
• Czy jest jakieś obejście problemu?
• Czy zwykły użytkownik łatwo natrafi na dany błąd?
• Jak bardzo uciążliwy jest ten błąd z perspektywy całej aplikacji?
• Czy błąd może mieć wpływ na zaufanie klienta do naszej pracy?

Pamiętaj, że nawet literówka może być błędem poważnym np. w wypadku kiedy zostanie popełniona w nazwie firmy, dla której robimy aplikację.

Czy zawsze określamy Priorytet i Ważność błędu?

Obecność pól Priorytet i Ważność w bug trackerze zależy od zasad przyjętych przez firmę. Na przestrzeni lat spotykałem się z sytuacją, w której pole Priorytet było niedostępne z poziomu Jiry czy Mantisa. Było to spowodowane założeniem, że testerzy lub inni członkowie zespołu będą w stanie poprawnie określić Ważność zgłoszenia. W takich sytuacjach Ważność decydowała o Priorytecie. 

Pytanie o to jak ustawiamy priorytet i ważność błędu jest jednym z pytań jakie zadawane są podczas rozmów rekrutacyjnych na stanowisko testera oprogramowania.