Rozdział 20

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?