Przebranżowienie na testera

VI Przyszłość
Kiedy tylko zaczęliśmy programować, okazało się - ku naszemyu zdumieniu - że wcale nie było tak łatwo jak sądziliśmy zrobić programy bezbłędnie. Przyszło nam wówczas odkryć usuwanie błędów z programu, „odpluskwianie”. Pamiętam do dziś dokładnie tę chwilę, kiedy sobie uśiwadomiłem, że znaczną część życia spędzę szukając błędów we własnych programach.
- Maurice Wilkes, jeden z pionierów komuteryzacji
W TEJ CZĘŚCI Zapewnienie jakości oprogramowania Kariera testera oprogramowania
Zapewnienie jakości oprogramowania
W TYM ROZDZIAŁE Jakość jest za darmo Test i zapewnienie jakości w przedsiębiorstwie Zarządzanie testowaniem a struktury organizacyjne CMM (Model Poziomu Jakości Procesu Wytwarzania) ISO 9000
Tematyka tej książki jest zgodna z jej tytułem – dotyczy przede wszystkim testu oprogramowania. Nauczyliśmy się jak planować testowanie, gdzie szukać błędów, jak je znajdować i jak raportować. Kto jest w tej branży początkujący, przypuszczalnie z tymi wlaśnie czynnościami zetknie się najpierw.
Warto jednak umieć spojrzeć na tę dziedzinę z szerszej perspektywy, aby zdawać sobie sprawę, co jeszcze można osiagnąć i jakie istnieją możliwości dalszej kariery. Celem tego rozdziału jest przedstawić to, co znajduje się poza testowaniem oprogramowania, nakreślić możliwosci i wyzwania, i zmotywować – miejmy nadzieję – czytelników do uczynienia z jakości swojego własnego celu.
Najważniejsze punkty tego rozdziału: 1. Jaki jest koszt wytwarzania oprogramowania o wysokiej jakości? 2. Jaka jest różnica między testowaniem a zapewnieniem jakości oprogramowania? 3. Różne formy, w jakich grupa odpowiedzialna za test - lub szerzej za jakość - może uczestniczyć w pracach projektu 4. Jak stosować CMM? 5. Standard ISO 9000 Jakość jest za darmo
Jakość za darmo? Niedmożliwe! Nie, to prawda. Philip Crosby1 napisal w swojej książce Jakość za darmo: co zrobić by osiągnąć jakość na pewno? (Quality is Free: The Art of Making Quality Certain), że zbudowanie produktu o wysokiej jakości nie kosztuje wcale więcej (często mniej) niż produktu o niskiej jakości. Wziąwszy pod uwagę to, czegośmy się dotąd nauczyli na temat ilości pracy niezbędnej do znajdowania i poprawiania błędów, może się to wydawać niemożliwe – a jednak jest możliwe.
Przypomnijmy sobie wykres z rozdziału 1-ego (powtórzony poniżej jako rysunek 20.1), pokazujący koszty znajdowania i naprawiania błędów w różnych fazach życia produktu. Im później znajduje się błędy, tym bardziej kosztowna jest ich naprawa – nie jest to w dodatku zależność liniowa, lecz wykładnicza.
Teraz podzielmy koszty jakości na dwie grupy: koszty osiągnięcia i koszty nieosiągnięcia potrzebnej jakości. Koszty osiągniecia jakości to koszty związane z planowaniem i wykonaniem wszystkich testów jeden raz, aby zweryfikować poprawność oprogramowania. Jeśli znajduje się jednak błędy i trzeba poświęcić czas na ich wyizolowanie, raportowanie i testowanie regresywne, wtedy koszt nieosiągnięcia jakości wzrasta. Te koszty, które ponosi się przed oficjalnym wypuszczeniem produktu, klasyfikuje się jako koszty awarii wewnętrznych; znajdują się one głównie po lewej stronie rysunku 20.1
Koszty naprawy błędu
Specyfikacja   Projekt   Kodowanie  Test   Wdrożenie
Faza, w której znaleziono błąd
Rysunek 20.1  Ten wykres ułatwia zrozumienie, dlaczego jakość jest za darmo
Jesli błędy nie zostaną znalezione i dostaną się do produktu dostarczonego do klientów, skutkiem będą kosztowne telefony do działu obsługi, ewentualnie naprawa, ponowne testy i wypuszczenie nowej wersji, a – w najgorszym razie – koszty wycofania produktu lub procesów sądowych. Te koszty – zwane kosztami awarii zewnętrznych – są także kosztami nieosiągniecia jakości i znajdują się po prawej stronie rysunku 20.1.
1 Philip Crosby, Joseph Juran i W. Edwards Deming są często określani jako “ojcowie jakości”. Napisali na temat zepewnienia jakości wiele książek i wiele z opisanych przez nich metod jest dziś powszechnie stosowanych na całym świecie. Chociaż ich prace nie dotyczą szczególnie oprogramowania, odnoszą się jednak w równym stopniu do różnych dziedzin. Miłej lektury!
W swojej książce Crosby demonstruje, że koszty osiągnięcia jakości plus koszty awarii wewnętrznych są mniejsze niż koszty awarii zewnętrznych. Niszcząc wszelkie błędy jak najwcześniej, albo – najlepiej – nie mając w ogóle żadnych błędów, uzyskujemy produkt taniej niż wtedy, kiedy awarie zdarzają się u klientów. Jednym słowem, jakość nic nie kosztuje – to czysto zdroworozsądkowy wniosek.
Niestety, nie wszędzie w przemyśle informatycznym zdołano zaakceptować tę prostą prawdę. Niejednokrotnie projekt zaczyna się pełen najlepszych intencji, ale kiedy pojawiają się pierwsze trudności i przestaje się nadążać za harmonogramem, zasady i rozsądek wyrzucane są do kosza. Na szczęście obserwuje się dziś również tendencje odwrotne. Firmy zaczynają zdawać sobie sprawę, że ich koszty jakości są zbyt wysokie, ale nie muszą. Klienci zaczynają się domagać oprogramowania dobrej jakości, a konkurencja zaczyna być w stanie je dostarczyć. Uswiadamiamy sobie, że to co Crosby napisał 20 lat temu z myslą o przedsiębiorstwach produkcyjnych, dotyczy jak najbardziej również dzisiejszego przemyslu informatycznego. Test i zapewnienie jakości w przedsiębiorstwie
W różnych przedsiębiorstwach, a nawet w różnych projektach, zespół w którego skład wchodzą testerzy występuje pod rozmaitymi szyldami: testowanie oprogramowania, zapewnienie jakości oprogramowania, kontrola jakości, weryfikacja i walidacja oprogramowania, test i integracja oprogramowania – i wiele innych. Często te nazwy stosowane są zamiennie lub jedną z nich wybiera się, bo brzmi bardziej „oficjalnie”, jak na przyklad „inżynier zapewnienia jakości” (Quality Assurance Engineer) w porównaniu z „testerem oprogramowania”. Trzeba sobie jednak zdawać sprawę, że te nazwy w gruncie rzeczy różnią się od siebie znacznie i nie są synonimami. Z jednej strony ma się do czynienia z podejściem że „to tylko nazwa”, a to co się naprawdę liczy to treść wykonywanej pracy. Z drugiej strony, nazwa zespołu czy nazwa wykonywanej przez pracownika roli to jest to, co przede wszyskim widzą inni członkowie zespołu projektowego. Etykietka zespołu określa oczekiwania innych: co dany zespół będzie dostarczać1 i jakich dostaw sam oczekuje. Kolejne części tego rozdziału poswięcone są zdefiniowaniu często spotykanych nazw dla zespołu odpowiedzialnego za testowanie i mają na celu wyjaśnienie różnic miedzy nimi.
Testowanie oprogramowania (Software Testing)
Nigdy dość tego powtarzać, więc jeszcze raz:
Celem testowania oprogramowania jest znajdowanie błędów, znajdowanie ich tak wcześnie jak się tylko da oraz dopilnowanie, by zostały naprawione.
1 Typowe nieporozumienia to np. oczekiwanie, ze zespół testowy odpowiada za wykonanie integracji (to jest możliwe, ale wymaga o wiele więcej środków i innego typu umiejętności niż sam test) oraz że zespół testowy odpowiada za… system do raportowania błędów (przyp. tlumacza).
W tej książce poznaliśmy wszelkie szczegóły tej definicji – w jaki sposób osiagnąć te cele oraz ograniczenia i trudności w rzeczywistości. Można określić testowanie oprogramowania jako zadanie polegające na oszacowaniu, raportowaniu i śledzeniu. Zajduje się błędy, przekonywująco je opisuje, informuje właściwe osoby oraz śledzi błędy, dopóki nie zostaną rozwiązane.
Definicja pracy testera w tej książce wykracza poza oszacowanie, raportowanie i śledzenie, bowiem dodana jest do nich odpowiedzialność za to, by błędy faktycznie zostały naprawione. Aczkolwiek wielu testerów poprzestałoby na okresleniu „raportowanie”, ja osobiście jestem przekonany, że bycie skutecznym testerem wymaga ponoszenia specjalnej, osobistej odpowiedzialności za znajdowane błędy, śledzenia ich przez cały cykl życiowy i nakłanianie odpowiedzialnych osób do tego, by błędy zostały naprawione. Najłatwiej jest oczywiście po prostu umieścić raport błędu w bazie danych i mieć nadzieję, że ktoś go dostrzeże i coś w jego sprawie zrobi, ale gdyby na tym poprzestać, ktoś mógłby spytacć – po co w ogóle szukać błędów?
Pamiętajmy o jednej bardzo ważnej rzeczy: tester oprogramowania nie jest odpowiedzialny za jakość oprogramowania! Może to brzmieć dziwnie, ale jest prawdą. Nie tester stworzył przecież błędy w programie, plan testów został zaaprobowany przez kierownika projektu i przez programistów, plan został zrealizowany co do joty i mimo wszelkich wysiłków, program nadal miał błędy. To nie jest winą testera!
Zastanówmy się nad tym. Lekarz nie jest w stanie spowodować, by gorączka spadła, mierząc temperaturę. Meteorolog nie powstrzyma huraganu mierząc szybkość wiatru. Tester nie potrafi naprawić produktu złej jakości przy pomocy samego znajdowania błędów. Testerzy po prostu meldują fakty. Nawet jeśli tester bardzo się stara, by znalezione błędy rzeczywiście zostały naprawione, te wysiłki nadal nie są w stanie przemienić złego produktu w dobry. Jakości nie da się „wtestować” i kropka.
W niektórych przedsiębiorstwach wierzy się, że jakość można stworzyć przy pomocy testowania. Zamiast poprawić metodykę wytwarzania oprogramowania, sądzi się, że rozwiązaniem jest dodanie większej ilości testerów. Sądzi się, że więcej testerów, znajdując więcej błędów, uczyni produkty lepszymi. Ciekawe, że ci sami ludzie nigdy nie zaproponowaliby użycia większej ilości ternmomwtrów, by obniżyć gorączkę.
Kierownik zespołu testującego lub menedżer testów jest odpowiedzialny za to, by każdy w zespole projektowym rozumiał rolę testera. Ta kwestia staje się często kością niezgody gdy harmonogramu nie udaje się dotrzymać lub gdy błędy prześlizgują się przez kontrolę, tak że najlepiej wyjaśnić wszystko z góry - w planie testowania projektu.
Zapewnienie jakości (Quality Assurance, QA)
Inną nazwą często nadawaną grupie zajmującej się poszukiwaniem błędów jest „Zapewnienie jakości”. W rozdziale 3-im została podana następująca definicja osoby pełniącej tę funkcję:
Inżynier zapewnienia jakości bada i dokonuje pomiarów procesu wytwarzania oprogramowania w celu znalezienia sposobów ulepszenia go i zapobieżenia powstawaniu błędów.
Teraz, kiedy wiemy już więcej na teamt testowania, ta definicja chyba wydaje się o wiele groźniejsza niż kiedy przeczytaliśmy ją po raz pierwszy. Grupa zajmująca się zapewnieniem jakości ma o wiele szerszy zakres działania i odpowiedzialności niż grupa testująca - a przynajmniej tak powinno być, zgodnie z definicją jej funkcji. Oprócz wykonywania części lub całości testowania1, grupa ma za zadanie zapobiegać powstawaniu błędów i zapewnieniu właściwego (przypuszczalnie wysokiego) poziomu jakości i niezawodności oprogramowania. Ta grupa nie tylko testuje i raportuje, lecz ma znacznie dalej idące zadania. Teraz widać dlaczego, jeśli budżet i czas dostępny dla grupy pozwala tylko na wykonywanie testownania, ryzykowne może być przyjęcie tego bardziej „prestiżowego” tytułu.
Można sobie zadać pytanie - skoro sam test nie jest w stanie zapewnić jakości produktu, co grupa zapewnienia jakości może w tej sprawie uczynić innego? Odpowiedź to pełna kontrola nad projektem, wdrażanie standardów i metodologii, staranne śledzenie i monitorowanie oraz ocena jakośći procesu wytwarzania, składanie propozycji sposobów rozwiązywania znajdowanych problemów, wykonywanie części testowania oraz podejmowanie decyzji o gotowaości produktu do wypuszczenia i dostawy. Z pewną przesadą można określić, że grupa zapewniania jakości jest jakby dodatkowym kierownikiem projektu, którego głównym celem jest „brak błędów”, podczas gdy właściwy kierownik projektu ma głównie na celu zrealizowanie projektu w ramch dostępnego budżetu i harmonogramu.
Jak dowiemy się w dalszej części rozdziału, przejście od testowania do zapewnienia jakości jest zwykle stopniowym procesem, jakby osiągania kolejnych poziomów dojrzałości. Nie jest to jeden krok - wczoraj było się testerem, a dziś jest się specjalistą od zapewnienia jakości.
1 Ile testowania powinna wykonywać grupa zapewniania jakości zależy od poziomu jakości procesu wytwarzania. Dowiemy się więcej na temat poziomów jakości procesu w dalszej części rozdziału.
Niektóre z umiejętności nabytych w trakcie lektury tej książki można określić jako należące do zapewniania jakości, zależnie od tego, gdzie przprowadzić granicę między znajdowaniem a zapobieganiem błędom oraz granicę między wewnętrzymi i zewnętrznymi awariami. Skoro celem zapewnienia jakości jest zapobieganie błedom, to można twierdzić, że testowanie statyczne specyfikacji produktu, dokumetnacji oraz kodu (rozdziały 4-y i 6-y) należy do zapewniania jakości, gdyż zapobiega pojawieniu się błędów. Błędy w ten sposób znalezione i usunięte nie będą mogły być później znalezione przez testerów wykonujących dynamiczne testowanie gotowego produktu.
Total Quality Management
Każdy słyszał zapewne o metodach zwanych Total Quality Management (Sumaryczne Zarządzanie Jakością) lub Total Quality Control (Sumaryczna Kontrola Jakości). Główna myśl tego podejścia zasadza się na tym, że scentralizowane zarządzanie jakością - poprzez zespół dopowiedzialny za zapewnienie jakości - nie sprawdza się, gdyż ludzie wykonujący faktyczną pracę, jak pisanie kodu czy tworzenie elementów graficznych, nie czują się odpowiedzialni za jakość i dlatego nie usiłują jej osiągnąć. Aby osiągnąć produkty o wysokiej jakości, kultura jakości musi być obecna w całej organizacji tak, by każdy był współodpowiedzialny za jakość.
Choć idea TQM/TCM ma istotne implikacje dla funkcji istniejącej grupy zapewnienia jakości, to nie elimiminuje ona oczywiście konieczności testowania oprogramowania. Przeciwnie, rola testowania w środownisku realizującym TQM jest jeszcze wyraźniej określona. Mimo wszelkich wysiłków, oprogramowanie wytwarzane jest przez ludzi, a ludzie popełniają błędy. Naadal potrzebna jest grupa w całości skoncentrowana na poszukiwaniu błędów. Może nie znajdą wiele, ale to tylko dobrze!
Inne nazwy dla zespółu odpowiedzialnego za test
Zależnie od miejsca pracy, można spotkać jeszcze inne nazwy na grupę zajmującą się poszukiwaniem i raportowaniem znalezionych błędów. Często spotyka się określenie Kontrola Jakości Oprogramowania (Software Quality Control, SQC). Nazwa ta pochodzi z systemów produkcyjnych, gdzie inspektorzy Kontroli Jakości pobierają próbki z linii produkcyjnej, testują je i - jeśli znajdą błędy - mają prawo zamknąć linię produkcyjną lub nawet całą fabrykę. Niewiele zespołów testujących oprogramowanie ma taką władzę, nawet jeśli nazywają siebie Kontrolą Jakości Oprogramowania.
Weryfikacja i walidacja oprogramowania to również często spotykane określenie organizacji testującej oprogramowanie. To bardzo dobra nazwa. Choć nieco przydługa, określa dokładnie to za co grupa jest odpowiedzialna i co robi. W rozdziale 3-im znajdują się definicje weryfikacji i walidacji. Moga nawet istnieć dwie grupy, jedna zajmująca się weryfikacją, a druga - walidacją.
Test i integracja, test i budowa, zarządzanie konfiguracją i test, test i zarządzanie laboratorium i inne podobne, złożone nazwy są z reguły sygnałem istnienia problemów. Niejednokrotnie, dobrowolnie lub nie, grupa testująca bierze na siebie role nie mające wiele związku z testowaniem. Na przykład, często można się zetknąć z sytuacją, że zespół testujący zajmuje się zarządzaniem konfiguracją lub integracją czy budowaniem produktu. Wynikają z tego dwojakie problemy: 6. Maleją środki dostępne do testowania produktu. 7. Celem grupy testującej jest usiłowanie wywoływania awarii, a nie praca konstrukcyjna, tak że odpowiedzialność za integrację stwarza potencjalny konflikt interesów.
Najlepiej, żeby programiści albo osobny zespół byli odpowiedzialni za integrację i budowanie systemu. Testowanie powinno móc sie skoncentrować na znajdowaniu błędów. Zarządzanie testowaniem a struktury organizacyjne
Oprócz nazwy i przyjętej oficjalnie roli, istnieje trzecie zagadnienie wywierające wielki wpływ na to, co robi zespół testujący i jaka jest jego rola w zespole projektowym. Chodzi o to, w jaki sposób zespół testowy włączony jest w ogólną strukturę organizacyjną projektu. Istnieją różne struktury organizacyjne i każda z nich ma swoje plusy i minusy. O niektórych twierdzi się, że są generalnie lepsze, ale to, co działa dobrze w jednym miejscu, nie musi funkcjonować równie dobrze gdzie indziej. Kto pracuje przez dłuższy czas z testowaniem, zetknie się zapewne z wieloma z tych struktur. Oto kilka przykładów.
Na rysunku 20.2 znajduje się struktura często stosowana przez małe (poniżej 10-ciu osób) zespoły projektowe. W tej strukturze, zespół testowy podporządkowany jest kierownikowi produkcji, czyli osobie nadzorującej pracę programistów. Wziąwszy pod uwagę to, co wiemy na temat testowania, powinno teraz nam zamigotać żółte światło ostrzegawcze - jeśli osoby piszące kod i osoby szukające w kodzie błędów podporządkowane są jednej i tej samej osobie, może to spowodować wiele problemów.
Kierownik produkcji
ProgramiściTesterzy
Rysunek 20.2  W strukturze organizacyjnej małego projektu zespół testowy często podporządkowany zostaje kierownikowi  produktu.
Powstaje wtedy nieunikniony konflikt interesów. Celem kierownika produkcji jest wytwarzanie oprogramowania. Testerzy meldujący o znalezionych błędach stwarzają na pozór przeszkody w osiągnioęciu tego celu. Kiedy testerzy wykonują dobrze swoja pracę, praca programistów zczyna wyglądać gorzej. Jeśli kierownik da do dyspozycji więcej środków testerom, znajdą oni zapewne więcej błędów, a im więcej błędów znajdą, tym bardziej utrudnią rolę kierownikowi produkcji dążącemu do wytworzenia gotowego oprogramowania.
Mimo tych minusów, struktura taka może nieźle funkcjonować pod warunkiem, że kierownik ma duże doświadczenie i zdaje sobie sprawę, że jego rzeczywistym celem nie jest po prostu zbudowanie programu, lecz zbudowanie programu o odpowiedniej jakości. Taki kierownik będzie traktował testerów i programistów jednakowo. Jest to również bardzo dobra struktura  z punktu widzenia przepływu informacji. Jest w niej minimalna ilość poziomów organizacyjnych, a testerzy i programiści mogą dobrze razem współpracować.
Rysunek 20.3 pokazuje inną, często spotykaną strukturę, gdzie grupa testowa i grupa programistów podporządkowane są kierownikowi projektu. W tym układzie grupa testowa me zwykle swego własnego kierownika, którego uwaga skoncentrowana jest wyłącznie na pracy zespołu testującego. Taka niezależność jest bardzo korzystna, kiedy podejmowane są kluczowe decyzje dotyczące jakości oprogramowannia. Głos zespołu testującego staje się równie ważny co zespołu programistów i innych grup wspólpracujących oprzy wytwarzaniu produktu.
Minusem tej struktury jest jednak fakt, że kierownik projektu ma ostatnie słowo przy podejmowaniu decyzji dotyczących jakości. W wielu branżach i dla wielu typów oprogramowania jest to rozwiązanie w zupełności wystarczające. Przy wytwarzaniu systemów krytycznych dla bezpieczeństwa lub innych systemów wysokiego ryzyka, opłaca się niekiedy, by kontrola jakości była reprezentowana na wyższym poziomie. Struktura takiej organizacji przedstawiona jest na rysunku 20.4.
W takiej organizacji, zespoły odpowiedzialne za jakość podporządkowane są bezpośrednio wyższemu kierownictwu firmy, na tym samym poziomie co poszczególne projekty. Zwykle dotyczy to całości zapewnienia jakości, a nie tylko testowania. Niezależność tej grupy od bezpośredniego kierownictwa projektów umożliwia jej ustalanie standardów i regół, pomiary wyników i przyjmowanie procesów stosowanych przez wiele projektów naraz. Informacja na temat złej - a także dobrej - jakości dociera wprost do najwyższego poziomu organizacji.

Kierownik produkcji
ProgramiściTesterzy
Kierownik testowania
Kierownik projektu
Rysunek 20.3  W organizacji, gdzie zespól testowy podporządkowany jest wprost kierownikowi projektu, testerzy dysponują pewną niezależnością od programistów.
Dyrekcja
Kierownicy produkcji
Kierownicy zapewnienia jakości/testowania
Kierownicy projektów
Rysunek 20.4  Zespół zapewnienia jakości albo zespół testujący podporządkowany bezpośrednio wyższemu kierownictwu ma największą niezależność, największą władzę i największą odpowiedzialność.
Oczywiście, wraz z rosnącą władzą musi pojawić się wzrost odpowiedzilaności i powściągliwość. To, że zapewnienie jakości jest niezależne od projektów nie ma oznaczać, że zacznie ono stawiać nierealne i niemożliwe do osiągnięcia wymagania dotyczące jakości, jeśli takich wymagań nie stawiają klienci ani użytkownicy. Standard przyjęty przez przedsiębiorstwo dla systemów bazodanowych może być zbyt wymagający w odniesieniu do gier komputerowych. Aby działać skutecznie, niezależna organizacja zapewnienia jakości musi umieć współpracować z projektami i umieć połączyć swój entuzjazm dla jakości z praktycznymi wymaganiami produkcji oprogramowania. Niezbędne są też wysiłki, by utrzymać jak najlepsze kontakty z zepołami programistów i innymi członkami zespołów projektowych. Staje się to tym trudniejsze, im bardziej wydłużają się drogi przepływu informacji.
Pamiętajmy, że podane tu trzy struktury to tylko uproszczone przykłady wielu możliwych typów i że opisane plusy i minusy także mogą być bardzo różne. W procesie wytwarzania oporogramowania rzadko ma się do czynienia z niezawodnymi receptami i to, co działa w jednym projekcie, może nie pasowac do innego, na pozór zupełnie podobnego. Dostępne są jednak pewne standardowe pomiary i metody sprawdzone w wielu projektach, które licznym zespołom umożliwiły poprawę jakości. Zapoznamy się nieco z nimi w dwóch następnych podrozdziałach. CMM (Model Poziomu Jakości Procesu Wytwórczego)
Model Poziomu Jakości Procesu Wytwórczego dla oprogramowania (Capability Maturity Model, CMM lub CMM-SW)1 to standard stosowany do określenia i pomiaru dojrzałości procesu wytwórczego przedsiębiorstwa informatycznego i służący do identyfikacji możliwych kierunków poprawy jakości procesu. Model ten został skonstruowany wspólnie przez Software Engineering Institute (SEI), Carnegie Mellon University oraz przedstawicieli przemysłu informatycznego, pod kierownictem Ministerstwa Obronu USA.
CMM ma ogólny charakter i daje się zastosować równie dobrze do każdego przedsiębiorstwa, niezależnie od jego wielkości - od największego koncernu do jednoosobowej firmy doradczej. Wyróżnia on pięć poziomów (patrz rysunek 20.5), które pozwalają dość łatwo oszacować dojrzałość (jakość) procesu wytworczego przedsiębiorstwa i określić, jakie kroki należy podjąc w celu przejścia na wyższy poziom.
Optymalizujący Sterowany Zdefiniowany Powtarzalny Wstępny
Poziomy jakości procesu wg CMM 5. Stała poprawa jakości procesu poprzez ilościowe sprzężenie zwrotne i stosowanie nowych metod. 4. Proces kontrolowany. Szczegółowe pomiary oraz zrozumienie jakości procesu i produktu. 3. Myślenie na poziomie organizacji. Zorientowany zadaniowo i proaktywnie. Udokumentowany i ustandaryzowany. 2. Myślenie na poziomie projektu. Reaktywny. Podobne projekty mogą powtórzyć wcześniejsze sukcesy. 1. Proces chaotyczny, ad hoc. Powodzenie projektu zależy oc szczęścia i od wybitnych jednostek.
Rysunek 20.5  Model Poziomu Jakości Procesu Wytwórczego stosuje się do oceny dojrzałości firmy w procesie wytwarzania oprogramowania.
Czytając dalej, pamiętajmy że spośród wszystkich przedsiębiorstw na świecie zajmujących się wytwarzaniem oprogramowania, większość jest na poziomie 1-ym, sporo znajduje się na poziomie 2-im, nieliczne - na 3-im, garstka - na 4-ym, a zaledwie kilka - na 5-ym. Oto opisy 5-ciu poziomów wyróżniancyh przez CMM:
1 CMM, Capability Maturity Model oraz Carnegie Mellon są znakami firmowymi zarejestrowanymi w Urzędzie Patenowym USA.
8. Poziom 1-y: Wstępny. Proces wytwarzania oprogramowania na tym poziomie jest przypadkowy i zwykle chaotyczny. Powodzenie projektu zależy od szczęścia i od indywidulanych wysiłków jednostek. Nie stosuje się standardowych metod planowania, monitorowania i sterowania procesem. Nie daje się przewidzieć czasu trwania i kosztów projektu. Proces testowania jest równie przypadkowy co reszta procesu wytwarzania. 9. Poziom 2-i: Powtarzalny. Najlepiej go określić jako myślenie na poziomie projektu. Podstawowe elementy procesu zarządzania projektem stosuje się do śledzenia kosztów, harmonogramu, funkcjonalności i jakości projektu. Stosuje się niekiedy doświadczenia zdobyte w poprzednich, analogicznych projektach. Jest poczucie pewnej dyscypliny. Stosuje się podstawowe metody testowe, jak planowanie testowania i dokumentację zadań testowych. 10.Poziom 3-i: Zdefiniowany. Pojawia sie myślenie organizacyjne nie tylko na poziomie projektu. Najważniejsze czynności kierownicze i inżynierskie są unormowane i udokumentowane. Normy te stosuje się w różnych projektach. Norm i standardów nie zarzuca się pod wpływem trudności czy pośpiechu. Dokumentacja testowa i plany testowania podlegają inspekcjom, zamin testowanie się rozpoczyna. Zespół testujący jest niezależny od programistów. Wyniki testowania analizowane są dla oszacowania tego, czy produkt jest juz gotowy. 11. Poziom 4-y: Sterowany. Na tym poziomie proces organizacyjny znajduje się pod kontrolą statystyczną. Jakość produktu definiowana jest z góry wg kryteriów ilościowych (np. "produkt nie zostanie wypuszczony dopóki częstość błędów nie zejdzie poniżej 0,5 błędu na 1000 linii kodu"). Wytwarzanie produktu nie zostaje zakończone, dopóki wymagane kryteria nie zostaną spełnione. Szczegóły dotyczące procesu i jakości produktu są gromadzone w trakcie trwania projektu i dokonuje się korekt w celu utrzymania projektu na kursie.
12.Poziom 5-y: Optymalizujący. Poziom ten nazywany jest optymalizującym (nie "optymalnym"), ponieważ dokonuje się na nim nieustannych poprawek i korekt poziomu 4-ego. Próbuje się stosować nowe technologie i sposoby pracy, wyniki są mierzone. Stosuje się zarówno zmiany przyrostowe jak i skokowe w celu poprawienia jakości. Kiedy ktoś mógłby już pomysleć, że został osiągnięty najlepszy możliwy stan, koło obraca się jeszcze raz i podejmuje się kolejne wysiłki w celu osiągnięcia jeszcze wyższego poziomu.
Czy opis któregoś z poziomów brzmi znajomo? Strach pomyśleć, że większość oprogramowania wytwarzana jest na poziomie 1-ym, ale często nie dziwi to nikogo, kiedy się użyje programu. Czy jednak odważylibyśmy się przejść przez most, lecieć samolotem albo wsiąść do windy zbudowanej na poziomie 1-ym? Pewnie nie. Kiedyś - miejmy nadzieję - konsumenci zaczną energiczniej domagać się wyższej jakości oprogramownaia i firmy stopniowo zaczną się wspinać na wyższe poziomy modelu CMM.
Trzeba zdawać sobie sprawę, że należy do roli testra propagować osiągnięcia przez przedsiębiorstwo wyższego poziomu CMM. Taka decyzja powinna byc podjęta na poziomie kierownictwa przedsiębiorstwa, wdrożona odgórnie. Zaczynając nową pracę jako tester, warto wszakże oszcować z grubsza, na jakim poziomie dojrzałości znajduje się nowa firma i zespół testowy, w którym przyjdzie nam pracować. Mając te dane, lub wiedząc do jakiego poziomu firma dąży, łatwiej będzie mieć samemu realistyczne oczekiwania i trafniej zrozumieć, czego przedsiębiorstwo może oczekiwać od testera.
Więcej informacji na temat CMM można znaleźć w witrynie Software Engineering INstitute, www.sei.cmu.edu/cmm. ISO 9000
Międzynarodowa Organizacja Standaryzacyjna (International Organisation for Standardisation, ISO) ma serię standardów 9000, które odnoszą się rónież do jakości oprogramowania. ISO jest międzynarodową organizacją ustalającą standardy dla wszystkiego, od śrubek i bolców począwszy, a skończywszy - w swojej serii standardów 9000 - na zarządzaniu jakością i zapewnianiu jakości.
Prawie każdy zetknął się w jakiejś formie z ISO 9000, choćby w reklamach produktów czy usług przedsiębiorstw. Często odnośnik do ISO 9000 występuje w postaci małego logotypu obok nazwy firmy. Nie jest łatwo osiągnąc certyfikat ISO 9000, więc fima które to osiągnęła pragnie ten fakt pokazać ewentualnym klientom, zwłaszcza jeśli jej konkurencja takego certyfikatu nie ma.
ISO 9000 jest zbiorem standardów dotyczących zarządzania i zapewnienia jakości, które definiują podstawowy zestaw działań, pozwalających firmie dostarczać produkty zgodnie z wymaganiami jakości jej klientów. Nie ma znaczenia czy ma się do czynienia z wielomiliardową korporacją, czy też z firmą mieszczącą się w garażu, czy produktem jest oprogramowanie, sprzęt rybacki, czy dostawy pizzy do domu. Zasady dobrego zarządzania odnoszą się do nich w tym samaym sotpniu.
ISO 9000 ma dwie ważne zalety: 13.Dotyczy procesu wytwórczego, nie zaś produktu. Obiektem jej zainteresowania jest sposób, w jaki organizacja wykonuje swą pracę, a nie wyniki tej pracy. Nie usiłuje zdefiniować poziomów jakości dla produktów schodzących z taśmy produkcyjnej lub dla oprogramowania na płycie CD. Jak już wiemy, pojęcie jakości jest względne i subiektywne. Celem przedsiębiorstwa powinno być osiągnięcie poziomu jakości zgodnego z oczekiwaniami klientów. W osiągnięciu tego celu pomoże znacząco dobrej jakości proces wytwórczy. 14.ISO 9000 wyznacza jedynie, jakie są wymagania dotyczące procesu, a nie jak je spełnić. Na przykład, standard określa, że zespół projektowy powinien zaplanować i wykonać przeglądy projektów produktu (patrz też rozdziały 4-y i 6-y), ale nie określa, w jaki sposób spełnić to wymaganie. Wykonywanie przeglądów projektów konstrukcji jest pożądane i powinno być wykonane przez odpowiedzialny zespół projektowy (dlatego wchodzi w skład ISO 9000), ale dokładnie w jaki sposób takie przeglądy będą realizowane pozostawia się do decyzji zespołu wykonującego produkt. ISO 9000 określa co trzeba wykonać, ale nie - jak.
Przedsiębiorstwo, które otrzymało certyfikat ISO 9000, osiągnęło określony poziom kontroli jakości w swoim procesie wytwórczym. Nie oznacza to jednak, że jego produkty także osiągnęły określony poziom jakości - aczkolwiek jest prawdopodobne, że jego produkty będą lepszej jakości niż pochodzące z firmy, która ISO  9000 nie osiągnąła.
Z tego powodu, głównie w Unii Europejskiej, ale coraz częściej również w USA, klienci oczekują, że ich dostawcy będą mieli certyfikat ISO 9000. Z dwóch dostawców konkurujących o ten sam kontrakt, ten z nich który ma certyfikat ISO 9000 będzie w korzystniejszej sytuacji.
Standardy z rodziny ISO 9000 stosujące się do oprogramowania to ISO 9001 oraz ISO 9000-3. ISO 9001 dotyczy przedsiębiorstw które projektują, wytwarzają, produkują, instlują i zajmują się obsługą produktów. ISO 9000-3 dotyczy przedsiębiorstw które wytwarzają, dostarczają, instalują i pielęgnują oprogramowanie.
Nie da się w tym rozdziale podać w szczegółach wszystkich wymagań ISO 9000, ale poniższa lista powinna pozwolić się zorientować, jakie rodzaje kryteriów wchodzą w skład standardu. Mijemy nadzieję, że świadomość istnienia międzynarodowej inicjatywy mającej na celu pomóc przedsiębiorstwom stworzyć lepszy proces wytwarzania oprogramowania przyczyni się też do poprawienia humoru czytelnikowi.
Oto niektóre z kryteriów ISO 9000-3: 15.Należy sporządzić szczegółowe plany kontroli jakości, procedury zarządzania konfiguracją, weryfikacji i walidacji produktu (testowanie), niezgodności (błędów) i działań korekcyjnych (napraw). 16.Należy sporządzic i otrzymać akceptację planów wytworzania oprogramowania, w skład którego wejdzie definicja projektu, lista celów projektu, harmonogram projektu, specyfikacja produktu, opis organizacji projektu, analiza ryzyka i założeń oraz starategi kontrolowania ryzyka. 17.Specyfikacja produktu powinna być sformułowana w sposób zrozumiały dla klienta i ułatwiająca przeprowadzenie walidacji w trakcie testowania. 18.Należy zaplanować, określić, udokumentować i wykonywać przeglądy projektów oprogramowania. 19.Należy sporządzić procedury kontrolne dla zmian przeprowadzanych w konstrukcji produktu w trakcie jego cyklu życiowego. 20.Należy sporządzić i udokumentować plan testowania oprogramowania. 21.Należy sporządzić metody pozwalające na kontrolę, czy produkt spełnia wymagania klienta. 22.Należy przeprowadzić walidację oprogramowania i test akceptacyjny. 23.Należy zachować wyniki przeprowadzonych testów. 24.Należy kontrolować w jaki sposób znalezione błędy są badane i rozwiązywane.
25.Należy móc udowodnić gotowość projektu przed jego dostarczeniem do klienta. 26.Należy mieć procedury kontrolowania procesu wypuszczania i dostawy produktu. 27.Należy zidentyfikować i zdefiniować, jakie pomiary dotyczące jakości będą wykonywane. 28.Należy stosować metody staystyczne do kontrolowania procesu wytwarzania oprogramowania. 29.Należy stosować metody statystyczne do oszacowania jakości produktu.
Wszystkie te wymagania wydają sieę dość podstawowe i zdroworozsądkowe. Można zadać sobie pytanie, jak przedsiębiorstwo jest w ogóle w stanie stworzyć oprogramowanie nie mając do dyspozycji procesu spełniającego te kryteria. Zdumiewa, że jest to w ogóle możliwe, ale jednocześnie wyjaśnia, dlaczego tyle dostępnych na rynku programów jest pełnych błędów. Można mieć nadzieję, że z czasem konkurencja i wymagania klientów zmuszą coraz więcej przedsiębiorstw w przemyśle informatycznym do spełnienia zasad ISO 9000.
Kto jest zainteresowany, by dowiedzieć sie więcej na temat ISO 9000, znajdzie materiały w następujących witrynach WWW: 30.Międzynarodowa Organizacja Standaryzacyjna (ISO), www.iso.ch 31.Amercian Society for Quality (ASQ), www.asq.org 32.American National Standards Institute (ANSI), www.ansi.org Podsumowanie
Jedno z praw Murphy'ego głosi, że nigdy nie ma dośc czasu, by wykonać coś poprawnie, ale zawsze jest dość czasu, by zrobić to od nowa - brzmi jak firma na poziomie pierwszym CMM, prawda? Zapomijmy o Murphym i pomyślmy o Philipie Crosby. Miał ona rację głosząc, że jakość zaiste jest za darmo. To tylko kwestia tego, by zespół projektowy pracował według procesu, bez nadmiernego pośpiechu, z sposób zdyscyplinowany i usiłując wykonywać wszystko poprawnie już od początku.
Oczywiście, mimo wszelkich wysiłków, ludzie nadal będą się mylić, a błędy będą się pojawiać. Celem zapewnienia jakości jest, aby przyczyny błędów to były rzeczywiście pomyłki, nie zaś skutki głębokich problemów procesu wytwarzania. Test oprogramowania będzie nadal niezbędny nawet w najlepszej organizacji, ale jeśli wszystko poszłoby dobrze, praca testera może ograniczać się do często powtarzanego stwierdzenia "Nie, dzisiaj nie znalazłem żadnych błędów, ale mijemy nazdzieję, że znajdę coś jutro".
Książka jest już niemal zakończona. Pozostał jescze jeden rozdział, gdzie nauczymy się, jak zdobywać dalsze doświadczenie w testowaniu oprogramowania i gdzie szukać dalszych informacji. 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 istnieją koszty testowania, związane z kosztami osiągnięcia jakości? 2. Prawda czy fałsz: zespół testowy jest odpowiedzialny za jakość. 3. Czemu niełatwo jest spełnić wszystkie wymaganaia, które implikuje tytuł inżyniera zapewnienia jakości? 4. Czemu korzystne jest, by grupa odpowiedzialna za test lub zapewnienie jakości była podporządkowana bezpośrednio kierownictwu firmy? 5. Na jakim poziomie CMM będzie firma, która spełniła warunki standardu 9000-3 dla oprogramowania?

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?