Rozdział 19

Rozdział 19  Pomiar sukcesu
W TYM ROZDZIALE Wykorzystanie danych ze statystyki raportów błędów Pomiary stosowane w testowaniu Typowe pomiary stosowane w projekcie
W rozdziale 18-ym poznaliśmy podstawowe zasady rejestracji i śledzenia błędów oraz jak posłużyć się specjalną bazę danych w celu gromadzenia raportów o błędach. Chociaż najczęściej pracuje się z tą bazą danych podczas wprowadzania do niej lub modyfikowania już zarejestrowanych błędów, dodatkowym, pośrednim zyskiem z jej istnienia jest możność wydobywania z niej interesujących danych, które wskazują na sukces (albo niepowodzenie) testowania oraz na ogólny postęp w projekcie.
Korzystając ze zgromadzonych w bazie danych informacji, można dokonywać poszukiwań, których wyniki pokażą na przykład jakie typy błędów rejestrowane sa najczęściej, jak szybko rozwiązuje się znalezione błędy, jaki procent znalezionych dotąd błędów zostało naprawionych itp. Kierownik testowania lub kierownik projektu mogą na podstawie takiej statystyki zidentyfikować trendy, które wskażą na przykład czy jakaś część oprogramowania wydaje się potrzebować jeszcze dużo więcej testowania, albo czy projekt wydaje się nadążać za harmonogramem. Dane są dostępne, jedynie potrzeba sporządzić na ich podstawie odpowiednie raporty, które wydobędą poszukiwane trendy na światło dzienne.
W tym rozdziale zapoznamy się z typowymi formami pytań oraz raportów, z którymi tester prawdopodobnie wcześniej lub później będzie musiał się spotkać, oraz sposoby ich zastosowania w projektach informatycznych. Najważniejsze punkty w tym rozdziale to: 87.Jak korzystać z pomiarów i danych statystycznych 88.Czemu trzeba zachować ostrożność podczas zbierania danych i konstruowania raportów na ich podstawie 89.Jak formułować proste pytania w bazach danych i jak budować z nich raporty 90.Często stosowane pomiary w projektach Wykorzystanie danych ze statystyki raportów błędów
Zastanówmy się nad następującymi pytaniami: 91.Jakie części testowanego oprogramowania mają najwięcej błędów? Jakie najmniej?
92.Ile rozwiązanych błędów jest obecnie przypisanych Marcie? 93.Robert wkrótce wyjedzie na urlop. Czy zdąży przedtem naprawić wszystkie przypisane mu błędy? 94.Ile błędów znaleziono w tym tygodniu? W tym miesiącu? W czasie całego projektu? 95.Na najbliższe posiedzenie grupy sterującej projektu potrzebna jest lista wszystkich otwartych błędów o priorytecie 1 96.Czy wydaje się, że jest szansa dotrzymać zaplanowaną datę wypuszczenia oprogramowania?
Tego rodzaju pytania zadawane są nieustannie w trakcie trwania projektu informatycznego. Nie jest to żadna ścisła matematyka, lecz proste pytania, na które zarówno zespół testowy jak i cały zespół projektowy musi znać odpowiedź.
Może się to komuś wydawać dziwnym, że baza danych służąca do rejestracji i śledzenia raportów błędów może stać się takim podstawowym narzędziem do pomiaru statusu projektu i do znajdowania odpowiedzi na tak zasadnicze pytania. Kto jeszcze się tego nie nauczył, mógłby oczekiwać, że tę rolę powinien raczej spełniać plan projektu, główny harmonogram albo jakiś inny dokument pod kontrolą kierownika projektu. Jednak w rzeczywistości te dokumenty odzwierciedlają bardziej zamiary niż stan faktyczny, podczas gdy baza danych oddaje to, co dzieje się w rzeczywistości. Chcąc wybrać dobrą restaurację, można to zrobić na podstawie życiorysu głównego kucharza lub historii właściciela restauracji. Jednak chcąc miec pewność, że wybór będzie trafny, oprzemy się raczej na opinii aktualnego działu w prasie codziennej lub na danych z inspekcji sanitarnych restauracji. W ten sam sposób działa baza danych projektu. Jej zawartość mówi nam co działo się w przeszłości, co dzieje się obecnie oraz pozwala nam analizować dane by dokonać dobrze podbudowanej próby przewidywania przyszłości. Pomiary określonych atrybutów projektu informatycznego określa się terminem pomiary oprogramowania. Średnia ilość błędów znalezionych dziennie przez testera jest takim pomiarem. Stosunek ilości błędów o wadze 1 do ilości błędów o wadze 4 jest innym pomiarem.
Ponieważ baza danych zawierająca raporty o błędach jest codziennie uzupełniana nowymi błędami, datami planowanych napraw, nazwiskami członków projektu, przypisywaniem błędów różnym osobom itd., jest ona oczywistym miejscem, skąd można pobierać pomiary opisujące status projektu - oraz status poszczególnmych testerów i programistów.
Tutaj kryje się również potencjalne niebezpieczeństwo korzystania z bazy danych dla uzyskiwania pomiarów. Ta sama baza danych, z której każdy może się dowiedzieć, ile jeszcze pozostało do naprawienia błędów o priorytecie 1-ym, pozwoli też kierownictwu dowiedzieć się, ile błędów zostało spowodowanych przez określonego programistę. Szef testera może także sprawdzić, ile dany tester sporządził raportów błędów w porównaniu z innymi testerami. Czy to dobrze? Być może, pod warunkiem że zarówno tester jak i programiosta są naprawdę dobrzy. Co będzie jednak, jeśli jeden tester będzie testował kod wyprodukowany przez naprawdę dobrego programistę? Będzie to oznaczać mniej błędów do znalezienia i statystyka ilości sporządzonych przez danego testera raportów błędów będzie się prezetować słabiutko w porónaniu z wynikami uzyskanymi przez jego kolegów, testujących kod naprawdę nafaszerowany błędami.
Nie jest celem tego rozdziału wdawać się w rozważania dotyczące moralnych i interpersonalnych aspektów, które mogą się pojawić wobec sposobów zastosowania statystyki wygenerowanej z bazy danych. Generalna zasada powinna być taka, że celem korzystania z danych ma być uzyskanie pomiarów dotyczących projektu, a nie osiągnięć poszczególnych osób. Stosowanie pomiarów do ocen indywidualnych może być wzięte pod uwagę pod warunkiem, że pomiary są dostępne do wglądu tylko dla upoważnionych osób, są zrozumiałe i jednoznaczne - czy wyniki ujawniają dobrego programistę czy kiepskiego testera? Pracując w projekcie używającym bazy danych do rejestrowania i śledzenia błędów, należy - by uniknąć poźniejszych niespodzianek - z góry przedyskutować ze swoim szefem oraz z kierownikiem projektu, w jaki sposób dane te będą wykorzystywane.
Pomijając politykę, zastosowanie bazy danych jako źródła pomiarów jest nadzyczajnie skuteczną metodą oceny stanu projektu i swojej własnej pracy. Wszelka potrzebna informacja już tam jest, chodzi jedynie o to, by ją wydobyć i zaprezentować w odpowiedni sposób. W pozostałej części tego rozdziału będzie mowa o tym, jak generować i interpretować pewne powszechnie stosowane pomiary do oceny projektów informatycznych. Oczywiście, projekty bywają rozmaite, więc trzeba pamiętać, że różne będą także adekwatne typy pomiarów. Kiedy się właśnie zobaczyło najbardziej dziwaczny diagram kołowy pod słońcem, ktoś w tejże chwili wymyśli inny, pozwalający na nowy, skuteczny sposób uzyskania wglądu w dane dotyczące projektu. Pomiary stosowane w testowaniu
Chyba najczęściej - oprócz rejestrowania i modyfikowania raportów błędów - używaną funkcją bazy danych do śledzenia błędów jest wykonywanie pytań, aby uzyskać listy błędów dobranych pod wybranym względem. Pamiętajmy, że bazy danych mogą zawierać tysiące raportów błędów. Manualne przeszukiwanie czy sortowanie tak wielkiej listy jest niewykonalne. Urok rejestrowania błędów w bazie danych polega między innymi na tym, że wykonywanie pytań staje się tak łatwe. Rysunek 19.1 pokazuje typowe okno służące do budowania pytań, z przykładowym pytaniem gotowym do wprowadzenia do aplikacji.
Rysunek 19.1  Większość baz danych służących do rejestracji i śledzenia błędów umożliwia budowanie pytań, które pozwalają uzyskiwać poszukiwaną informację (baza danych Mantis, za zgodą Dave’a Ball’a z HBS International, Inc.)
Ten program do budowania pytań, jak większośc innych, używa standardowych operatorów logicznych ORAZ i LUB oraz nawiasów do konstruowania złożonych pytań. W pokazanym przykładzie tester poszukuje listy błędów spełniających następujące kryteria: 97.Nazwa produktu brzmi Mantis LUB Mantis Web ORAZ 98.…błąd został otwarty albo przez IraCol LUB przez JosNar ORAZ 99.…obecny status błędu jest Zamknięty.
Kliknięcie w przycisk Zadaj Pytanie spowoduje szukanie w bazie danych wszystkich błędów spełniających podane kryteria. Wynikiem przeszukiwania będzie lista numerów i tytułów błędów spełniających te kryteria.
Rodzaje pytań, które można zadawać zależą od tego, jakie pola znajdują się w bazie danych, jakie wartości pola te mogą przyjnować, oraz od funkcji aplikacji do obsługi bazy danych. Daje się w każdym razie zwykle uzyskać odpowiedź na niemal każde pytanie dotyczące testowania i jego relacji do projektu. Oto przykładowa lista pytań, na które większość baz danych udzieli odpowiedzi: 100.Jakie są idnetyfikatory rozwiązanych błędów, przypisanych w ostatniom czasie danemu testerowi do zamknięcia? 101.Ile raportów błędów przedłożył dany tester w trakcie trwania projektu? W ostatnim tygodniu? Między 1 kwietnia a 31 lipca? 102.Które z wprowadzonych przez danego testera raportów dotyczących interfejsu użytkownika zostały rozwiązane jako „nie do naprawy”? 103.Ile błędów zarejestrowanych przez danego testera miało wagę 1, a ile wagę 2?
104.Spośród wprowadzonych przez danego testera błędów, ile już naprawiono, ile zostało odroczonych, a ile było duplikatami?
Odpowiedzią na postawione pytanie jest lista błędów, taka jak pokazana w oknie na rysunku 19.2. Znajdują się w niej - w kolejności swoich numerów - wszystkie błędy spełniające kryteria postawione w pytaniu. Błędy, których nie ma na liście, kryteriów nie spełniają.
Numrery (identyfikatory) błędów
Tytuły (skrócone opisy) błędów spełniających kryteria
Lista błędów spełniających kryteria pytania
Rysunek 19.2  Odpowiedź na postawione pytanie pojawia się w oknie aplikacji bazodanowej jako lista błędów spełniających kryteria pytania.
Możliwość stawiania pytań i przeszukiwania bazy danych jest wielką pomocą w uzyskiwaniu informacji niezbędnej do oceny jakości wykonanej pracy oraz do planowania dalszych działań. Kolejny krok to przedstawienie odpowiedzi na pytanie (lub pytania) w formie drukowanego raportu, najlepiej w postaci graficznego diagramu. Rysunek 19.3 pokazuje jak może wyglądać dialog funkcji stosowanej do konstruowania takich raportów.
Rysunek 19.3  Ta baza danych pozwala dokonać wyboru, które pola każdego rekordu mają zostać wyeksportowane na plik (tekstowy lub w formacie aplikacji do obróbki teskstu).
Na rysunku 19.2 znajduje się lista znalezionych błędów. Dla każdego błędu pokazany jest jego numer/identyfikator, tytuł, status, priorytet, waga, decyzja oraz nazwa produktu, którego błąd dotyczy. Czasem potrzebuje się dokładnie tej informacji, ale czasem przydałoby sie więcej lub mniej szczegółów. Definiując, które pola mają zostać wyeksportowane na plik przy pomocy funkcji pokazanej na rysunku 19.3, można precyzyjnie określić, które dane znajdą się w ostatecznym raporcie. Jeśli potrzebna jest lista błędów przypisaneych określonemu testerowi, wystarczy wyeksportować numery i tytuły błędów. Wybierając się na zebranie mające dyskutować na temat otwartych błędów, sporządzi się zapewne raport zawierający numery błędów, ich tytuły, wagi, priorytety oraz nazwisko osoby, której są przypisane. Przykład takiej listy znajduje się w Tablicy 19.1.
Tabela 19.1  Lista otwartych błędów na zebranie Komitetu Błędów
Nr Tytuł błędu Priorytet Waga Przypisany komu 005 Liczby parzyste nie są dodawane poprawnie (nieparzyste poprawnie) 1 2 WaltP 023 0 dzielone przez 0 powoduje awarię 1 1 ElP 024 Ślepe dołączenia do usuniętych tematów w pliku pomocy calc.jlp 3 3 BobH 025 Ślepe dołączenia do nieznanych tematów w pliku pomocy wcalc.hlp 3 3 BobH
030 Błędne kolory w trybie 256 (poprawne w trybie 16) 3 2 MarthaH
Zamiast zapisywać wyniki przeszukiwania w pliku o formacie gotowym do sporządzenia wydruku, można go zapisać w formie samego tekstu z polami oddzielonymi znakiem tabulatora. Taki plik można wczytać do innej bazy danych, do arkusza kalkulacyjnego albo do aplikacji do sporządzania wykresów. Na przykład można sofrmułować następujące pytanie:
Produkt RÓWNA SIĘ Calc-U-Lot ORAZ1 Wersja RÓWNA SIĘ 2.0 ORAZ Otwarty Przez RÓWNA SIĘ Patryk
Takie pytanie stworzy listę wszystkich błędów dla (fikcyjnego) produktu o nazwie Calc-U-Lot, wersji 2.0, otwartych przez kogoś o imieniu Patryk. Jeśli uzyskaną listę, zawierającą pole opisujące wagę błędu, wyeksportować do np. arkusza kalkulacyjnego, można sporządzić wykres taki jak na rysunku 19.4.
Calc-ULot, wer. 2.0 Błędy Patryka posortowane według wagi
Waga 1   Waga 2   Waga 3   Waga 4
Rysunek 19.4  Na podstawie informacji z bazy danych można sporządzać wykresy pokazujące szczegóły na temat stanu testowania.
Ten wykres kołowy nie zawiera tytułów ani opisów błędów, ani dat, ani decyzji, ani nawet mumerów błędów. Widzimy wyłącznie przegląd błędów przypisanych Patrykowi w projekcie wytwarzania aplikacji Calc-U-Lot, wersji 2.0 (istotne jeśli tester lub programista uczestniczy jednocześnie we wjęcej niż jednym projekcie), podzielonych według wagi. Spośród błędów Patryka 45% ma wagę 1, 32% wagę 2, 16% wagę 3 i 7% wagę 4. Za tymi liczbami kryje się wiele istotnych szczegółów, ale w skrócie można powiedziać, że większość przypisanych Patrykowi błędów jest dość poważnych.
Podobnie, rysunek 19.5 pokazuje przykład innego wykresu, sporządzonego na podstawie odpowiedzi na inne pytanie, który pokazuje jak błędy Patryka podzieliły się wedle podjętych decyzji, co z nimi zrobić. Pytanie w celu uzyskania listy błędów wyglądałoby następująco:
Produkt RÓWNA SIĘ Calc-U-Lot ORAZ Wersja RÓWNA SIĘ 2.0 ORAZ Otwary Przez RÓWNA SIĘ Patryk ORAZ Status RÓWNA SIĘ Rozwiązany LUB Status RÓWNA SIĘ Zamknięty
1 Pseudo-kod użyty w tych przykładach to jakby uproszczony SQL (przyp. tłumacza).
Eksportując listę będącą odpowiedzią na powyższe pytanie wraz z polem „Decyzja” do aplikacji generującej wykresy, można wygenerować diagram taki jak na rysunku 19.5, pokazujący, że większość błędów Patryka zostaje naprawionych (dobry znak dla tstera), a tylko niewielki procent zostaje rozwiązanych jako nie dające się odtworzyć, duplikaty, odroczone albo - z różnych powodów - jako „nie-błędy” (fałszywe błędy).
Calc-ULot, wer. 2.0 Błędy Patryka posortowane według rozwiązania
Naprawiony  Nie odtw.  Duplikat  Nie-błąd  Odroczony
Ilość błędów
Rysunek 19.5  Różne pytania pozwalają przedstawić dane na temat błędów z różnych perspektyw. Na tym przykladzie widzimy, jak zostały rozwiązane błędy należące do jednego testera.
Rozpocząwszy testowania, zaczyna się stosować pewne pomiary po to, by śledzić postępy pracy. Niektórzy chętnie stosują pomiar ilości błędów znalezioneych w ciągu jednago dnia, inni posługują się raczej „współczynnikiem naprawialnośći”, jak w powyższym przykładzie. Wydobywając informację z bazy danych, daje sie sporządzić wiele różnych pomiarów. To prowadzi nas do następnego podrozdziału, gdzie będzie mowa o powszechnie stosowanych pomiarach na wyższym poziomie, pokazujących stan i postępy całego projektu. Typowe pomiary stosowane w projekcie
Zabawimy się teraz w „wielkiego szefa” i zastanowimy się nad pytania, nad którymi kierownicy głowią się każdego dnia nad poranną kawą: czy projekt robi postępy? czy oprogramowanie da się dostarczyć zgodnie z harmonogramem? jakie jest ryzyko opóźnienia? jaka jest nieazwodność produktu?
Kierownictwo zawsze jest zainteresowane ogólnymi danymi na temat projektu - jaka jest ogólna jakość i niezawodność produktu oraz czy projekt idzie zgodnie z harmonogramem. Baza danych z błędami jest doskonałym źródłem uzyskania takiej informacji.
Przypomnijmy sobie rozdział 3-ci „Testowanie w rzeczywistości”, gdzie poznaliśmy zasadę - im więcje błędów się znalazło, tym więcej błędów jest jeszcze ukrytych. Ta zasada jest spełniona niezależnie od tego, czy stosuje się ja wobec małego fragmentu kodu, czy wobec oprogramowania składającego się z tysięcy modułów. Stosując ją, można bez trrudu wykonywać pomiary i sporządzać wykresy, pozwalające wyrobić sobie zdanie na temat stanu nie tylko testów, ale całego projektu.
Najprawdopodobniej nie tester, lecz kierwonik testów lub projektu będzie wykonywał te pomiary. Ważne jest jednak, aby również testerzy orientowali się w ich znaczeniu, bo to pozwala zrozumieć związek między własną pracą a postępami zespołu testującego oraz całego projektu.
Rysunek 19.6 jest podstawowym diagramem kołowym, pokazującym jak błędy znalezione w projekcie Calc-U-Lot, wersja 2.0, dzielą się wedle głównych funkcji oraz typów działań programu.
Lokalizacja
Inne
Interfejs użytkowanika
Matematyka całkowitoliczbowa
Matematyka zmiennoprzecinkowa
Matematyka binarna
Dokumentacja
Konfiguracja
Kompatybilność
Calc-U-Lot wer. 2.0 - Błędy w różnych częściach programu
Rysunek 19.6  Diagram kołowy na poziomie całego projektu pokazuje, jak wiele błędów znaleziono w głównych częściach wytwarzanego programu.
Załóżmy, że powyższy wykres wygenerowany został gdzieś w połowie procesu wytwarzania programu. Stosując zasadę „błędy chodzą stadami”, łatwo przewidzieć, które obszary oprogramowania zapewne zawierają jescze wiele błędów i prawdopodobnie będą wymagały dodatkowego testowania.
Trzy dziedziny - interfejs użytkowanika, matematyka całkowitoliczbowa oraz matematyka zmiennoprzecinkowa - łącznie odpowiadaja za 60% znalezionych dotąd błędów. Przy założeniu, że różne dziedziny testowane były równie starannie, istnieje rzeczywiście duże prawdopodobieńastwo, że te trzy naprawdę są pełne błędów i zawierają jeszcze wiele dalszych błędów do znalezienia. Formułując takie wnioski, trzeba jednak poważnie wziąć pod uwagę, czy testowanie odbywało się jednakowo intensywnie w całym projekcie. Mogło się przecież łatwo zdarzyć, że te trzy dziedziny przetestowano już dość starannie, podczas gdy w pozostałych testy ledwo się rozpoczęły! Generując pomiary na podstawie bazy danych błędów, trzeba zawsze uwzględnić, czy wnioski formułuje się na pdstawie prawidłowych danych!
Dane przedstawione w powyższym przykładzie mówią kierwonictwu bardzo wiele o stanie projektu, co wymownie ilustruje, jak istotną informację moża oddestylować z prostych i łatwo zrozumiałych faktów. Zespoły testujące często używają tego typu wykresów, aby zrozumieć skąd bierze się najwięcej błędów i które rejony projektu wymagają najwięcej uwagi. Wykres nie zawiera jednak danych dotyczących czasu. Na przykład jest możliwe, że tempo znajdowania nowych błędów (czyli przyrost łącznej ilości błędów) dla interfejsu użytkownika słabnie, natosmiast wzrasta dla lokalizacji. Tego nie da się powiedzieć na podstawie takiego wykresu. Z tego powodu często używa się innego typu wykresów, pokazujących łączna sumę znalezionych błędów przez dłuższy okres. Rysunek 19.7 jest przykładem takiego wykresu.
Na tym wykresie, początkowe daty tygodni począwszy od 7 czerwca aż do 6 września znajdują się na osi X, zaś ilość znajdowanych każdego dnia błędów na osi Y. Widać, że tempo znajdowania błędów było niskie na początku projektu, stopniowo wzrastało i w końcu ustabilizowało się na poziomie około 15 błędów dziennie. Przyjmijmy, że planowana data wypuszczenia produktu to 15 września. Czy można się spodziewać dotrzymania tego terminu, patrząc na wykres?
Większośc rozsądnie myślących ludzi odpowie "nie". Wykres jednoznacznie pokazuje stabilną frekwencję znajdowania błędów przez dłuższy czas, bez żadnych tendencji spadkowych. Oczywisćie może się zdarzyć, że spadek tempa znajdowania błędów dający się zaobserwować w ciągu ostatnich trzech dni będzie trwał nadal, ale brak na to dowodów. Dopóki nie pojawi sie wyraźny trend, nie ma żadnych powodów sądzić, że oprogramowanie jest gotowe do wypuszczenia.
Wyraźny trend pokazujący dokonany postęp dostrzega się natomiast na rysunku 19.8. Początek wykresu jest taki sam dla obu projektów (rysunki 19.7 i 19.8), ale po osiągnięciu szczytowego poziomu w połowie lipca, ilość znajdowanych błędów wyraźnie maleje, w końcu spadając do około jednego-dwóch dziennie - wyraźny wskaźnik, że błędów w oprogramowaniu jest coraz mniej i dlatego stają się coraz trudniejsze do znalezienia.
Ilość błędów
Calc-U-Lot wer. 2.0 - Ilość błędów otwartych w różnych tygodniach
Data otwarcia
Błędy otwarte każdego dnia
Rysunek 19.7  Wykres ilości błędów otwartych w różnych tygodniach ujawnia wiele na temat projektu wytwarzania oprogramowania .
Ilość błędów
Calc-U-Lot wer. 2.0 - Ilość błędów otwartych w różnych tygodniach oraz wykres łącznej ilości otwartych błędów
Data otwarcia
Błędy otwarte każdego dnia
Skumulowana ilość błędów
Rysunek 19.8  Ten wykres dotyczy projektu, który ma szansę zrealizować zaplanowaną datę wypuszczenia produktu 15 września.
Wykres na rysunku 19.8 zawiera dodatkową linię skumulowanej ilości błędów znalezionych od początku testowania. Widać jej systematyczne wznoszenie się, a potem wypłaszczenie, świadczące o malejącej frekwencji znajdowanych błędów. Projekt, który dotarł już do tego momentu, ma zwykle znaczne szanse wypuszczenia produktu. Interpretując dane trzeba zachować ostrożność. Weźmy pod uwagę wykres na rysunku 19.8. Widać na nim, że tempo znajdowania nowych błędów wyraźnie maleje. Można przyjąć, że dzieje się tak dzieki temu, że produkt staje się stopniowo - wraz z usuwaniem wcześniej znalezionych błędów - coraz stabilniejszy. Nie można jednak wykluczyć, że ten efekt wiąże się np. z mniejszą ilością testerów w pracy z powodu epidemii grypy! Kiedy testerzy nie testują, znajduje się mało błędów i wykres wygląda dokładnie tak samo, jak wóczas gdy produkt staje się coraz stabilniejszy.
Użyte w powyższych przykładach uproszczone wykresy mają na osi X jedynie daty kalendarzowe. W odniesieniu do rzeczywistego projektu należałoby na tej osi uwzględnić nie tylko daty, ale również harmonogram projektu i główne punkty kontrolne, takie jak planowane dostawy programu, kolejne fazy testowania itp. Mogłoby to na przykład wyjaśnić, czemu częstotliwość znajdowania błędów maleje w pewnym momencie (jedna faza testowania została zakończona i testerzy czekają na nową dostawę), albo czemu gwałtownie wzrasta (rozpoczęto testowanie dużej ilości wcześniej nietestowanego kodu). Wykres to tylko graficzne przedstawienie danych. Aby stał się użyteczny, musi być wytłumaczony i zrozumiały.
Wykres, który niezwykle skutecznie ilustruje stan projektu, pokazany jest na rysunku 19.9. Jest on podobny do wykresu z rysunku 19.8, ale dodane zostały na nim dwie dodatkowe krzywe: jedna pokazuje sumę ilości rozwiązanych błędów, druga sumę ilości zamkniętych błędów. Cieniowanie przestrzeni między krzywymi podkreśla granice między nimi.
Ilość otwartych błędów
Calc-U-Lot wer. 2.0 - Ilość błędów otwartych, rozwiązanych i zamkniętych
Data otwarcia
Błędy otwarte
Błędy rozwiązane
Błędy zamknięte
Rysunek 19.9  Czy to jest najlepszy z możliwych wykres stanu testowania w projekcie? Może tak, może nie. Na pewno bardzo dobrze ilustruje stan projektu.
Górna krzywa jest ta sama, co na rysunku 19.8 i przedstawia ilość wszystkich otwartych błędów. Tutaj nie ma żadnej nowości. Następna krzywa reprezentuje rozwiązane błędy - te, które zostały naprawione przez programistów albo co do których komitet podjął decyzję, że nie będą rozwiązywane. Wraz z upływem czasu, ta krzywa - należy mieć nadzieję - wznosi się do góry, podążając w ślad za krzywą błędów otwartych. Odstęp między krzywymi (na wykresie obszar wypełniony czarnym kolorem) będzie istniał prawie zawsze, ponieważ z reguły programiści ani komitet nie są w stanie rozwiązywać błędów natychmiast, gdy się pojawią. Zwykle błędy gromadzą się i odstęp ten początkowo się powiększa. W końcu programiści i inne osoby odpowiedzialne za rozwiązywanie błędów zaczynają nadrabiać zaległości i obie linie schodzą się - ilość błędów w jakiś sposób rozwiązanych pokrywa się z ilością błędów otwartych. Błąd rozwiązany to nie zawsze to samo, co błąd naprawiony. Niektóre błędy zostaną określone jako duplikaty, jako błędy, których nie będzie się naprawiać, jako fałszywe błędy itd.
Trzecia krzywa pokazuje ilość błędów zamkniętych. Pamiętajmy, że błąd naprawiony kierowany jest z powrotem do testera, aby sprawdzić, czy błąd faktycznie jest naprawiony, czy naprawa nie spowodowała innych błędów itd. Jeśli wszystko jest w porządku, błąd się zamyka. Krzywa ta znajduje się poniżej krzywej błędów rozwiązanych z tego samego powodu, co krzywa rozwiązanych nie nadąża sa krzywą otwartych - testerzy nie zdążają zamykać błędów natychmiast, kiedy zostaną naprawione, ponieważ ich czas pochłania przede wszystkim testowanie całej reszty oprogramowania. W końcu jednak zaległości zostają nadrobione i krzywa błędów zamkniętych łączy się z krzywą błędów rozwiązanych, gdy obie spłaszczają się - kiedy znajduje się coraz mniej nowych błędów.
O czym mówi nam ten wykres? Obszary czarny i szary informują, ile pracy pozostało jeszcze programistom i testerom. Poszerzający się pas czarny ostrzega, że programiści zostają coraz dalej i dalej w tyle z rozwiązywaniem znalezionych błędów. Poszerzający się pas szary wskazuje, że testerzy coraz bardziej nie nadążają z ponownym testowaniem błędów juz naprawionych. Kiedy krzywe wypłaszczają się i zbliżają do siebie, kierownik projektu zaczyna lepiej w nocy spać. Ten wykres zwykle rysuje się w kolorach. Czerwony oznacza błędy otwarte, żółty - rozwiązane, a zielony - zamknięte. Jeden rzut oka pokazuje, w jakim stanie znajduje się projekt. Dużo czerwieni oznacza dużo pracy dla programistów. Dużo żółtego oznacza pełno pracy dla testerów. Dużo zieleni oznacza, że projekt zbliża się do końca.
Połączenie krzywych ilości błędów otwartych, rozwiązanych i zamkniętych na jednym wykresie pozwala zobaczyć całościowy obraz stanu projektu i zmniejsza ryzyko błędnej interpretacji danych. Wspomniano już, że spłaszczenie krzywej ilości otwartych błędów mogło oznaczać albo brak błędów, albo brak testerów. Różnicy nie dało się dostrzec na podstawie dostępnych danych. Jeszcze inna możliwość to że zespół testerów postanowił przez kilka dni poświęcić się głównie testowaniu naprawionych błędów i nie wykonywał dużo nowych testów. Mając te informacje dostępne jednocześnie na jednym wykresie można łatwiej zrozumieć, co się stało. Pamiętajmy o tym usiłując odpowiedzieć na jedno z pytań zmaykających rozdział. Podsumowanie
Opisane w tym rozdziale rodzaje pomiarów nie są w żadnym razie listą ostateczną. Sa to tylko przykłady powszechnie stosowanych pomiarów używanych do śledzenia i określania statusu projektów informatycznych. Każdy zespół projektowy, kierownik projektu albo tester wybierze te pomiary, które w jego odczuciu najlepiej informują go o stanie projektu. Niektórzy mogą śledzić średnią warość wagi znajdowanych błędów. Dla innych będzie ważniejsze, jak szybko znajdowane błędy są rozwiązywane. Ktoś może chcieć wiedzieć, ile błędów przeciętnie znajduje w ciągu jednego dnia lub jaki jest stosunek ilości jego błędów znalezionych do naprawionych. Calem dokonywania pomiarów i posługiwania się ich wynikami jest wiedzieć, jak dobrze nam wychodzi praca, czy wszystko toczy się zgodnie z planem, a jeśli nie - co można zrobić by poprawić sytuację.
Rozdział 20-y "Zapewnienie jakości oprogramowania" zapozna nas z kolejnym poziomem na drabinie ewolucyjnej, sięgającym poza testowanie oprogramowania, gdzie pomiarów nie używa się tylko dla celów jednego, bieżącego projektu, ale również aby ocenić i ulepszyć całość procesu wytwórczego. 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.Czemu - wykorzystując dane pomiarowe z bazy danych ze znalezionymi błędami - liczenie tylo i wyłącznie ilości blędów znalezionych jednego dnia lub obliczenie średniej ilości błędów znajdowanych dziennie nie dałoby wystarczającgo obrazu stanu projektu? 2.Uzupełniając odpowiedź na pytanie 1-e, jakie inne dane pomiarowe warto wziać pod uwagę, aby trafnie i skutecznie mierzyć jakość własnej, osobistej jakości pracy jako testera? 3.Jak wyglądałoby pytanie postawione bazie danych (wolno użyć dowolnego formatu i składni "pseudojęzyka"), które miałoby wydobyć z niej wsztystkie rozwiązane błędy, przypisane Terry'emu, w projekcie Calc-U-Lot, wersja 3.0? 4.Jeśli tempo znajdowania nowych błędów słabnie (jak na rysunku 19.8) i wszyscy bardzo się cieszą, że projekt zbliża się do celu, jakie mogą być powody (wymień kilka), że liczby kłamią, tj. że stan produktu/projektu wcale nie jest dobry, mimo że błędów znajduje się coraz mniej?