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.

Jak efektywnie zgłaszać błędy

Jak często widzisz programistów, którzy żądają więcej informacji na temat opisanego przez ciebie błędu? Jak często słyszysz, że błędu nie da się powtórzyć i spędzasz czas nad zgłoszonym już i opisanym bugiem?
Kończy się na tym, że więcej czasu poświęcamy na tego rodzaju przypadki niż na samo testowanie. Problem leży w jakości raportów o błędach.

Kiedy odkrywasz defekt, informujesz o nim programistę. Raport błędu jest nośnikiem tej informacji. Głównym celem tworzenia raportu jest umożliwienie programiście zobaczenie i zrozumienie problemu.

W skrócie: raport błędu jest dokumentem, który opisuje różnicę pomiędzy oczekiwanym rezultatem i aktualnym stanem np. funkcji systemu. Dostarcza też informacji jak wywołać błąd ponownie.

Po znalezieniu defektu.
– Zapisz tę informację od razu jak tylko upewnisz się, że to błąd. Nie czekaj do końca dnia.

– Poświęć czas na diagnozę błędu, który zgłaszasz. Pomyśl o możliwych przyczynach. Może okazać się, że odkryjesz więcej problemów w tym samym miejscu systemu. Nadmień o swoich przypuszczeniach przy opisywaniu błędu. Programiści będą ci wdzięczni, że zrobiłeś tę część pracy.

– Nie wysyłaj raportu od razu. Daj sobie czas na ponowne przeczytanie go i ewentualne dodanie/poprawienie części opisu.

– Nie wyolbrzymiaj znaczenia błędu w opisie.

– Jakikolwiek znalazłeś błąd pamiętaj, że opis dotyczy zaistniałej sytuacji nie zaś osoby, która kodowała daną funkcjonalność.

Dlaczego oprogramowanie zawiera defekty?

Przyczyny dla których w projekcie mogą pojawić się błędy, można przypisać do kilku grup.

Wprowadzone przez człowieka na każdym z etapów SDLC, począwszy od etapu analizy wymagań na instalacji gotowego produktu kończąc.

Sprzęt/środowisko. “Błędy” z tej grupy nie są wynikiem źle napisanego czy nieprzetestowanego kodu, ale jego brakiem, np. brak funkcji obsługującej sytuację w której zerwane zostaje połączenie sieciowe w trakcie przesyłania danych przez aplikację.

Złożoność systemu
Złożoność systemu może być trudna do zrozumienia dla kogoś bez doświadczenia w funkcjonującym dzisiaj sposobie tworzenia oprogramowania. Interfejsy wzorowane na oknach, technologia klient-serwer, aplikacje rozproszone, komunikacja danych i relacyjne bazy mają swój udział w szybko przyrastającej złożoności oprogramowania/systemów. Również użycie technik obiektowych, zamiast uprościć może skomplikować projekt jeżeli nie jest on dobrze skonstruowany.

Błędy w kodzie
Programiści jak każdy z nas, popełniają błędy. Część z nich może powstać w wyniku interpretacji źle lub niewystarczająco jasno zdefiniowanych wymagań. Zakładając, że błędów nie da się uniknąć i że zostaną one odnalezione przez testerów :) jest ważne aby być przygotowanym do zarządzania nimi za pomocą narzędzi komercyjnych np. Rational, lub opensource np. Mantis.

Zmieniające się wymagania
Klient może nie być świadomym efektów zmian lub chce je wprowadzić pomimo ryzyka z którego zdaje sobie sprawę – redefiniowanie wymagań, estymacja liczby godzin przeznaczonych na dodanie/modyfikację funkcjonalności, wpływ zmian na równoległe projekty, konieczność ponownego wykonania tej samej pracy lub porzucenia części działającego i przetestowanego już kodu, zmiana wymagań sprzętowych (zazwyczaj w górę).

Wiele drobnych lub kilka dużych zmian może wpłynąć na wytworzone (zdefiniowane lub nieformalne) zależności wewnątrz projektu i stać się przyczyną problemów, podobnie jak rosnąca złożoność procesu zarządzania.

Presja czasu
Planowanie w projektach informatycznych jest w najlepszym przypadku trudne, częściowo opiera się na przewidywaniu. Może zdarzyć się, że zbliżający się termin oddania aplikacji staje się jedynym wyznacznikiem jakości kodu.