Błąd wykryty - ale co dalej? - pełna wersja do pobrania

GRZYBOBRANIE CZAS ZACZĄĆ
Raportowanie wykrytych błędów to chleb powszedni każdego testera. I każdy tester wie, że to zadanie łatwe i proste nie jest.Pierwszy problem, jaki napotykamy po wykryciu błędu to pytanie ‘błąd to czy nie błąd?’. Postaram się podać definicję błędu. Mimo, że potocznie używamy słowa ‘błąd’, tak naprawdę mamy na myśli awarię lub usterkę. Awaria (ang. failure), czyli odstępstwo systemu od spodziewanego zachowania lub wyniku działania oprogramowania. Usterka (ang. fault), czyli wada systemu spowodowana na skutek błędu programisty. Rozwiązanie pierwszego problemu jest już chyba proste. Powinniśmy niezwłocznie zaraportować błąd, gdy w testowanym przez Nasz systemie zauważymy zachowanie pasujące do powyższych definicji. Zatem ‘do klawiatur’, gdy:

• system działa nieprawidłowo, a działanie to powtarza się przy wystąpieniu określonych warunków;
• działanie systemu jest niezgodne z wymaganiami lub obowiązującymi standardami,
• dokumentacja techniczna jest niezgodna z dokumentacją biznesową,
• dokumentacja użytkownika nie zgadza się z dokumentacją techniczną.

Problem pierwszy już rozwiązany. Ale jak to w życiu od razy pojawia się kolejny. Chyba każdy tester, choć raz zastanawiał się jak zaraportować wykryty błąd, tak by programista lub inny członek zespołu projektowego mógł błąd zreprodukować. Postarajmy się określić listę wszystkich danych, które powinny zostać umieszczone w raporcie błędu.

WSKAZÓWKI JAK WKŁADAĆ GRZYBA DO KOSZYKA
Na początek ‘szczypta’ historii, czyli jeden z najstarszych zachowanych raportów błędu. Na początku była … ćma. To pośrednio temu owadowi zawdzięczamy dzisiejsze potoczne określenie błędu. Prawdziwą ‘matką chrzestną’ buga była Grace Murray Hopper. Grace Hopper 9 września 1947 roku, jak co dzień, przeprowadzała testy prototypu komputera Mark II. Niestety testy musiały zostać przerwane z powodu spięcia. Grace jest do tego przyzwyczajona, wszak poprzednikowi aktualnie testowanego prototypu - komputerowi Mark I - zdarzało się to nawet kilka razy dziennie. Po otwarciu pokrywy okazało się, że między styki przekaźnika nr 70 na panelu F maszyny Mark II Aiken Relay Calculator dostała się mała ćma. Grace nie pozwala wyrzucić ćmy i wklejając ją do dziennika incydentów (odpowiednik dzisiejszych logów) tworzy pierwszy ‘bug report’. Pisząc o pionierach, którzy usterki nazywali Bugami, należy także oddać hołd Edisonowi, który już w 1878 roku użył słowa ‘bug’. Jednak to Grace Murray Hopper udało się wprowadzić buga do języka informatyki.Pierwszego buga w historii można zobaczyć w National Museum of American History w Waszyngtonie lub na rysunku 1.

Rys. 1. Pierwszy ‘Bug report’

Pani kontradmirał Grace Murray Hopper tworząc pierwszy raport nie miała pojęcia ile problemów może napotkać tester tworząc raport błędu w dzisiejszych czasach.
Zanim zaczniemy się zastanawiać, co powinien zawierać raport błędu popatrzmy, czym powinien się charakteryzować dobrze przygotowany raport. Raport błędu powinien:

• opisywać tylko jeden konkretny błąd;
• zostać stworzony niezwłocznie po wykryciu błędu;
• zostać napisany w sposób pozwalający na reprodukcję błędu;
• zawierać wszystkie potrzebne informacje pozwalające programiście zlokalizować przyczynę występowania błędu;
• być zwięzły i jednoznaczny.
  

Co zatem powinien zawierać dobry raport błędu?

Identyfikator błędu
Identyfikator pozwala na szybką identyfikację błędu oraz powinien być unikalny,
co najmniej w obrębie testowanego systemu.

Temat błędu
Dobrze sformułowany temat jednoznacznie określa raportowany błąd. W temacie warto określić miejsce występowania oraz skutki błędu. Pozwoli to na szybkie przeglądanie raportów błędów bez konieczności wchodzenia w szczegóły każdego z nich.

Kroki reprodukcji
Aby programista mógł poprawić zgłoszony przez nas błąd potrzebuje dokładnych informacji jak go zreprodukować. Warto opisywać kolejne wykonywane czynności
w punktach. Opis powinien być precyzyjny i zawierać wszystkie, nawet najdrobniejsze kroki wykonywane w celu ponownego wywołania błędu.

Działanie obserwowane
Kolejną ważną informacją jest dokładny opis skutków wykrytego błędu. Szczegółowe opisanie błędnego działania systemu pozwala programiście na szybsze zidentyfikowanie miejsce występowania błędu oraz jego przyczyny. Warto dołączać do raportu zrzuty ekranu lub logi, pozwoli to programiście na lepsze zrozumienie raportowanego błędu, co przełoży się na szybsze wykrycie przyczyny błędu. Czasami jest to także jedyny dowód na wystąpienie błędu, w przypadku, gdy jego reprodukcja jest niemożliwa.

Działanie oczekiwane
Programista, który będzie poprawiał zgłoszony przez nas błąd powinien bardzo dobrze znać prawidłowe zachowania systemu. Warto jednak w raporcie umieścić prawidłowe zachowanie systemu, zmniejszymy w ten sposób prawdopodobieństwo wprowadzenia błędnej poprawki do systemu. Warto też podeprzeć się dokumentacją projektową (np. analizą wymagań projektowych) lub dokumentacją testową (np. odpowiednim przypadkiem testowym).

Waga błędu
Waga określa, w jakim stopniu raportowany błąd wpływa na możliwość i komfort pracy użytkownika systemu. Błąd, który uniemożliwia pracę z systemem powinien otrzymać najwyższą wagę, zaś błąd pozwalając na bezproblemową pracę - najniższą. Najczęściej spotykane wagi błędu:

• blokujący (ang. Blocker), gdy np. główne funkcjonalności systemu nie zostały zaimplementowane; 
• krytyczny (ang. Critical) to np. niepoprawne działanie głównych funkcjonalności systemu lub czyszczenie danych;
• ważny (ang. Major) to np. niepoprawne działanie pozostałych funkcjonalności systemu;
• normalny (ang. Normal), gdy np. raportowany błąd nie ma wpływu na funkcjonalność systemu;
• błahy (ang. Minor, Trivial) to np. błędy kosmetyczne, ortograficzne czy gramatyczne.

Priorytet błędu
Priorytet sugeruje, jak szybko raportowany błąd powinien zostać poprawiony, a nowa wersja systemu wraz z poprawkami dostarczona do testów. Bardzo często wraz
z priorytetem błędu definiuje się także czas reakcji na błąd.

Produkt/System
Niezbędne do kompletnego opisu błędu jest podanie, w jakim testowanym produkcie
czy systemie został wykryty raportowany błąd. Wyobraźmy sobie sytuację,
że przeprowadzamy testy dwóch systemów bilingowych dedykowanych do dwóch różnych krajów europejskich. Brak wskazania systemu, w którym wykryto błąd może spowodować poszukiwanie przez programistę przyczyn błędu w tym systemie, w którym ten błąd nie występuje.

Komponent
Podczas raportowania błędu warto również podać, w którym komponencie (module) został wykryty błąd. Pozwoli to programiście na szybsze zlokalizowanie przyczyny błędu
i wprowadzeniu poprawek.

Wersja testowanego systemu
Bardzo ważną informacją dla programisty, o której należy pamiętać, jest numer wersji testowanego systemu, w której błąd został znaleziony. Numer wersji jest też przydatny podczas przeprowadzania testów regresji.

System operacyjny
W przypadku, gdy testy przeprowadzane są na dedykowanym systemie operacyjnym,
lub na kilku różnych systemach warto także podać nazwę systemu. Podobnie sytuacja wygląda z sprzętem, jeśli taka informacja może okazać się przydatna warto ją umieścić w raporcie błędu.

Oczywiście każdy raport powinien także zawierać datę zgłoszenia błędu, dane osoby zgłaszającej oraz osoby odpowiedzialnej za wprowadzenie poprawek.

Tym samym udało się rozwiązać drugi z naszych problemów. Wydawałoby się, że zadanie wykonane i obsługę błędu mamy już za sobą. Nic bardziej mylnego, zaraportowanie błędu to dopiero początek. Przed nami kolejne wyzwanie i kolejny problem: co dalej z błędem, który został zaraportowany?

SUSZENIE, MARYNOWANIE CZY MOŻE DIP GRZYBOWY
Przyjrzyjmy się dokładniej ‘fazom życia’ naszego błędu. W której fazie znajduje się błąd możemy rozpoznać po jego statusie.

Raportowanie błędu
Rozpoczynamy przygodę, błąd został zidentyfikowany i został stworzony raport błędu. Błąd po zaraportowaniu ma status ‘Nowy’ (ang. New). Kolejnym krokiem jest wyznaczenie programisty odpowiedzialnego za znalezienie przyczyny błędu
i wprowadzenie poprawek do systemu. Po przydzieleniu błędu do programisty, jego status zmienia się na ‘Przypisany’ (ang. Assigned).

Poprawa błędu
Programista, któremu błąd został przydzielony identyfikuje przyczyny błędu i wprowadza poprawki. Po przeprowadzeniu testów wprowadzonych zmian oraz dodaniu komentarza o poczynionych zmianach programista zmienia status błędu na ‘Rozwiązany’ (ang. Resolved).
To nie jedyny przypadek, gdy programista traktuje błąd jako rozwiązany. Poniżej znajdziecie kilka innych sytuacji, gdy błąd dostaje właśnie taki status:

• gdy zgłoszony błąd okazuje się duplikatem już istniejącego, programista po powiązaniu go z błędem-duplikatem zmienia status błędu na ‘Duplikat’ (ang. Duplicate) i traktuje błąd jako rozwiązany;
• gdy zreprodukowanie błędu nie powiodło się ani w środowisku developerskim ani
  w środowisku testowym, programista po dodaniu komentarza zmienia status błędu na ‘Niepotwierdzony’ (ang. Worksforme) i traktuje błąd jako rozwiązany;
• gdy po zgłoszeniu błędu okazuje się, że to jednak nie jest błąd, programista po wprowadzeniu komentarza z uzasadnieniem zmienia status na ‘Nie-błąd’ (ang. Invalid) i traktuje błąd jako rozwiązany;
• gdy zgłoszony błąd nie zostanie poprawiony, ponieważ np. poprawka jest niemożliwa lub zbyt kosztowna, programista po wprowadzeniu komentarza z uzasadnieniem zmienia status na ‘Nierozwiązywalny’ (ang. Wontfix) i traktuje błąd jako rozwiązany.

Weryfikacja błędu
Po podjęciu decyzji o stworzeniu kolejnej wersji przeznaczonej do testów, do każdego
z rozwiązanych błędów wchodzących do wersji osoba zarządzająca wersjami dodaje komentarz. Komentarz powinien zawierać informację, w której wersji błąd został poprawiony. Dodatkowo tester powinien otrzymać listę wszystkich błędów, które należy zweryfikować podczas testów otrzymanej wersji systemu.
Po dostarczeniu wersji z poprawionymi błędami tester rozpoczyna testy regresji. Regresji podlegają tylko błędy mające status ‘Rozwiązany’ (ang. Resolved), które zostały włączone do testowanej wersji. Gdy błąd został poprawiony tester dodaje komentarz potwierdzający poprawkę i zmienia status błędu na ‘Zweryfikowany’ (ang. Verified). W przypadku, gdy błąd nadal występuje tester ponownie przekazuje błąd do programisty odpowiedzialnego za wprowadzoną poprawkę i wprowadzając stosowny komentarz, zmienia status błędu na ‘Ponownie otwarty’ (ang. Reopened).

Zamykanie błędu
Wszystkie błędy ze statusem ‘Zweryfikowany’ (ang. Verified) powinny zostać zamknięte przez osobę raportującą błąd. Po zamknięciu błąd otrzymuje status ‘Zamknięty’ (ang. Closed) i tym samym ‘cykl życia' błędu zostaje zakończony.

Ostatni problem został rozwiązany i udało się ustalić wszystkie fazy życia błędu:

• raportowanie błędu (statusy: Nowy, Przypisany);
• poprawa błędu (statusy: Rozwiązany, Duplikat, Niepotwierdzony, Nie-błąd, Nierozwiązywalny);
• weryfikacja błędu (statusy: Zweryfikowany, Ponownie otwarty);
• zamykanie błędu (status: Zamknięty).

Wszystkie problemy udało nam się szczęśliwie rozwiązać. Nasz błąd został zaraportowany, poprawiony i zweryfikowany, może, więc warto się zastanowić jak można ułatwić te trudne i czasami skomplikowane zadania. W walce ze zgłoszonymi błędami mogą nam pomóc narzędzia do śledzenia błędów tzw. Bug Trackery.

KOSZYK PEŁEN GRZYBÓW
We wtorki na Nowym Kleparzu w Krakowie króluje wiklina. Małych koszyków i ogromnych koszy jest tam mnóstwo, do wyboru do koloru. Podobnie wygląda rynek narzędzi do zarządzania błędami, można się o tym przekonać chociażby wpisując do przeglądarki hasło ‘bug tracker’.
Przypatrzmy się dwóm z nich, obydwa są narzędziami open source i obydwa znacznie mogą ułatwić nam raportowanie i obsługę już zgłoszonych błędów. Chociaż obydwa narzędzia mają ogrom możliwości i wykorzystywane są nie tylko do zarządzania błędami, zerkniemy jedynie na funkcje dotyczące zgłoszenia i śledzenia błędu.

Bugzilla nadchodzi
Zacznijmy od narzędzia, które większość z Was zapewne zna chociażby ze słyszenia – to Bugzilla, jeden z produktów Mozilli.
Zobaczmy się jak wygląda Bugzilla ‘od środka’. Wykryliśmy błąd i chcemy go zaraportować. Zatem do Bugzilli! Logujemy się, wybieramy z listy testowany produkt
i przechodzimy do dość przyjaznego i czytelnego interfejsu (rysunek2).

Rys. 2. Bugzilla: raportowanie błędu

Podczas raportowania błędów, w Bugzilli nazywanych bugami, część danych raportu jest wypełniana automatycznie. Wprowadzenie pozostałych danych jest proste i intuicyjne, ponieważ interfejs Bugzilli zawiera większość pól określających dobry raport błędu. Dzięki takim podpowiedziom stworzony przez nas raport będzie kompletny.
Popatrzmy, jakie dane raportu błędu wypełnia Bugzilla, a o czym musimy pamiętać sami.
Dane wprowadzane przez testera:

• wersja testowanego systemu;
• komponent;
• waga;
• priorytet;
• system operacyjny;
• sprzęt;
• osoba odpowiedzialna za poprawę błędu;
• temat;
• opis.

Dane przypisywane automatycznie:

• identyfikator (unikalny numer w obrębie wszystkich produktów);
• osoba zgłaszająca;
• data zgłoszenia;
• produkt

Mamy też możliwość wprowadzenia słów kluczowych, powiązania błędu z innymi już istniejącymi, a także dodania dowolnego załącznika. Możemy też przesłać mailem zaraportowany błąd do zainteresowanych osób. Niestety musimy pamiętać o dokładnym opisaniu w punktach kroków pozwalających na reprodukcję błędu oraz wprowadzeniu działań obserwowanych i oczekiwanych (pole ‘Opis)’. Po zakończeniu raportowania dostajemy wszystkie niezbędne informacje dotyczące błędu na jednym ekranie widocznym na rysunku 3.

Rys. 3. Bugzilla: raport błędu

Po zaraportowaniu błędu, w każdym momencie mamy możliwość zmodyfikowania błędu, dodania komentarza lub załącznika. O wszystkich zmianach Bugzilla informuje nas także drogą mailową.
Bugzilla pozwala nam na zarządzanie błędem, od jego zgłoszenia aż do zamknięcia. Mamy do wyboru dwa parametry określające stan, w jakim znajduje się zaraportowany błąd. Pierwszy to status, który określa, w jakiej fazie znajduje się nasz błąd. Drugi parametr określa sposób rozwiązania i jest uzupełnieniem statusu. Jak można zauważyć na każdym etapie życia stan błędu jest bardzo dokładnie określony i moim zdaniem jest to jeden z większych plusów Bugzilli. Zgłoszone błędy, a także ich statusy można śledzić przeglądając listę wszystkich zgłoszonych błędów. Jak wygląda przykładowa lista błędów w Bugzilli możecie zobaczyć na rysunku 4.

Rys. 4. Bugzilla: lista błędów

Bugzilla pozwala także na wyszukiwanie śledzonych przez Nas błędów oraz tworzenie raportów. Mamy do dyspozycji trzy sposoby wyszukiwania interesujących nas błędów:

• wyszukiwanie pojedynczego błędu;
• wyszukiwanie proste;
• wyszukiwanie złożone

Jeśli chcemy przeglądać wszystkie błędy, lub interesują Nas tylko błędy otwarte bądź zamknięte, Bugzilla oferuje Nam prosty panel wyszukiwania (rysunek 5).

Rys. 5. Bugzilla: proste wyszukiwanie

Jeśli znamy dane parametry szukanych błędów (np. status bądź priorytet) to Bugzilla proponuje o wiele bardziej szczegółową wyszukiwarkę. Jak można zauważyć liczba możliwych konfiguracji interesujących Nas błędów jest dość spora (rysunek 6). Plusy takiego szczegółowego wyszukiwania zapewne docenicie w trakcie tworzenia raportu z przeprowadzonych testów.

Rys. 6. Bugzilla: złożone wyszukiwanie

Bugzilla, jak już pewno zauważyliście posiada ogromne możliwości, jeśli chodzi
o raportowanie, zarządzanie i śledzenie błędów. Ułatwia też znacznie komunikacje na linii tester – programista, a każdy z Nas wie jak taka komunikacja jest ważna.
Czy zatem wybierzecie Bugzillę? Wybór należy oczywiście do Was, ale zerknijcie też na drugie narzędzie.

A może jednak Trac?
Trac to wielka ‘machina’ pozwalająca zarządzać całościowo projektem. Ma również moduł do raportowania i zarządzania błędami, które w Tracu nazywają się ticketami.
Zatem do dzieła, raportujmy wykryty błąd. Po zalogowaniu się do Traca i przejściu do modułu raportowania błędów pokazuje się nam prosty formularz pozwalający na zgłoszenie błędu (rysunek 7).

Rys. 7. Trac: raportowanie błędu

Podczas raportowania błędów, tak jak i w Bugzilli, część danych raportu jest wypełniana automatycznie. Pozostałe dane wprowadza tester. W Tracu mamy możliwość wyboru danych, które powinien zawierać formularz raportu. Możemy zrezygnować np. z określenia wagi błędu i wtedy podczas zgłaszania błędu podanie wagi błędu będzie możliwe jedynie w polu opisowym. Zerknijmy jak wygląda podział pomiędzy danymi wprowadzanymi automatycznie, a tymi, które powinien wprowadzić tester.
Dane wprowadzane przez testera:

• wersja testowanego systemu;
• komponent;
• waga;
• priorytet;
• osoba odpowiedzialna za poprawę błędu;
• temat;
• opis.

Dane przypisywane automatycznie:

• identyfikator (unikalny numer w obrębie wszystkich produktów);
• osoba zgłaszająca;
• data zgłoszenia;
• produkt.

Podobnie jak w Bugzilli mamy możliwość wprowadzenia słów kluczowych i dodania dowolnego załącznika. Możemy też określić grupę osób, która powinna otrzymać raport błędu lub powiązać błąd z milestonem. Niestety znowu musimy pamiętać o dokładnym opisaniu kroków błędu oraz wprowadzeniu działań obserwowanych i oczekiwanych (pole ‘Opis)’. Dodatkowo, jeśli chcielibyśmy określić system operacyjny lub sprzęt, na którym są przeprowadzane testy, to jest to możliwe jedynie w polu opisu.

Po zaraportowaniu błędu, możemy modyfikować dane raportu, a wszystkie zmiany są widoczne w historii błędu.

Trac tak jak większość narzędzi do zarządzania błędem pozwala nam na śledzenie błędu, od jego zgłoszenia aż do zamknięcia. Ponownie mamy do wyboru dwa parametry określające stan, w jakim znajduje się zaraportowany błąd. Pierwszy to status, który określa, w jakiej fazie znajduje się nasz błąd. Drugi parametr określa sposób rozwiązania i jest uzupełnieniem statusu. Zmiana statusu błędu w Tracu jest traktowana jako modyfikacja błędu. Pamiętając o dodaniu odpowiedniego komentarza wybieramy jeden z dostępnych statusów z listy i akceptujemy zmianę. Okno, w którym dokonujemy modyfikacji błędu zostało przedstawione na rysunku 8.

Rys. 8. Trac: raport błędu
 

Podczas śledzenia błędów ułatwieniem powinna być kolorowa lista błędów. Trac automatycznie przypisuje wybrany kolor odpowiednim statusom błędów. Czy kolorowa lista błędów przypadnie Wam do gustu możecie sprawdzić sami – spójrzcie na rysunek 9 - Trac: lista błędów.

Rys. 9. Trac: lista błędów

Niestety w Tracu rozwiązanie błędu jest równoznaczne z jego zamknięciem, dlatego przeprowadzenie weryfikacji błędu może sprawiać trudności. Ustalenie, które błędy zostały poprawnie zamknięte (czyli rozwiązane i zweryfikowane), a które tylko rozwiązane, jest możliwe jedynie poprzez przeglądanie komentarzy błędu informujących o przeprowadzonej weryfikacji. Określenie, na którym etapie życia jest nasz błąd nie jest już takie proste.
Jeśli chcemy wyszukać interesujące Nas błędy lub niezbędny Nam jest raport uwzględniający różne rodzaje znalezionych błędów Trac proponuje dwa rozwiązania: zestaw gotowych raportów lub złożoną wyszukiwarkę.
Jeśli zadowolą Nas gotowe raporty lub chcemy wyszukać np. jedynie błędy otwarte, Trac proponuje dziewięć raportów widocznych przedstawionych na rysunku 10.

Rys. 10. Trac: zestawienia błędów - raporty

Jeśli jednak mamy wyższe wymagania możemy stworzyć własną listę szukanych błędów. Trac oferuje zestaw ‘klocków - zapytań’, za pomocą których każdy może wyszukać listę interesujących go błędów. Interfejs wyszukiwarki, zaprezentowany na rysunku 11, przedstawia dwanaście parametrów, po których możemy wyszukiwać błędy.

Rys. 11. Trac: zestawienia błędów - wyszukiwarka

Możliwości Traca, jak można zauważyć są ogromne. Trac pozwala na raportowanie
i śledzenie błędów od momentu zgłoszenia aż do zamknięcia. Wielkim plusem Traca jest integracja z repozytorium czy Wiki projektowym – wszystkie informacje zostały zebrane w jednym miejscu. Niestety weryfikacja błędu, poprzez brak odrębnego statusu, jest utrudniona. Trac oferuje także inny sposób wyszukiwania błędów i tworzenia raportów, czy statystyk błędów, które jak wiecie bardzo pomagają podczas tworzenia raportu z testów.
Czy zatem wybierzecie Traca? Wybór należy jak zawsze do Was.

Bugzilla czy Trac oto jest pytanie – odpowiedź musicie znaleźć już sami. Więcej informacji znajdziecie na oficjalnych stronach: www.bugzilla.org i trac.edgewall.org.

Pamiętajcie jednak proszę, że narzędzia tylko pomagają w osiągnięciu celu. Raportowanie i śledzenie błędów nadal należy do nas, Bug Trackery pozwalają jednak lepiej zarządzać zgłoszonymi błędami.