Rozdział 18

Rozdział 18  Raportowanie wyników
W TYM ROZDZIALE Co zrobić, żeby błędy były naprawiane Izolowanie i odtwarzanie błędów Błąd błędowi nierówny Cykl życiowy błędu Systemy śledzenia błędów
Patrząc na testowanie z oddalenia, dostrzec można w najszerszym zarysie trzy główne zadania: planowanie testów, samo testowanie oraz temat tego rozdziału - raportowanie wyników.
Na pierwszy rzut oka może się wydawać, że raportowanie odkrytych problemów jest najłatwiejsze z tych trzech zadań. W porównaniu z ilością pracy konieczną do planowania i z umiejętnościami niezbędnymi, by skutecznie znajdować błędy, opowiedzenie innym że znalazło się błąd powinno przecież być prostsze i nmiej czasochłonne. W rzeczywistości, jest to najważniejsze - i czasami najtrudniejsze - z zdań jakie stoją przed testerem.
Najważniejsze punkty tego rozdziału: 61.Częmu błędy nie zawsze zostaja naprawione 62.Co można zrobić, by zwiększyć szansę naprawienia błędów 63.Jakimi metodami izolować i ponownie wywoływać znalezione błędy 64.Jak przyebiega życie błędu - od jego narodzin aż do śmierci 65.Jak śledzić i kontrolować błędy ręcznie lub przy pomocy bazy danych Mały Kurczak ma kłopot Mały Kurczak był pewnego razu w lesie, kiedy na głowe spadł mu żołądź. Tak go to przeraziło, że cały zadrżał. Trząsł się tak, że aż zgubił połowę piór. „Pomocy, pomocy! Niebo się wali! Musze pobiec powiedzieć królowi!” - zawołał Mały Kurczak.
I kurczak pobiegł w wielkim strachu opowiedzieć królowi. PO drodze spotkał Henny Penny. „Dokąd idziesz, Mały Kurczaku?” - spytał Henny Penny. „Och, pomocy! Niebo się wali!” - odpowidział Mały Kurczak. „Skąd wiesz?” - zapytał Henny Penny. „Widziałem to na własne oczy, słyszałem to na własne uszy, a część nieba spadła mi na głowę!” - odpowiedział Mały Kurczak. „To straszne, po prostu straszne! Lepiej pośpieszmy się!” - zawołał Henny Penny. I obaj pobiegli jak najszybciej tylko umieli. W tej popularnej dziecinnej bajeczce, Mały Kurczak wpada w szok, kiedy staje się coś nieoczekiwanego i ucieka w panice, wołając na cały świat, co mu się wydaje. Pomuślmy, jak Mały Kurczak zachowałby się znalazłszy błąd oprogramowania! Jak zareagowałby na to kierwonik projektu albo programista? Jest wiele interesujących podobieństw między tą historyjką a testowaniem oprogramowania - warto mieć ją w pamięci czytając ten rozdział. Co zrobić, żeby błędy były naprawiane
Dawno temu w rozdziale 3-im „Test oprogramowania w rzeczywistości” dowiedzieliśmy się, że mimo wszelkich starań podczas planowania i wykonywania testów, nie wszystkie znalezione błędy1 zostaną naprawione. Niektóre zostaną całkowicie odrzucone, inne mogą być odroczone z zamiarem naprawienia ich dopiero w kolejnej wersji oprogramowania. Z początku taka możliwośc wydawała się nieco zniechęcająca czy wręcz groźna. Tearz, wiedząc już o wiele więcej na temat testowania, przypusczalnie łatwiej nam zrozumieć, czemu w rzeczywistości nie wszystkie błędy są naprawiane.
Oto wymienione w rozdziale 3-im powody, dla których nie wszystkie błędy zostają naprawiane: 66.Brakuje czasu. W każdym porjekcie zawsze jest zbyt wiele funkcji, zbyt mało załogi i nie dośc czasu w harmonogramie. Jeśli pracuje się nad programem do deklaracji podatkowych, data składanie deklaracji się nie zmieni - program musi być gotowy w terminie.
1 Tutaj przydałoby się rozróżnienie między "awarią" (dającym się zaobserwować nieprawidłowym działaniem programu) oraz "błędem" (przyczyną tej nieprawidłowości), by uczynić wywód jaśniejszym. Autor jednak konskwentnie używa tego samego słowa "bug" na określenie raz przyczyny błędu, a raz - jego objawów.
67.To nie jest naprawdę błąd. Znane jest powiedzonko „To nie błąd, to funkcja!” Częste są nieporozumienia, błędy w testownaniu lub zmiany specyfikacji powodujące, że pozorne błędy zostają zaklasyfikowane jako pożądane funkcje. 68.Za duże ryzyko naprawy. Niestety, tak często jest. Oprogramowanie jest delikatne, splątane, czasem jak makaron nitki. Można wtedy naprawiając jeden błąd „obudzić” inne, wcześniej ulryte błędy. Pod naciskiem wymagań wypuszcznia programu miomo przykrótkiego harmonogramu, jakiekolwiek zmiany mogą być zbyt ryzykowne. Lepiej może być zostawić w spokoju już znany błąd, niż ryzykować pojawienie się nowych, nieznanaych. 69.Po prostu nie warto. To może brzmi brutalnie, ale taka jest rzeczywistość. Błędy które występują niezbyt często albo w rzadko używanych funkcjach można pominąć. Błędy dla których istnieją obejścia, czyli metody jak je omijać, często uznaje się za niewarte naprawy. Rzecz sprowadza się do decyzji biznesowej w oparciu o przewidywane ryzyko.
Do tej listy warto dodać jeszcze jedną pozycję, która może być dodatkwym powodem pojawienia się tych wcześniejszych: 70.Błędy są nieskutecznie raportowane. Tester nie sporządził dostatecznie silnej argumentacji, dlaczego dany błąd powinien zostać naprawiony. Skutkiem tego błąd został mylnie oceniony jako nie-błąd, uznano że nie jest dostatecznie ważny aby opóźniać produkt, zbyt ryzykowny do naprawy, albo po prostu nie wart wysiłku.
Tak jak to było z Małym Kurczakiem, bieganie i krzyki, że niebo się wali nie jest zwykle skuteczną metodą komunikowania problemu - o ile oczywiście niebo nie wali się naprawdę. Większość znajdowanych błędów nie będzie aż tak dramatycznych. Trzeba będzie tylko zwięźle i treściwie powiadomić o swoim znalezisku zespół zajmujący się podejmowaniem decyzji w tych sprawach, tak żeby miał do dyspozycji potrzebną do decyzji informację. Ponieważ istnieje wiele różnych modeli wytwarzania oprogramowania i różne typy dynamiki grupowej, nie da się z góry jednoznacznie opisać, jak będzie przebiegać w danym zespole lub projekcie proces podejmowania decyzji, czy błąd ma być naprawiony, czy nie. Często decyzja należy wyłącznie do kierownika projektu, czasem do programisty, czasem podejmuje ją specjalnie dobrany zespół.
Jadnak zawsze jedna lub kilka osób dokonuje przeglądu błędu, którego dotyczy złożony raport, i podejmuje decyzję co dalej. Ta decyzja jest podejmowana przynajmniej częściowo w oparciu o informację dostarczoną przez testera w raporcie błędu.
Nie trzeba być prawnikiem albo byłym przewodniczącym grupy dyskusyjnej, aby domyśleć się, jak należy przekonywać innych, by błąd został naprawiony. Wystarczy w znacznym stopniu zdrowy rozsądek i podstawowe umiejętności komunikacyjne. W dalszej części rozdziału zapoznamy się z różnymi systemami zapisywania i śledzenia raportów o błędach, ale na razie weźmiemy pod uwagę klika ogólnych, podstawowych zasad. 71.Raportować błędy jak najszybciej. Mówiliśmy już o tym wczesniej, ale tych powtórzeń nigdy nie jest zbyt wiele. Im wcześniej znajdzie się błąd, tym więcej czasu pozostaje w harmonogramie na jego naprawę. Wyobraźmy sobie, że zawstydzający błąd ortograficzny zostaje znaleziony w tekście pomocniczym na kilka miesięcy przed wypuszczeniem programu. Jest wówczas bardzo prawdopodobne, że błąd zostanie naprawiony. Ten sam błąd znaleziony kilka godzin przed dostawą, zapewne naprawiony nie będzie. Rysunek 18.1 ilustruje zależność między czasem a naprawą błędów na wykresie.
Początek projektu Czas
Prawdopodobieństwo naprawy
Mniejszy bład
Poważny błąd
Rysunek 18.1  Im poźniej błąd zostanie znaleziony, tym mniejsze prawdopodobieństwo, że zostanie naprawiony, zwłaszcza jeśli chodzi o miej poważne błędy.
Może sie to wydawać dziwne - błąd jest wciąż tym samym błędem niezależnie od tego czy znaleźć go dzisiaj, czy za trzy miesiące. W doskonałym świecie nie miałoby znaczenia, kiedy błąd zostaje znaleziony, tylko co to jest za błąd. Jednak w rzeczywistości ryzyko związane z naprawianiem błędu wzrasta wraz z upływem czasu i ten fakt ma rosnące znaczenia w trakcie podejmownaia decyzji. 72.Opisywać błędy skutecznie. Wyobraźmy sobie, że jest się programistą i otrzymuje od testera następujący raport o błędzie: „Kiedy tylko wstukam masę przypadkowych znaków w okno wlogowujące, oprogramowanie zaczyna wyrabiać dziwne rzeczy.” W jaki sposób można choćby zacząć szukać przyczyny błędu nie wiedząc co to za przypadkowe znaki, jak wielka ilość wywołuje ten efekt, i jakie dziwne rzeczy się zdarzały? Skuteczny opis błędu Dobrze napisany raport o błędzie ma nastęujące cechy: • Jest jak najkrótszy. Opisuje wyłącznie fakty i szczegóły konieczne do zademonstrowania i opisu błędu. Określenie „masa przypadkowych znaków” nie jest jak najkrótsze. Należy podać dokładną sekwencję kroków, które wywołują problem. Jeśli błąd wywołują rozmaite zbiory czynnowści i danych wejściowych, podaje się kilka przykładów, zwłaszcza jeśli zawierają jakąś regularność czy inna wskazówkę, która możę ułatwić programiście lokalizację przyczyny błędu. Pisze się zwięźle i na temat. • Jest pojedynczy. Raport błędu powinien opisywać tylko jeden błąd. To brzymi jak coś oczywistego, ale czasami niełatwo jest odróżnić od siebie kilka błędów o podobnych objawach i w pośpiechu wrzuca się je wszystkie do jednego worka. Kłopot, jaki zwykle wynika z opisywania kilku różnych błędów w jednym raporcie jest taki, że zwykle tylko pierwszy z tych błędów zostaje naprawiony - pozostale są zapomniane lub zignorowane. Poza tym niemożliwe jest śledzenie statusu kilku różnych błędów jeśli opisuje je wspólny raport (więcej o tym piszemy poniżej).
Łatwo powiedzieć, że błędy należy meldować pojedynczo i nie łączyć razem w jednym raporcie, ale w rzeczywistości nie jest to zawsze takie łatwe. Przyjrzyjmy się następującemu raportowi: „Następujące pięć słów ma błędy literowe w pliku pomocy interakcyjnej…” To, oczywiście, trzeba podzielić na pięć osobnych raportów. Ale jak potraktować „Dialog wlogowania nie przyjmuje haseł ani tożsamości użytkownika zawierających duże litery”? Czy to jeden, czy dwa różne błędy? Z punktu widzenia użytkownika wygląda to jak dwa błędy, jeden dotyczący hasła i drugi dotyczący tożsamości użytkownika. Jednak na poziomie kodu może to być tylko jeden błąd, gdzie programista zapomniał uwzględnić duże litery. Zalecenie: kiedy ma się wątpliwości, lepiej rozdzielić błędy na dwa różne raporty niż je łączyć. Tester poszukuje objawów, nie przyczyn błędu. Wiele błędów może mieć wspólną przyczynę, ale nie wie się tego dopóki błąd nie zostanie naprawiony1. Lepiej popełnić błąd stwarzając omyłkowo dwa raporty tam, gdzie wystarczyłby jeden, niż opóźnić albo, co gorsza, spowodować że błąd nie zostanie w ogóle naprawiony z powodu wrzucenia kilku błędów do jednego worka.      • Jest oczywisty i ogólny. Błąd opisany nadmiernie szczegółowo, przy pomocy wielu zawiłych kroków niezbędnych do wywołania jakiegoś jednego specjalnego przypadku błędu nie skłania naprawiania go w tym samym stopniu co błąd opisany w kilku prostych, łatwych do wykonania instrukcjach pokazujących, na ile jest on ogólny i łatwo dostrzegalny przez użytkownika.
1 Raczej dopóki błąd nie zostanie znaleziony, niekoniecznie "naprawiony". Po raz któryś z rzędu wywody byłyby o wiele jeśniejsze, gdyby stosować inne określenie na objawy błędu (np. "awaria") i na jego przyczyny (np. "błąd" lub "usterka"). Przyp. tłumacza.
Raportowanie błędów znalezionych przez narzędzia do automatycznego testowania jest przykładem takiej sytuacji. Automatyczny program mógł działać przez wiele godzin zanim błąd został znaleziony. Kierownik projektu podejmujący decyzję dotyczącą tego, co zrobić z błędem, może się zawahać, czy warto naprawiać błąd, któy wymaga wielogodzinnego walenia w klawiaturę, zanim się ujawni. Jeśli jednak poświęcić chwilę analizie wyników testu, może się okazać, że nie potrzeba wcale wielu godzin - wystarczy kilka powszechnie stosowanych uderzeń w klawisze. Ten proces nazywa się izolowaniem błędu. Automayczny program po prostu przypadkiem trafił na tę sekwencję klawiszy. Jeśli chce się, aby błąd został potraktowany z uwagą, na jaką zasługuje, trzeba w raporcie opisać tych właśnie kilka „magicznych” uderzeń w klawisze, a nie tysiące wykonanych przez automatyczny program zanim dotarł on do miejsca pojawienia się błędu. • Daje się odtworzyć. Aby raport błędu został potraktowany poważnie, opisany błąd musi dać się odtworzyć - wykonanie określonego ciągu czynności spowoduje, że oprogramowanie osiągnie ten sam stan co porzednio i błąd pojawi się ponownie. Jedną z trudniejszych, ale satysfakcjonujących czynności w testowaniu są próby wyizolowania i odtworzenia tych pozornie losowych zachowań oprogramowania - niezrozumiałych zawieszeń się, przypadkowego zniszczenia danych przez program i tak dalej1. W dalszej części rozdziału poznamy kilka sposobów jak to osiągnąć. Kiedy wiadomo już, jak odtworzyć błąd przy pomocy jednoznacznej serii czynności, pora napisać raport meldujący o istnieniu tego błędu2. 73.Opisywać błędy nikogo nie oskarżając. Nietrudno, by między programistami i testerami powstały antagonizmy. Kto zapomniał, dlaczego, niech przeczyta ponownie rozdział 3ci. Programiści i cały zespół wytwarzający system może traktować raporty o błędach jako raporty o całej ich pracy, dlatego raporty błędów należy pisać stylem bezosobowym, dyplomatycznie i powstrzymując się od wydawania osądów. Raport błędów mówiący „Kod twojego sterownika drukarki jest okropny, po prostu nie działa. Nie wierzę, że ośmieliłeś się przekazać go do testowania” jest niestosowny. Raporty błędów powinno się pisać „przeciwko” błędom, a nie osobom3, i ograniczać się do opisu samych faktów. Nie należy się chwalić, nie należy się wywyższać, nie należy oskarżać. Liczą się takt i dyplomacja.
1 Szczególnie trudne staje się to w odniesieniu do programów czasu rzeczywistego - tam potrzebne są specjalne techniki szukania błędów, którcyh wystąpienie może zależeć od skomplikowanego splotu zmiennych czasowych (przyp. tłumacza).
74.Śledzić dalsze losy złożonego raportu. Jest jedna rzecz gorsza niż nie znaleźć błędu: znaleźć błąd, napisać raport, a potem o nim zapomieć lub go zgubić1. Wiemy już że testowaniae oprogramowania to ciężka praca, nie pozwólmy więc by jej owoce - znalezione przez nas błędy - zostały zmarnowane. Od momentu znalezienia błędu na testerze spoczywa odpowiedzialność, by zameldować o jego istnieniu i dopatrzeć, by poświęcono mu konieczną uwagę. Dobry tester znajduje wiele błędów. Wielki tester znajduje wiele błędów i śledzi ich dalsze losy aż do momentu, gdy zostaną naprawione. Nauczymy się więcej na ten temat w dalszej części tego rozdziału.
Te zasady - wczesne raportowanie błędów, skuteczne metody ich opisywania, używanie nieantagonizujących sformułowań, śledzenie dalszych losów raportów - są zgodne z zasadami zdrowego rozsądku. Stosują się do każdgo zadania wymagającego międzyludzkiej komunikacji. Czasami jednak w pośpiechu nietrudno o nich zapomnieć. Jednak dla testera, którey chce skutecznie meldować znalezione błędy i spowodować, by zostały naprawione, stosowanie się do tych zasad jest konieczne. Izolowanie i odtwarzanie błędów
Nauczyliśmy się właśnie, że aby skutecznie złożyć meldunek o znalezionym błędzie, trzeba go opisać przekonywująco, ogólnie i w sposób pozwalający na jego odtworzenie. Wielokrotnie jest to nietrudne. Wyobraźmy sobie, że mamy proste zadanie testowe dla programu graficznego, sprawdzające czy daje się stosować wszystkie kolory. Jeśli za każdym razem, kiedy wybiera się kolor czerwony, program rysuje na zielono, jest to oczywisty, ogólny i odtwarzalny błąd.
2 Autor spycha na testerów znaczną część odpowiedzialności za znalezienie przyczyny, a nie tylko objawów błędu. Oczywiście często nie jest to najlepsze rozwiązania, a jego ceną bywa zwykle utrata kontroli nad harmonogramem testów i to, że w budżet czasowy testowania wpisuje się czynności należące jednoznacznie do wytwarzania (przyp. tłumacza).
3 Osoba będąca pozornie "autorem" danego błędu wcale nie zawsze rzeczywiscie ponosi za niego winę: znacznie częsciej "winny" jest nierealistyczny harmonogram, brak odpowiedniego doświadczenia, brak dobrych specyfikacji i wszelki inny bałagan organizacyjny i procesowy, niż autentyczne niechlujstwo programisty (przyp. tłumacza).
1 Nie pierwszy to raz autor zdaje się byc zdania, że testerzy ponoszą odpowiedzialność za braki organizacyjne i za to, co bezwzględnie powinno należeć do obowiązków kierownika projektu, o ile nie przekaże on tej odpowiedzialności innym (przyp. tłumacza).
Co jednak począć, kiedy taki błąd pojawia się dopiero po wykonaniu kilku innych zadań testowych, ale nie występuje, jeśli to samo zadanie testowe wykonać zaraz ponownym wystartowaniu maszyny? Co począć, kiedy pojawia się losowo albo tylko w czasie pełni księżyca? Trzeba będzie wtedy zabawić się w detektywa.
Izolowanie i odtwarzanie błędów wymaga umiejętności detektywistycznych i prób ograniczenia okoliczności, w których problem występuje. Dobra wiadomość to fakt, ze „losowe” błędy nie istnieją - jeśli odtworzyć dokładnie tę samą sytuację i zastosować dokładnie te same dane wejściowe, błąd na pewno pojawi się ponownie. Kłopot polega na tym, że odtworzenie dokładnie tego samego stanu i zespołu danych wejścia może być bardzo trudne i czasochłonne. Kiedy odpowiedź już się zna, wydaje się oczywista. Zanim się ją znajdzie, zadanie może wydawać się beznadziejne. Niektórzy testerzy zdają się mieć wrodzony talent do izolowania i odtwarzania błędów. Potrafią oni odkryć błąd i potem szybko zidentyfikować dzialania i warunki, w których występuje. Dla innych taka umiejętność pojawia się dopiero wraz z rosnącym doświadczniem, kiedy znaleźli i zameldowali wiele różnych rodzajów błędów1. Każdy, kto chce być dobrym testerem, musi jednak tę umiejętność opanować, tak że warto wykorzystać każdą okazję, by próbować swoich sił w izolowaniu i odtwarzaniu błędów.
Na początek kilka dobrych rad, które przydadzą się, kiedy znajdzie się błąd wymagający bardzo wielu kroków w celu odtworzenia lub nie dający się na pozór odtworzyć w ogóle. Komu się to przytrafi, niech spróbuje wykorzystać na początek wskazówki z poniższej listy: 75.Niczego nie brać za pewnik. Zapisywać wszystko co się robi - każdy krok, każdą przerwę - wszystko. Nietrudno omyłkowo opuścić lub dodać jeden krok. Pomocą może być kolega obserwujący, co robi się w czasie testowania. Można posłużyć się też programem do nagrywania naciśniętych klawiszy oraz ruchów i kliknięć myszką. Jeśli to konieczne, można nawet posłużyć się kamerą wideo do nagrania swoich czynności. Chodzi o to, by każdy krok stał się widoczny i by można go było zanalizować z innej perspektywy.
1 Generalnie, umiejętność szybkiego izolowanie przyczyn błędów wymaga dobrej znajomości szczegółów aplikacji i jej konstrukcji, co powoduje, że skuteczniejsi pod tym względem zawsze powinni byc programiści niż testerzy. Dlatego uparcie twierdzę, że izolownie błędów to zadanie raczej dla programisty niż dla testera! (przyp. tłumacza).
76.Szukajmy sytuacji zależnych od zmiennych czasowych. Czy błąd pojawia się tylko o określonej porze dnia? Być może zależy od tego, jak szybko wprowadza się dane lub od tego, czy dane zapisuje się na wolniejszą dyskietkę zamiast na szybszy dysk twardy. Czy sieć była mocno obciążona kiedy zaobserwowało się błąd? Warto wypróbować to samo zadanie testowe na szybszym i na wolniejszym sprzęcie. Myśleć o aspektach czasowych. 77.Błędy spowodowane takimi „szklanoskrzynkowymi” okolicznościami jak warunki brzegowe, przeciążenie systemu, przecieki pamięci, czy przepełnienie zasobów danych są zwykle trudne do wyizolowania. Może się zdarzyć, że wykona się zadanie testowe powodujące zniszczenie fragmentu danych, ale odkryje się to dopiero znacznie później, kiedy będzie się z tych danych chciało skorzystać. Błędy, które nie występują po ponownym wystartowaniu maszyny, tylko dopiero po jakimś czasie, zwykle zaliczają się do tej katoegorii. Kiedy tak się dzieje, warto uważnie przyjrzeć się wykonywanym wcześniej testom, może posłużyć się dynamicznymi technikami szklanej skrzynki, aby odkryć poprzednio przeoczone uboczne skutki wykonywanych zadań. 78.Błędy zależne od stanu aplikacji pojawiają się tylko wtedy, kiedy oprogramowanie znajduje się w określonym stanie. Przykłady takich błędów to błędy, które występują tylko wtedy, kiedy program wykonywany jest po raz pierwszy albo przeciwnie, tylko wtedy kiedy program wykonywany jest kolejne razy. Może jakiś błąd pojawia się dopiero po wcześniejszym zapiszniu danych lub po uprzednim naciśnięciu jakiegoś klawisza. Takie błędy mogą na pozór wyglądać jak zależne od zmiennych czasowych, ale ważny jest nie czas, lecz kolejność, w jakiej wykonuje się zadania.
79.Warto uwzględnić zależności od zasobów, współdziałanie aplikacji z pamięcią, z siecią oraz wspólne korzystanie z zasobów sprzętowych przez różne aplikacje. Czy błąd występuje tylko na obciążonym systemie, który jednocześnie obsługuje inne programy albo komunikuje się z innymi systemami? Może się okazać, że przyczyną błędu są warunki  wyścigu (kilka procesów lub programów rywalizujących o te same zasoby), przecieki pamięci (pamięć wykorzystywana i zwracana przez program nie w całości wraca do puli pamięci pozostającej do dyspozycji systemu operacyjunego), albo jest to błąd zależny od stanu systemu, pojawijący się tylko w połączeniu z określonymi zasobami. 80.Nie wolno zapominać o sprzęcie. Inaczej niż oprogramowanie, sprzęt może psuć się wraz z upływem czasu i działać w nieoczekiwany sposób. Obluzowana karta, zapsuta kość pamięci albo przegrzany mikroprocesor mogą wywoływac awarie, które na pierwszy rzut oka wyglądaja jak skutki błędów oprogramowania, ale nimi nie są. Warto spróbować wywołać tę sama awarię na innym sprzęcie. To jest szczególnie istotne podczas wykonywania testowania konfiguracji i kompatybilności. Sprawdza się, czy ta sama awaria pojawia się tylko na jednym rodzaju sprzętu czy na wielu.
Jeśli mimo wszelkich wysiłków wciąż nie udaje się wyizolować znalezionego błędu i sporządzić zwięzłej listy kroków niezbędnych dla jego odtworzenia, trzeba mimo to zapisać informację o nim po to, by nie został zapomniany. Może się zdarzyć, że przy pomocy informacji zdobytej przez testera programista będzie w stanie błąd zidentyfikować. Ponieważ programista zna kod, więc opis symptomów, kroków zadania testowego i przede wszystkim tych czynności, które tester wykonal usiłując zidentyfkiować przyczynę awarii, mogą programiście podsunąć wskazówki, gdzie błąd może się ukrywać. Oczywiście programista nie będzie chciał ani nie powinien nawet tego robić w odniesieniu do wszystkich znajdowanych błędów1, ale niektóre szczególnie trudne wymagają pracy zespołowej. Błąd błędowi nierówny
1 Dlaczegóż by nie? Cóż za fantastyczny i nienaturalny pomysł podziału pracy, by zmuszać testerów do wykonywania zadania, w którym programista jest zdecydowanie lepszy, kosztem tego, co testerzy mają robić i w czym są lepsi, to jest testowania?! (przyp. tłumacza)
Każdy zgodzi się pewnie, że błąd niszczący dane użytkownika jest poważniejszy niż zwykły błąd literowy. Cóż jednak będzie wtedy, kiedy zniszczenie danych jest tak rzadkie, że być może żadnemu użytkownikowi nigdy się nie przytrafi, podczas gdy błąd lityerowy powoduje, że każdy użytkownik ma trudności z zainstalowaniem oprogramowania? Który błąd jest wtedy ważniejszy i powinien być naprawiony przede wszystkim? Decyzja staje się trudniejsza.
Gdyby projekt miał do dyspozycji nieskończoną ilość czasu, naprawionoby oba błędy, ale tak sie nigdy nie zdarza. Jak dowiedzieliśmy się wcześniej, w każdym projekcie informatycznym trzeba wyważać jedne błędy wobec drugich i podejmować ryzykowne decyzje. Ryzyko zawarte jest w decyzji, które błędy naprawić przede wszystkim, a które można pominąć lub zaplanować do naprawy dopiero w późniejszej wersji programu.
Składając raporty o błędach, tester często ma możliwość podania propozycji, co ma z nimi zostać zrobione. Tester klasyfikuje błędy i w zwięzły sposób opisuje ich znaczenie i skutki. Powszechnie stopsowaną metodą jest przypisanie błędowi wagi oraz priorytetu. Szczegóły tego procesu są różne w różnych przedsiębiorstwach, ale istota rzeczy pozostaje ta sama: 81.Waga oznacza jak poważny jest błąd i jakie są jego skutki dla produktu i dla użytkownika. 82.Priorytet oznacza jak ważne jest naprawienie błędu i kiedy należy go naprawić.
Podana poniżej lista często stosowanych kryteriów klasyfikacji wagi i priorytetu powinna ułatwić zrozumienie różnicy między nimi. Pamiętajmy, to są tylko przykłady. Niektóre firmy stosuja nawet dziesięć różnych poziomów, inne zadowalają się trzema. Bez wzglądu na ilość poziomów, cel jest ten sam.
Waga 1.Katastrofa systemu, utrata danych, zniszczenie danych 2.Błąd w działaniu, nieprawidłowy wynik, utrata funkcjonalności 3.Pomniejszy problem, błąd literowy, forma interfejsu użytkownika, rzadki wypadek 4.Propozycja
Priorytet
1.Natychmiastowa naprawa, uniemożliwia dalsze testowanie, bardzo widoczny 2.Musi być naprawiony przed wypuszczeniem produktu 3.Powinien zostać naprawiony w miarę możliwości 4.Można naprawić, ale można też wypuścić bez zmiany
Błąd polegający na rzadko występującym zniszczeniu danych można zaklasyfikować jako Waga 1, Priorytet 3. Błąd literowy w instrukcji instalacji systemu, powodujący że użytkownik zadzwoni po pomoc, można zaklasyfikować jako Waga 3, Priorytet 2.
Co powiedzieć o wersji programu, który „pada” natychmiast po wystartowaniu? Przypuszczalnie Waga 1, Priorytet 1. Pogląd, że przycisk należy przesunąć odrobinę na dół strony można chyba zaklasyfikować jako Waga 4, Priorytet 4.
Ta informacja jest kluczowa dla osoby lub zespołu dokonującego przeglądu raportu błędu1 i podejmującego decyzje, jakie błędy naprawiać i w jakiej kolejności. Programista, któremu przypisano 25 błędów do naprawy, powinien przypuszczalnie zacząć od błędów mających priorytet 1, zamiast najpierw odwalić najłatwiejsze. Podobnie, dwóch kierowników projektów - jednego zajmującego się grą komputerową, a drugiego - oprogramowaniem monitora pracy serca - mogliby otrzymać podobną informację i na jej podstawie podjąć diametralnie odmienne decyzje. Jeden z nich zapewne postawi na to, by aplikacja wyglądała jak najlepiej i działała jak najszybciej, zaś drugi przypuszczalnie wybierze w pierwszym rzędzie niezawodność. Informacja o wadze i priorytecie błędów jest podstawą do decyzji. Kawałek dalej w tym rozdziale zobaczymy, jak pola do wprowadzanie tej informacji używane są w rzeczywistym systemie do rejestracji i śledzenie błędów. Priorytety błędów mogą się zmieniać w trakcie trwania projektu. Błąd z początku zarejestrowany jako Priorytet 2 może zmienic się na Priorytet 4 kiedy czas ucieka i data wypuszczenia pierwszej wersji wisi nad głową. Tester który znalazł błąd powinien nieustannie kontrolować status danego błędu by upewnić się czy jest to nadal zgodne z jego zdaniem i móc dostarczać nowych danych na poparcie tego, by został naprawiony2. Cykl życiowy błędu
1 I zwykle taki zespół o wiele bardziej od pojednycznego testera powołany jest do nadawania raportom wagi i priorytetu - w takim zespola powinny znajdować się osoby z marketingu, osoby zajmujące się konstruowaiem wymagań itp (przyp. tłumacza).
2 A kontrolą polityki personalnej firmy oraz planowanej emisji nowych akcji nie powinien tester czasem też się zająć? W końcu i do tego są wyznaczone osoby, które mogą - jak w tym przykładzie kierwonictwo projektu gdzie bez nieustannej kontroli i interwencji testerów system do śledzenie raportów błędów nie działa - popeniać błędy… (sarkastyczny przypisek tłumacza).
W entomologii (badającej prawdziwe, żywe owady) określenie cykl życiowy odnosi się do to różnych etapów życia owada. Z lekcji biologii ze szkoły średniej przypominamy sobie, że stadia większości owadów to jajko, larwa, poczwarka i dorosły owad. Dlatego wydaje się na miejscu, wziąwszy pod uwagę że błędy oprogramowania nazywamy także „pluskwami”, że podobny system stadiów życiowych zastosuje się, by wyróżnić poszczególne fazy życia błędów. Fazy życiowe komputerowej „pluskwy” nie są dokładnie takie same jak prawdziwego owada, ale koncepcja jest analogiczna. Rysunek 18.2 pokazuje przykład najprostszego i optymalnego cyklu życiowego błędu oprogramowania.
Otwarty
Rozwiązany
Zamknięty
Tester znajduje i rejestruje błąd
Błąd przydzielony programiście
Programista naprawia błąd
Błąd przydzielony testerowi
Tester potwierdza że błąd został naprawiony
Tester zamyka błąd
Błąd znaleziony
Rysunek 18.2  Diagram stanów pokazuje, że komputerowa „pluskwa” ma cykl życiowy podobny do prawdziwego owada.
Na tym przykładzie widać, że kiedy błąd zostaje po raz pierwszy znaleziony przez testera, zostaje zarejestrowany i przypisany programiście do naprawy. Ten stan nazywa się stanem otwartym. Kiedy programista poprawi już kod, przypisuje go na powrót testerowi i błąd wchodzi w stan rozwiązany. Tester przeprowadza wtedy test regresywny aby potwierdzić, że błąd rzeczywiście został naprawiony i - jeśli tak jest - zamyka błąd. Błąd wchodzi wtedy w swą ostatnią fazę, w stan zamknięty.
Często cykl życiowy błędu nie jest bardziej skomplikowany: błąd zostaje otwarty, rozwiązany i zamknięty1. W pewnych sytaucjach jednak cykl życiowy nieco się komplikuje, jak widać na rysunku 18.3.
1 Zręczniej byłoby mówić o różnych stanach raportu o błędzie, nie o stanach błędu, ale taką nietypową terminologię stosuje autor (przyp. tłumacza).
W tym wypadku cykl zaczyna się tak samo jak poprzednio od tego, że tester otwiera błąd i przypisuje go programiście, ale programista nie naprawia błędu. Zdaniem programisty błąd nie jest dostatecznie istotny by umotywować naprawę, więc programista odwołuje się do kierownika projektu. Kierownik projektu zgadza się ze zdaniem programisty i umieszcza błąd w stanie „rozwiązany, nie będzie naprawiony”. Tester nie zgadza się z tą decyzją, znajduje bardziej ogólny i jednoznaczny przykład błędu, otwiera go ponownie i przypisuje kierownikowi porjektu. Kierownik projektu w oparciu o nową informację przyznaje rację testerowi i ponownie przypisuje błąd programiście do naprawienia. Programista naprawia błąd i rozwiązując go, przypisuje go testerowi, który potwierdza zniknięcie symptomów i zamyka raport błedu.
Otwarty
Otwarty
Rozwiązany (nie naprawiony)
Tester znajduje i rejestruje błąd
Błąd przydzielony programiście
Programista ocenia błąd jako zbyt drobny by go naprawiać Błąd przydzielony kierownikowi projektu
Kierownik projektu ocenia błąd jako nie wymagający naprawy
Błąd przypisany testerowi
Błąd znaleziony
Otwarty
Tester znajduje ogólniejszy przypadek awarii
Błąd przypisany kierownikowi projektu
Otwarty
Kierownik projektu akceptuje konieczność naprawy
Błąd przypisany programiście
Rozwiązany (naprawiony)
Zamknięty (jako naprawiony)
Programista naprawia błąd Błąd przypisany testerowi
Tester potwierdza, że błąd jest naprawiony
Tester zamyka błąd
Rysunek 18.3  Cykl życiowy błędu staje się niekiedy bardzo skomplikowany, jeśli proces naprawiania błędu nie przebiega tak gładko jak się oczekiwało.
Widzimy, że błąd może podlegać wielu zmianom i powracać do poprzednich stanów w czasie swego życia, czasem skacząc do punktu startowego i zaczynając cykl życiowy od początku. Rysunek 18.4 dodaje do prostego modelu z rysunku 18.2 możliwe decyzje, zatwierdzenia i powroty, które zdarzają się w większości projektów. Oczywiście, każde przedsiębiorstwo i projekt może mieć własny system, ale ten rysunek jest na tyle ogólny że powinien z grubsza pasować do większości ze spotykanych cykli życiowych błędów.
Ten ogólny cykl życiowy ma dwa dodatkowe stany i kilka dodatkowych linii łączących. Stan przeglądu ma miejsce wtedy, gdy kierownik projektu lub komitet, czasem nazywany Komisją Kontroli Zmian (Change Control Board, CCB), podejmuje decyzję czy błąd należy naprawić. W niektórcyh projektach wszystkie błędy przechodzą przez tę komisję zanim przypisane zostają programiście do naprawy. W innych projektach zdarza się to tylko pod koniec projektu albo wcale. Zwróćmy uwagę, że od stanu przeglądu jest strzałka prowadząca bezpośrednio do stanu zamkniętego. Korzysta się z niej, kiedy przegląd decyduje, że błędu nie trzeba naprawiać - jest zbyt drobny, nie jest w rzeczywistości błędem, albo wynika z błędu testowania. Dodany został stan odroczony. Przegląd może zadecydować, że błąd należy naprawić kiedyś w przyszłości, ale nie w obecnej wersji programu.
Otwarty
Rozwiązany
Zamknięty
Błąd znaleziony
Odroczony
Przegląd
Rysunek 18.4  Ten ogólny diagram stanów cyklu życiowego błędu pasuje do większości zdarzających się naprawdę sytuacji.
Dodatkowe połączenie od stanu rozwiązanego do otwartego dotyczy sytuacji, kiedy tester odkrywa, że błąd nie został naprawiony. Błąd otwiera się ponownie i cykl życiowy zaczyna się od początku. Dwie przerywane linie od stanu zamkniętego i odroczonego z powrotem do stanu otwartego wykorzystywane są rzadko, ale są na tyle ważne, że trzeba o nich wspomnieć. Ponieważ tester nigdy nie rezygnuje, może się zdarzyć, że błąd na pozór naprawiony, przetestowany i zamknięty pojawia się ponownie. Takie błędy nazywa się niekiedy regresjami. Zdarza się też, że błąd oproczony okazuje się potem na tyle poważny, że wymaga jednak natychmiastowej naprawy. Jeśli któraś z tych sytuacji ma miejsce, błąd zostaje ponownie otwarty i cały proces zaczyna się od początku.
Większość zespołów projektowych stosuje reguły dotyczące tego, kto ma prawo zmienić stan błędu lub przypisać błąd komuś innemu. Na przykład, być może tylko kierownik projektu ma prawo podjąć decyzję o odroczeniu błędu, lub tylko tester ma prawo zamknąć błąd. Ważne jest, żeby raz zanotowawszy istnienie błędu, śledzić jego drogę przez cykl życiowy, nie zgubić go i dostarczać informacji koniecznej do tego, by błąd został naprawiony i zamknięty. Systemy śledzenia błędów
W tej chwili powionno już być jasne, że proces raportowania błędów jest skomplikowanym stworem, wymagającym dużo informacji, sporo szczegółów i wiele dyscypliny, aby działać. Wszystko czegośmy się w tym rozdziale nauczyli brzmi dobrze, ale aby móc zastosować to w praktyce potrzebny jest system, który umożliwia rejestrowanie znalezionych błędów i śledzenie ich przez cały cykl życiowy. Takie są włąśnie zadania systemu śledzenia błędów.
Pozostała część rozdziału poświęcona jest opisowi podstaw takiego systemu. Podane będą przykłady systemów opartych na papierowych notatkach i systemów opartych o bazę danych. System, który będzie się stosować w rzeczywistości zależy oczywiście od przedsiębiorstwa lub od projektu, ale z drugiej strony, podstawowe zasady są dość podobne i spójne w całym przemyśle oprogramowania, tak więc ten opis powinien pozwolić poradzić sobie z każdym systemem, kórego przyjdzie nam używać.
Standard: raport incydentu
Nasz dobry przyjaciel, Standard Dokumentacji dla Testu Oprogramowania ANSI/IEEE 829 (można go znaleźć na standards.iee.org), definiuje dokument zwany Raportem Incydentu Testowego (Test Incident Report), którego zadaniem jest „udokumentować każde zdarzenie, które zachodzi w trakcie testowania i wymaga dalszego badania”. Mówiąc krótko, zarejestrować błąd1.
Przegląd standardu jest dobrym sposobem, by zebrać wszystko czegośmy się dotąd nauczyli o procesie raportowania i śledzenia błędów. Poniższa lista zawiera - nieco zmodyfikowany pod względem terminologii - zakres tego stadardu. 83.Identyfikator. Określa unikalny numer czy nazwę błędu, której używa się do poszukiwania błędu lub w odnośnikach do niego. 84.Streszczenie. Krótkie streszczenie istoty błędu. Zawiera też referencje do wersji testowanego oprogramowania, stosowanej procedury testowej, numeru zadania testowego i specyfikacji testu. 85.Opis wydarzenia. Jest to szczegółowy opis błędu, zawierający następującą informację: − Data i godzina − Imię i nazwisko testera − Użyta konfiguracja oprogramowania i sprzętu − Dane wejściowe − Kroki procedury testowej − Oczekiwane wyniki − Uzyskane wyniki − Usiłowania odtworzenia błędu wraz z opisem, co wypróbowano − Inne informacje i obserwacje, które mogą ułatwić programiście lokalizację błędu. 86.Skutki. Waga, priorytet oraz oszacowanie skutków błędu dla planu testowania, specyfikacji, procedur i zadań testowych.
1 Ściślej, zarejestować podejrzenie istnienia błędu. W najlepszym razie ma się do czynienia z oczywistą awarią, której dokładną przyczynę ujawni jednak dopiero dalsze poszukiwanie błędu. Często jednak raport dotyczy jakiegoś "podejrzanego" wydarzenia, gdzie analizy wymaga, czy była to w ogóle awaria, czy np. kłopoty ze środowiskiem testowym albo omyłka testera!
Ręczne raportowanie i śledzenie błędów
Standard 829 nie definiuje formatu raportu błędu, ale podaje przykład prostego dokumentu. Rysunek 18.5 pokazuje, jak taki papierowy raport błędu może wyglądać.
Nazwa projektu Raport Błędu Błąd nr: Oprogramowanie: Produkt: Wersja:
Tester: Data: Przypisany komu:
Waga: 1 2 3 4 Priorytet: 1 2 3 4 Odtwarzalność: TAK NIE Tytuł: Opis: Decyzja: NAPRAWIONY - DUPLIKAT - NIEODTWARZALNY - NIE DA SIĘ NAPRAWIĆ - ODROCZONY - NIE NAPRAWIAĆ Data rozwiązania: Rozwiązany przez: Wersja:
Komentarz na temat rozwiązania: Ponownie przetestowany przez: Przetestowana wersja: Data testu:
Komentarz na temat testu:
Podpisy: Autor: Tester: Programista: Kierownik projektu:
Marketing: Obsługa produktu: Rysunek 18.5  Przykładowy formularz raportu błędu pokazujący, jak wszystkie potrzebne dane można zmieścić na pojedynczej stronie.
Zwróćmy uwagę, że ten jednostronicowy formularz ma mijesce na wszelką informację potrzebną, by zidentyfikować i opisać błąd. Zawiera też pola, które wykorzystuje się, by móc śledzic błąd w trakcie jego całego cyklu życiowego. Kiedy formularz zostanie wypełniony przez testera, można go przypisać programiście do naprawy. Programista ma do dyspozycji pola, gdzie może wprowadzać dane na temat naprawy, w tym propozycje decyzji dotyczących błędu. Sa też pola, gdzie tester - po naprawieniu błędu - wprowadza informację na temat wyników ponowengo testu i może zamknąć błąd. Na dole formularza znajduje się miejsce na podpisy - wiele przedsiębiorstw stosuje zasadę, że podpisem poświadcza się akceptację tego, jak błąd został rozwiązany1.
W bardzo małych projektach papierowe formularze mogą być zupełnie wystarczające. Jeszcze we wczesnych latach 90-ych zdarzały się wielkie, krytyczne dla firmy projekty z tysiącami zarejestrowanych błędów, które stosowały papierowe formularze w celu raportowania i śledzenia błędów. Resztki tych metod trwają miejscami pewnie do dziś.
Kłopot z papierowymi formularzami jest taki, że są one… papierowe, a każdy kto kiedykolwiek usiłował coś znaleźć w jakimkolwiek systemie opartym na papierowej dokumentacji wie dobrze, jakie to bywa nieskuteczne. Wyobraźmy sobie tylko zawiłości możliwych cykli żcyiowych raportu błędu (przykład mieliśmy na rysunku 18.3), a zwątpimy, czy papierowy system jest w stanie za nimi nadążyć. Co będzie, jeśli ktoś zapragnie poznać status raportu numer 6329 albo zechce się dowiedzieć, jak wiele jest jeszcze otwartych raportów o priorytecie 1? Dzięki Bogu za arkusze kalkulacyjne i bazy danych.
Automatyczne raportowanie i śledzenie błędów
Tak samo jak z opisami zadań i procedur testowych, którymi zajmowaliśmy sie w rozdziale 17, nie ma powodu, by nie ówspółcześnić standardu ANSI/IEEE 829 i nie zaadaptować go do pracy w nowoczesnych systemach. W końcu informacja potrzebna do śledzenia błędów, taka jak dane na formularzu z rysunku 18.5, to tylko tekst i liczby - idealne zastosowaneie dla bazy danych. Rysunek 18.6 pokazuje taki automatyczny system do reportowania i śledzenia błędów, jaki można często dziś spotkać w pracy testera.
1 Bardzo anglosaskie podejście - "podchody" mające na celu skłonić np. kierownika testów, żeby wreszcie podpisał raport marnie naprawionego błędu i w ten sposób umożliwił wypuszczenie programu bywają tam przedmiotem wielu anekdot. Taki formalizm ma swoje zalety, ma też liczne wady (przyp. tłumacza).
Rysunek 18.6 pokazuje najwyższy poziom bazy danych zawierającej 3263 błędy. Poszczgólne błędy, ich identyfikatory, tytuły, status, priorytet, waga i podjęte decyzje pokazuje lista w górnej części ekranu. Dalsza informacja na temat wybranego błędu widoczna jest w dolnej części ekranu. Od razu widzi się, kto otworzył dany błąd, kto go rozwiązał i kto go zamknął. Można też przewijać wszystkie szczególy wprowadzone do raportu w ciągu cyklu życiowego błędu.
Zwróćmy uwagę na pasek z przyciskami na górze ekranu, przy pomocy których można stworzyć (otworzyć) nowy raport, jak również edytować, rozwiązać, zamknąć lub reaktywować (ponownie otworzyć) już istniejący raport. Na kolejnych stronach zobaczymy, jakie okna pojawiają się po wybraniu poszczególnych opcji.
Lisiting błędów
Skrócona informacja na temat cyklu życiowego wybranego błędu
Szczegółowe dane na temat błędu
Rysunek 18.6  Okno główne typowej aplikacji bazodanowej do raportowania błędów zawiera próbkę możliwości oferowanych przez taki system (ilustracje przedstawiają bazę danych Mantis, za zgodą Dave Ball’a i HBS International, Inc.).
Rysunek 18.7 przedstawia okno dialogowe Nowy Błąd, do którego wprowadza się dane na temat nowego błędu do zarejestrowania w systemie. Ogólny opis błędu zawiera tytuł, wagę, priorytet, dane na temat wersji oprogramowania itd. Jako komentarz wprowadza się opis tego, w jaki sposób doszło do wykrycia błędu. Ta aplikacja zawiera już gotowe nagłówki, służące jako pomoc do wypełnienia potrzebnej informacji. Wprowadzając opis nowgo błędu, trzeba tylko wypełnić wszystko po kolei - cel testu, przygotowanie zadania, kroki potrzebne do wywołania błędu, oczekiwane wyniki, otrzymane wyniki, konfigurację sprzętu i oprogramowania, której sie używało kiedy wystąpił błąd.

Szczegółowy opis danych wejściowych i kroków procedurey testowej
Rysunek 18.7 Nowy błąd zaczyna swój cykl życiowy w oknie dialogowym Nowy Błąd.
Kiedy błąd został już wprowadzony, a właściwie kiedykolwiek w trakcie jego cyklu życiowego, może okazać sie potrzebna nowa informacja uzupełniająca opis, zmiany priorytetu lub wagi, i wszelkie inne drobne zmiany danych dotyczących błędu. Rysunak 18.8 przedstawia okno, które t umożliwia.
Zwróćmy uwagę, że to okno dialogowe zawiera dodatkowe pola prócz pól dostępnych już przy wprowadzaniu nowgo błędu. W trakcie edycji opisu błędu można na przykład wprowadzić odnośnik do innego błędu, jeśli wydają się podobne lub w inny sposób spokrewnione. Programista może dodać informację na temat tego, na jakim etapie znajduje się praca nad naprawą błędu i ile czasu jeszcze na to potrzeba. Jest tam nawet pole umożliwiające „zwieszenie” błędu, jakby zamrożenie błędu na obecnym etapie jego cyklu życiowego.
Ważną funkcja pokazaną na rysunku 18.8 jest pole Komentarze. Za każdym razem kiedy modyfikuje się opis błędu, kiedy się go otwiera, zmienia, rozwiązuje i zamyka, infomracja ta zostaje zarejestrowana w polu Komnetarze. Na pierwszy rzut oka widać, jakie fazy błąd przeszedł już w swoim cyklu życiowym.
Informacja do śledzenia zmian cyklu życiowego Informacja do śledzenia zmian cyklu życiowego
Dodatkowe pola dostępne przay modyfikacji
Rysunek 18.8 Okno Edycja pozwala dodawać nowe informacje do istniejącego raportu błędu .
Rysunek 18.9 pokazuje okno stosowane wóczas gdy ktoś, zwykle programista lub kierownik projektu, rozwiązuje bład. Rozwijana lista zawiera różne możliwe rozwiązania, począwszy od Naprawiony, poprzez Nie daje się naprawić aż do Duplikat. Jeśli błąd został naprawiony, wprowadza się numer wersji programu zawierającej potrzebne zmiany, a informację na temat tego, co i jak zostało zmienione, wprowadza się do pola przeznaczonego na komentarze. Błąd zostaje następnie przypisany testerowi do ponownego przetestowania i zamknięcia.
Wiele baz danych dla raportów błędów zawiera nie tylko komnetarz dotyczący zmian, ale pełne szczegóły przeprowadzonych zmian: linię kodu, nazwę modułu, a nawet rodzaj błędu, jako że może to być istotną informacją dla testera stosującego metody szkalnej skrzynki.
Kiedy błąd został rozwiązany, zwykle przypisuje się go ponownie testerowi, aby go zamknął. Rysunek 18.10 pokazuje okno dialogowe Zamykanie. Ponieważ w bazie danych zapisano wszelkie zmiany w raporcie od momentu jego otwarcia, widzi się wszystkie decyzje podjęte po drodze i dokładny opis sposobu naprawienia błędu. Może się zdarzyć, że błąd został naprawiony inaczej niż tester się spodziewał, może inny, podobny błąd został znaleziony przez innego testera, albo programista dodał komentarz, że dany sposób naprawy jest ryzykowny. Wszelka informacja może przydać się testerowi, gdy będzie testował ponownie, aby się upewnić, czy rzeczywiście błąd został naprawiony. Jeśli błąd nie został naprawiony, po prosu otwiera się go ponownie i cykl życiowy zaczyna się od początku.
Rysunek 18.9  Okno dialogowe Rozwiązanie używane jest zwykle przez programistę, zapisującego dane na temat sposobu naprawienia blędu.
Rysunek 18.10  Raport błędu gotowy do zamknięcia zawiera do wglądu całą swoją historię.
Kiedy raz się zacznie stosować bazę danych do śledzenia błędów, człowiek dziwi się, jak można to było kiedykolwiek robić na papierze. Baza danych do śledzenia raportów o błędach staje się głównym ośrodkiem, używanym nie tylko przez testerów, do komunikowania statusu projektu, przypisywania uczestnikom projektu zadań do wykonania i - co najważniejsze - upewnienia się, że  żadne błędy nie zostaną zapomniane czy pominięte. Jest to stosowne zamknięcie tego wszystkiego, czego nauczyliśmy się w tym rozdziale na temat raportowania znalezionych błędów. Podsumowanie
Rozdział zaczął się od dziecinej historyjki o Kurczaku, który przestraszył się ogromnie, gdy żołądź spadł mu na głowę. Kurczak pomyślał, że znalazł poważny problem - błąd wagi 1, priorytetu 1 - i natychmiast zaczął biegać i krzyczeć, że wali się cały świat.
Testerowi tez może się coś takiego łatwo przydarzyć, gdy znajdzie w programie coś, co nie działa tak jak powinno. Nauczyliśmy się w tym rozdziale, że powinien istnieć formalny proces, wedle którego należy pracować aby porządnie wyizolować, zaklasyfikować, zarejestrować i śledzić dlasze losy znalezionych błędów tak, by mieć pewność, że zostaną w końcu rozwiązane i - miejmy nadzieję - naprawione.
Mały Kurczak nigdy nie czytał rozdziału 18-ego, więc nie przyszło mu do głowy nic innego niż opowiadać wszystkim spotkanym, co mu się zdarzyło. Oczywiście, to nie był dobry pomysł. Świat się nie walił. Gdyby Kurczak choć na chwilę zatrzymał się i spróbował wyizolować i odtworzyć problem, okazałoby się szybko, że to w ogóle nie był żadnen problem - że spadanie żołędzi z drzewa było zgodne z zamiarem konstruktora. Tymczasem panika i naiwność w końcu zgubiły Kurczaka. Dla tych, co nie znają tej historii: Kurczak i jego przyjaciele w końcu spotkali głodnego lisa, który zaprosił ich do swej nory, aby posłuchać całej historii.
Wypływa z tego taki morał, że dobry tester musi nie tylko umieć zaplanować swoje testy i znajdować błędy, ale także umieć metodycznie i systematycznie raportować ich istnienie. Przesadny, źle opisany albo wręcz nieprawdziwy błąd nie jest w ogóle błędem - i na pewno nie zostanie naprawiony. Pytania
Pytania mają na celu ułatwienie zrozumienia. W aneksie A „Odpowiedzi na pytania” znajdują się prawidłowe rozwiązania – ale nie należy ściągać! 1.Podaj kilka powodów, dla których błąd może nie zostać naprawiony. 2.Jakie są podstawowe zasady pisania raportów o błędach tak, aby zmaksymalizować szansę, że zostaną naprawione? 3.Podaj kilka technik izolowania i odtwarzania błędu. 4.Wyobraźmy sobie, że testując Kalkulator Windows otrzymujemy następujące wyniki: 1+1=2, 2+2=5, 3+3=6, 4+4+9, 5+5=10 i 6+6=13. Napisz stosowny tytuł raportu i opis błędu. 5.Jaką wagę i priorytet nadałbyś błędowi literowemu w nazwie firmy na pierwszym ekranie aplikacji? 6.Jakie są trzy podstawowe fazy cyklu życiowego błędu i dwa często stosowane stany dodatkowe? 7.Podaj kilka powodów, dla których system śledzenia błędów z użyciem bazy danych jest znacznie bardziej użyteczny niż system oparty na papierowych raportach.