Redakcja
W ostatnim czasie opublikowaliśmy ciekawy artykuł o tym, jak powinno wyglądać zgłoszenie defektu (https://testerzy.pl/baza-wiedzy/artykuly/jak-porzadnie-opisac-znaleziony-defekt). Teraz opisujemy kilka reguł związanych z defektami.
Uwaga! Poniższe zasady mogą nie być zgodne z regułami ISTQB®.
Zasada pewności
Rozwiązanie: Raportowanie błędu musi być poprzedzone analizą i upewnieniem się, czy mamy do czynienia z błędem oprogramowania.
Dlaczego: Jednym z najczęstszych błędów popełnianych przez testerów jest raportowanie błędów, które nie są błędami. Wynika to z naszego niezrozumienia kontekstu lub nieznajomości specyfikacji. Przed zaraportowaniem błędu, poprzez analizę, odpytanie eksperta lub też eksperyment, musimy więc odpowiedzieć sobie na pytanie, czy to na pewno jest błąd.
Wyjątek: Jesteśmy niedoświadczonymi jeszcze testerami, a nasze błędy będą przechodziły przez dodatkowy punkt weryfikacji.
Zasada pojedynczości
Rozwiązanie: Jeden błąd to jeden raport.
Dlaczego: Jeśli raport zawiera opis wielu zgłoszeń, to naprawienie jedynie części z nich zaczyna generować problemy. Nie możemy zamknąć zgłoszenia, ponieważ nie zostało rozwiązane w całości. Musimy za to przekazać informację o konieczności retestu, ale jak to zrobić jeśli nie możemy go przekazać w części do testera? Poza tym tracimy informację o metrykach. Co nam da informacja o ilości zgłoszonych defektów jeśli nie wiemy, ile w jednym zgłoszeniu może być defektów.
Wyjątek: Jeśli poprawka dla defektu może zostać zrobiona za jednym razem, to możemy raportować je łącznie. Przykładowo możemy zaraportować komunikat błędu z kilkoma literówkami.
Zasada tytułu
Rozwiązanie: Najważniejszym elementem raportu jest tytuł.
Dlaczego: Tytuł to element zgłoszenia, który będzie czytany najczęściej i musi jednoznacznie wskazywać, czego dotyczy błąd. Kiedy ktoś będzie przeszukiwał bazę w poszukiwaniu defektów po to, aby np. by nie popełnić duplikatu, najczęściej przejrzy tytuły zgłoszeń.
Wyjątek: Nie ma.
Zasada duplikatu
Rozwiązanie: Nie raportuj błędu, który już został zaraportowany.
Dlaczego: To kolejny przykład nieefektywności testerskiej. Zgłaszanie po wielokroć tego samego błędu skutkuje nadmiarową pracą dla innych członków zespołu. Przejrzyj repozytorium wszystkich defektów (np. trzy wyszukania) po słowach kluczowych błędu i upewnij się, że go tam nie ma.
Wyjątek: Jeśli coś wygląda jak duplikat, ale znajduje się w innej części aplikacji lub ma odmienne zachowanie, to może nie mieć tej samej przyczyny źródłowej. Zaraportuj, ale napisz, że „podobny do zgłoszenia X”.
Zasada prostoty
Rozwiązanie: Raport błędu w żołnierskich słowach powinien przekazać, co się wydarzyło i jak do tego dojść.
Dlaczego: Nie masz czasu na rozpisywanie się, a programista nie ma czasu na czytanie elaboratów. Krótki opis i zwięzłe kroki reprodukcji to podstawa. Nie tworzymy epopei narodowej - powtórzenia lub równoważniki zdań są bardziej niż mile widziane.
Wyjątek: Jeśli raportujemy do osoby (np. kogoś „z biznesu”), która może nie zrozumieć języka technicznego, musimy dodać więcej szczegółów.
Zasada wagi
Rozwiązanie: Waga jest ważna i powinna być częścią opisu błędu.
Dlaczego: Podanie wagi przez testera już przy pierwszym raportowaniu przynosi wymierne korzyści i możliwość sortowania zgłoszeń od tych, które otrzymały największą wagę. Jest to pierwsza estymacja i ustalenie priorytetów. Jeśli tester ma i wiedzę biznesową, i techniczną, jego zgłoszenia wnoszą dużą wartość do dalszej pracy nad błędem.
Wyjątek: Jeśli uznajemy, że w naszym oprogramowaniu nie ma miejsca na żadne błędy, to nie ma większego znaczenia, w jakiej kolejności będą naprawiane. Mogą być więc niewartościowane wagą.
Zasada pilności
Rozwiązanie: Pilny defekt powinien być zgłoszony pilnie.
Dlaczego: W projektach ważne jest, aby szybko dostarczać informacje o jakości. Jeśli w oprogramowaniu pojawia się błąd wielkiej wagi, to chcemy poinformować o nim możliwie jak najszybciej, aby szybko go naprawić.
Wyjątek: Gdy wiemy, że nasze zgłoszenie nie będzie szybko odczytane (np. raportujemy w weekend, gdy nikt nie pracuje), możemy odłożyć raportowanie w czasie.
Zasada nieraportowania
Rozwiązanie: Nie każdy błąd musi być raportowany.
Dlaczego: Choć w wielu źródłach przeczytacie, że wszystkie rzeczy należy zgłaszać, to jest to zazwyczaj opinia teoretyków. W praktyce nie zawsze będzie czas na raportowanie, nie zawsze będzie czas na naprawianie. Część defektów zdewaluuje się zanim je zgłosimy. Część jest tak trywialnych, że zapewne nikt ich nie zauważy, oprócz wprawnego oka testera. Jeśli masz czas i nieskończony budżet, raportuj wszystko. Jeśli jednak masz ograniczenia, raportuj tak, by uzyskiwać poprawki.
Wyjątek: Jeśli mamy małą wiedzę o tym, co dzieje się w oprogramowaniu i nie do końca możemy ocenić, co jest ważne, a co nie, wtedy raportujmy wszystko.
Zasada niereprodukowalności
Rozwiązanie: Nie zawsze da się zreprodukować defekt, ale to nie znaczy, że nie należy próbować.
Dlaczego: Defekty niereprodukowalne to często symptom czegoś naprawdę poważnego. Znalezienie czegoś takiego powinno zaświecić testerowi czerwoną lampkę w głowie i zachęcić do zbadania problemu.
Wyjątek: Możemy nie raportować defektu jeśli mamy uzasadnione przekonanie, że niekoniecznie wynika on z błędu oprogramowania, np. ktoś mógł wrzucić aktualizację na środowisko testowe.
