Rozdział 16

Część V Dokumentacja testowania
Nic się naprawdę nie zdarzyło, jeśli tego nie zanotowano.
- Viginia Woolf, angielska pisarka, eseistka i krytk literacki
Przy pisaniu artykułów do czasopism naukowych wydaje się obowiązywać zasada, że zaciera się za sobą ślady, nadaje swojej pracy kształt bardziej gotowy niż to jest naprawdę, przemilcza ślepe uliczki i to, jak na początku miało się zupełnie mylną teorię. Nie a więc gdzie opublikować - w poważnej formie - co się naprawdę zrobiło żeby rzecz zaczęła działać.
- Richard Feynman, amerykański fizyk
W TEJ CZĘŚCI Planowanie testowania Jak pisać zadania testowe i rejestrować ich wyniki Raportowanie wyników Pomiar sukcesu
Rozdział 16  Planowanie testowania
W TYM ROZDZIALE Cele planowania testów Tematyka planowania
Ten rozdział otwiera część V-ą „Dokumentacja testowania”. Omówione dotąd tematy przedstawiały testowanie z lotu ptaka i nauczyły nas podstaw znajdowania błędów - gdzie szukać, jak testować, jak testować skutecznie. Rozdziały należące do części V-ej opisują, jak wszystkie związane z testowaniem czynności planuje się, organizuje i komunikuje zespołowi projektowemu.
Pamiętajmy jaki cel przyświeca testerowi:
Celem testu oprogramowania jest znajdowanie błędów, znajdowanie ich jak najwcześniej i dopilnowanie, żeby zostały naprawione.
Porządne udokumentowanie testowania przy pomocy dobrze skonstruowanych planu testowania, zadań testowych i raportów testów przyczyni się do osiągnięcia tego celu.
Niniejszy rozdział poświęcony jest przede wszystkim planowi testowania, najważniejszemu z dokumentów potrzebnych w pracy testera. Nowy tester przypuszczalnie nie będzie musiał napisać obszernego planu testowania - to zadanie przypadnie w udziale kierownikowi zespołu testowego albo menedżerowi testów. Każdy jednak będzie w jakimś stopniu uczestniczył w wytwarzaniu planu, dlatego potrzebna jest orientacja na czym to zadanie polega i co wchodzi w skład planu testowania. W ten sposób można zarówno przyczynić się do procesu planowania, jak i nauczyć się lepszej organizacji - dla siebie. Poza tym, już wkrótce dzisiejszy początkujący tester stanie się doświadczonym testerem i będzie pisać plany testowania.
Główne tematy tego rozdziału: 1. Cele planowania testowania 2. Dlaczego ważnie jest planowanie, a nie plan 3. Co trzeba uwzględnić w planowaniu 4. Jaka rolę w planie testowania odgrywaja początkujący testerzy Cele planowania testów
Proces testowania nie może funkcjonować w próżni. Testowanie byłoby bardzo trudne, gdyby programiści pisali kod nie informując, co program ma wykonywać, jak działa, kiedy będzie gotowy. Podobnie, jeśli testerzy nie będą informować co planują testować, jakich potrzebują zasobów i jaki mają harmonogram, szanse sukcesu będą nikłe. Najważniejszy nośnikiem informacji na teat tego, co testerzy zamierzają robić, jest plan testownaia oprogramowania.
Standard ANSI/IEEE 829/1983 poświęcony dokumentacji testu oprogrmowania następująco definiuje cel planu testowania:
Określenie zakresu, metodyki, zasobów i harmonogramu testowania. Zidentyfikowanie przedmiotów testowania, funkcji do przetestowania, czynności które trzeba wykonać, osób odpowiedzialnych za każdą z nich oraz ryzyka związanego z planem.
Zarówno ta definicja jak i cała reszta standardu zakłada, że plan testowania jest rodzajem pisemnego dokumentu. Nic w tym dziwnego, ale chociaż ten kawałek papieru (albo dokument elektroniczny) jest końcoweym rezultatem, nie o niego jednak przede wszystkim chodzi.
Plan testowania jest ubocznym produktem szczegółowego procesu planowania, który został podjęty w celu stworzenia tego dokumentu. Istotny nie jest dokument, lecz proces planowania.
Tytuł rozdziału brzmi „Planowanie testowania”, a nie „Pisanie planu testowania”. To rozróżnienie jest zamierzone. Zbyt często napisany plan testowania kończy żywot jako „cegła” - dokument ustawiony na półce, którego nikt nie czyta. Jeśli celem planowania nie jest dokument, lecz proces jago konstruowania - nie pisanie planu lecz definieowanie zadań - problem „cegły” znika automatycznoie.
Nie oznacza to że końcowy dokument - plan testowania opisujący wyniki procesu planowania - jest zbędny. Wręcz przeciwnie, plan testowania jest nadal potrzebny jako referncja i do archiwizowania. W niektórych przemysłach jest wręcz wymagany przez prawo. Ważne jdynie, żeby plan nie był głównym celem, lecz niejako ubocznym produktem procesu planowania.
Njważniejszym celem planowania testowania jest zakomunikowanie - a nie zapisanie - zamiarów, oczekiwań i sposobu rozumienia testu przez zaspół testowy1.
1 Bardzo to piękne deklaracje - zwłaszcza jeśli mają przeciwdziałać nadmiernej "biurokratyzacji" projektów - niemniej warunkiem koniecznym choć niewystarczjącym do skutecznego zakomunikowania - jest zapisanie wyników planowania, zwłaszcza jeśli sie chce, żeby komunikat pozostał aktualny także po upłynięciu pewnego czasu.
Jeśli zespół projektowy spędzi dostateczną ilość czasu pracując nad tematami opisnymi w pozostałej części rozdziału, wyjaśniając i informując wszystkich o swoich zamiarach, wówczas zostanie uczyniony duży krok w kierunku realizacji powyższego celu. Tematyka planowania
Wiele książek na temat testowania zawiera wzór albo przykład planu testowania, który łatwo można zmodyfikować, aby stworzyć na jego podstawie swój własny plan. Wadą tego podejścia jest to, że sprzyja zbytniej koncentracji na dokumencie zamiast na procesie. Bywało że kierownicy testów dużych projektów brali elektroniczny wzorzec dokumentu, spędzali kilka godzin wycinając, kopiując i wklejając, po czym wychodził im „niepowtarzalny” plan dla ich projektu. Mogło się wydawać, że dokonali nie byle czego, konstruując w ciągu paru godzin to, co innym zajęło tygodnie lub miesiące. Tego rodzaju plan pozostawał z reguły z dala od rzeczywistości tak dalece, że często nikt w zespole nie orientował się, co właściwie robili testerzy i dlaczego.
Z tego powodu nie ma w tej książce szablonu planu testowania. Zamiast niego jest lista najważniejszych tematów, które trzeba dokładnie przedyskutować, zrozumieć i ustalić w zespole projektowym - z udziałem testerów. Nie wszystkie pozycje z listy będą adwkwatne do każdego projektu, ale i tak łatwiej będzie ją dopasować do potrzeb projektu niż szczegółowy szablon dokumentu. Z natury rzeczy planowanie jest procesem dynamicznym, tak że dozwolone jest ominięcie tych pozycji listy, które danego projektu nie dotyczą.
W wyniku procesu planowania powstanie oczywiście jakiś rodzaj dokumentu. Jego kształt może byc z góry określony - jeśli branża lub przedsiębiorstwo mają swój standard. Przykładem szablonu do zastosowania jest Standard 829/1983 ANSI/IEEE dla Dokumentacji Testowania Oprogramowania. W przeciwnym razie formę dokumentu projekt może ustalić sam - należy nastawić się na formę najskuteczniejszą aby przekazać innym istotną treść.
Oczekiwania
Tematy, które w pierwszym rzędzie trzeba będzie zaplanować, dotyczą podstawowych aspektów i oczekiwań zespołu testowego. To są rzeczy na tyle kluczowe, że powinien w ich sprawie być zawarty konsensus, ale często zostają przeoczone. Być może robią wrażenie „zbyt oczywistych” i zakłada się, że wszyscy je rozumieją - ale dobry tester nigdy niczego nie powinien zakładać!
5. Jaki jest cel procesu planowania testu i planu testowania? Tester zna powody planowania - OK, czytelnik wkrótce je pozna - ale czy znają je również programiści, autorzy techniczni, kierownictwo? Co ważniejsze, czy zgadzają się na zaplanowany proces testowanoie? 6. Jaki produkt się testuje? Oczywiście, sądziy że to jest „Ginsumatic” v8.0, ale czy na pewno? Czy wersja 8.0 jest tylko niewielką zmianą w ramach pielęgnacji, czy zupełną zianą architektury systemu? Czy jest to pojedynczy produkt czy też skaładający się z tysięcy komponentów. Czy wytwarzany jest w przedsiębiorstwie, czy też przez inną firmę? Aby testowanie zakończło się sukcesem, musi istnieć pełne proozumienie czym jest prokt, jego wielkość i zakres. Opis produktu na podstawie specyfikacji wyagań to dobry początek. Potem móżna sobie sprawić niespodziankę, pokazując opis kilku złonkom zespłu. Niejeden prograista powidzial „Co? Pisany przerze mnie kod tego noie zrobi!”. 7. Jakie są cele jakościowe i niezawodnościowe? Ten temat z reguły powoduje najrozmaitsze reakcje, ale jest istotne by wszyscy zgodzili się na wybrane cele. Sprzedwca oczekuje, że produkt będzie działał jak najszybciej. Programista powie, że chciałby mieć najnowszą technologię. Obsługa powie, że nie nie chce znać żadnych błędów powodujących widoczną awarię. Nie wszyscy moga mieć rację na raz. Jak mierzyć „szykbo” i „fajnie”? I jak powiedzieć kierownikowi produktu, że system będzie ulegał czasem awarii? Zespół testujący będzie testował niezawodność i jakość produktu, tak że trzeba znać swój cel. Skąd inaczej wiedzieć, czy się do niego już doszło?
Wynikiem procesu planowania ma być jasna, zwięzła i zaakcpetowana przez wszystkich definicja celów jakości i niezawodności produktu. Musi być tak sformułowana, żeby nie było żadnych dyskusji, czy rzeczywiście są osiągnięte - lub nie. Jeśli sprzedawcy życzą sobie szybkości, każmy im zdefiniować miarę - na przykład „milion transkacji na sekundę” albo „dwa razy szybciej niż konkurent XYZ wykonujący podobne zadanie”. Jeśli programiści życzą sobie odlotowych technologi, zdefiniujmy dokładnie o co chodzi i pamiętajmy, że zbędna technologia to błąd! Jeśli chodzi o błędy, nie da się zagwarantować, że ich nie będzie - wiemy już że to jest niemożliwe. Można jednak sfromułować cel wyimerny, na przykład że automatyczna „małpa” będzie testować program przez dwadzieścia cztery godziny nie powodując ani jednej awarii, albo że wszystkie zadania testowe będą wykonane bez ani jednego nowego błędu itd1. Bądźmy konkretni. Kiedy zbliża się data wypuszczenia produktu, nie powinno już być żadnych nieporozumień w sprawie kryteriów jakości i niezawodności. Powinny już byc znane wszystkim.
Ludzie, miejsca i rzeczy
Planując testowanie musimy zidentyfikować osoby pracujące w projekcie, ich funkcje i jak się z nimi skontaktować. W małym projekcie może się to wydawać zbędne, ale nawet mały projekt może mieć pracowników rozproszonych z dala jeden od drugiego. Zatrudnieni mogą się także zmieniać, co utrudnia kontrolę nad tym, kto jest za co odpowiedzialny. W duży projekcie mogą istnieć setki połączeń między osobami. Zespoły testowe zwykle muszą współpracować ze szczególnie dużą ilością osób, i dobra orientacja kto jest kto i jak się z każdym skontaktować jest szczególnie ważna. Plan testowania powinien więc zawierać nazwiska, tytuły, adresy, telefony, adresy poczty elektronicznej i zakresy odpowiedzialności wszystkich najważniejszych osób w projekcie2.
Trzeba również określić, gdzie znajduje się dokumentcja (na „której półce” stoi plan testowania), skąd można załadować oprogramowanie, gdzie znajdują się narzędzia do testowania3. Należy wziąć pod uwagę aliasy (nazwy zastępcze) poczty elektronicznej, nazwy serwerów, adresy witryn WWW.
1 Jest to - brutalnie skrótowe - streszcznie możliwych kryteriów uznania testowania za zakończone. To obszerna tematyka, wymagająca w zasadzie osobnego rozdziału (przyp. tłumacza).
2 Po raz kolejny w tej książce trudno się oprzeć wrażenieu, że propozycje autora zmierzają w stronę tego, by kompetentny i zapobiegliwy kierownik testowania kompensował wszelkie braki niezbyt sprawnego kierownika projektu (przyp. tłumacza).
3 Czy to raczej nie wchodzi w zakres zarządzania konfiguracją (przyp. tłumacza)?
Jeśli do przeprowadzenia testów potrzebny jest sprzęt, gdzie się znajduje i jak go dostać? Jeśli zewnętrzne laboratorium ma wykonać testowanie konfiguracji, gdzi się ono mieści i jaki ma haronogram?
Najlepiej streścić tę tematykę jako „wskaźniki do tego wszystkiego, o co zapytałby nowozatrudniony tester”. Może to być dobrym zadaniem dla początkującego testera. Zajdując odpowiedzi na swoje pytania, po prostu się je zapisuje. To, co się znalazło, zapewne więcej osób też chciałoby wiedzieć.
Definicje
Niełatwo skłonić wszystkie osoby należące do zespołu projektowego do tego, by pogodziły się w kwestii definicji celów jakości i niezawodności. Niestety, te pojęcia to dopiero pierwsze z listy licznych pojęć, które projekt wytwarzania oprogramowania musi zdefiniować. Przypomnijmy sobie definicję błędu z rozdziału 1-ego, „Podstawy testowania oprograowania”: 1. Oprogramowanie nie wykonuje czegoś, co wedle specyfikacji powinno wykonywać. 2. Oprogramowanie robi coś, czego wedle specyfikacji powinno nie robić. 3. Oprogramowanie wykonuje coś, o czym specyfkacja w ogóle nie wspomina. 4. Oprogramowanie nie wykonuje czegoś, czego specyfikacja wprawdzie nie wspomina – ale powinna.
Czy każdy członek zespołu zna, rozumie i - co najważniejsze - zgadza się z tą definicją? Czy kierownik projektu zna cele zespołu testowego? Jeśli nie, sposób zakomunikowania tego powinien zostać opisany w planie testowania.
To jeden z najpoważniejszych problemów w zespołach projektowych - nieznajomość definicji podstawoych używanych w projekcie pojęć. Programiści rozumieją jakiś termin w jeden sposób, testerzy w drugi, a kierownik w trzeci sposób. Wyobraźmy sobie zamieszanie wynikające z tego, że prograiści i testerzy rozumieją inaczej pojęcie tak podstawowe, jak to czym jest błąd.
Słownictwo i teminologia używane przez zespół testowy powinno być zdefiniowane w procesie planowanoia testowania. Trzeba zidentyfikować ewentualne różnice i uzgodnić je, żeby wszyscy mogli się ze sobą rozuieć.
Oto lista kilku często spotykanych terminów i ich bardzo ogólnikowe definicje. Lista nie jest pełna, a definicje nie są niepodważalne. Jedne i drugie mogą zależeć od zakresu projektu, rodzaju modelu wytwarzania stosowanego przez zespół, poziomu doświadczenia i kompetencji członków zespołu. Podaje się je tutaj po to, aby zachęcić do zastanowienia się, jakie terminy powinny być w projekcie zdefiniowane i jak jest ważne, by każdy znał ich znaczenie. 8. Połączenie (wersja). Połączenie kodu i danych w całość, którą można testować. Plan testów powinien określać częstotliwośc połączeń (codziennie, raz na tydzień) i ich przewidywaną jakość. 9. Informacja na temat wersji1. Dokument dołączany do każdej nowej wersji (połączenia), określający co jest nowe, zmienione lub naprawione. 10.Wersja alfa. Wczesna wersja przeznaczona do częściowej dystrybucji dla nielicznych wybranych klientów oraz dla celów demonstracji. Nie ma być używana w rzeczywistych sytuacjach. Chcąc używać wersję alfa, trzeba znać dokładnie jej zawartośc i poziom jakości. 11. Wersja beta. Oficjalna wersja przeznczona do dystrybucji do potencjalnych klientów. Pamiętamy z rozdziału 15-ego „Testowanie beta i polowanie na błędy”, że należy zdefiniować cele robienia wersji beta oprogramowania. 12.Zamrożenie specyfikacji. Data w harmonograie, po której specyfikacja ma być kompletna i przestać się zieniać. Kto brał już udział w paru projektach, może podejrzewać, że taka data występuje tylko w baśniach, ale zdecydowanie należy zalecać jej ustalenie - po tej dacie specyfikacja wymagań może już tylko ulegać ograniczonym i ściśle kontrolowanym zianom. 13.Zamrożenie funkcji. Data w haronogramie, po której programiści przestają dodawać do kodu nowe funkcje i koncentrują się wyłącznie na naprawianiu błędów.
1 W książce termin "Test release document". Inne często spotykane angielskie nazwy to "Release information", "Build contents" i inne - prawie każda firma ma własną nazwę (przyp. tłumacza).
14.Komitet błędów1. Grupa złożona z kierownika testów, kierownika projektu oraz kierownika produktu2, spotykająca się raz w tygodniu3 w celu dokonania przeglądu raportów błędów i podjęcia decyzji, które z nich i jak mają byc naprawione. Komitet błędów jest głównym użytkownikiem celów jakości i niezawodnośći, zdefiniowanych w planie testowania.
Podział ddpowiedzialności
Istnieje wiele zewnętrznych okoliczności, wywierających decydujący wpływ na proces testowania. Na prace zespołu testowego wywierają też wpływ inne grupy: programiści, kierownictwo, autorzy tekstów techniczncyh itd. Jeśłi nie zaplanuje się podziału odpowiedzialności, projekt - zwłaszcza testowanie - może stać się komedią chaotycznego przerzucania sobie piłeczki nawzajem, przez co traci się kontrolę i zapoina o ważnych zadaniach do wykonania.
Rodaje zadań, które trzeba zdefiniować, nie zawsze są proste i oczywiste, typu „testerzy testują, programiści programują”. Najprostszym sposobem planowania i zakomunikownaia podziału zadań i odpowiedzialności jest tabela (zob. rysunek 16.1).
Rodzaje zadań i czynności znajdują się w lewej kolumnie, a lista możliwych właścicieli - w pierwszym rzędzie na górze tabeli. Znak „x” oznacza właściciela zadania, a myślnik „-„ wskazuje na rolę wspóluczestnika. Pusty znak oznacza brak bezpośredniego związku.
Doświadczenie ułatwia podjęcie decyzji w sprawie listy ewentualnych zadań. Kilku starszych uczestników projektu może dokonać wstępnej analizy, ale każdy projekt ma nieco inną struktue, inne też niż gdzie indziej zależności międzygrupowe. Można zacząć od wypytywania o minione projekty i o to, co wtedy zostało zaponiane.
Co tesować, czego nie testować
Nie wszystko co wchodzi w skład produktu informatycznego zawsze się tetsuje. Oprogramowanie może zawierać komponenty wypuszczone i przetestowane już wcześniej. Wykorzystuje się też oprogranowanie dostarczone przez inne firmy.
1 Tutaj "bug committee", inne częste nazwy to "change control board", "defect meeting", "trouble report board", "emergency board" (przyp. tłumacza).
2 I często wielu innych osób (przyp. tłumacza).
3 Albo częściej, albo też ziej - zleżnie od fazy projektu, potrzeb i od częstotliwości znajdowania błęów (przyp. tłumacza).

Zadanie
Kierownictwo projektu
Programiści
Test
Autorzy techniczni
Dział sprzedaży
Obsługa produktu
Opisanie wizji produktu --- X Stworzenie listy koponentów x Zawarcie kontraktów i proozumień x --Projektowanie produktu x --- --Główny plan projektu x ---   --- --Specyfikcja produktu x Inspekcja specyfikacji produktu --- --- --- --- --- --Wewnętrzna architektura produktu --- x Konstrukcja i kodowanie x Planowanie testowania x Inspekcja planu testowania --- x --- --- --Test komponentów (modułów) x Test ogólny x Stworzyć listę konfiguracji --- x --- --Testowanie konfiguracji x Zdefiniować pomiary dotyczące osiągów/wydajnośći x --Wykonać testy kontrolne x Testowanie zawartości --- x Test kodu dostarczanego spoza projektu --Zautomatyzować proces wytwarzania nowej wersji x Budowanie i duplikacja dysku x Kontrola jakości x Lista „beta” x --Kontrola nad programem beta x --Przegląd materiałów drukowanych --- --- --- x --- --Definicja wersji do demonstracji --- x Wykonanie wersji do demonstracji --- x Przetestowanie do wersji do demonstracji x Komitet błędów x --- --- --- --Rysunek 16.1 Użycie tabeli do zaplanowania podziału odpowiedzialności
W procesie planowania trzeba zidentyfikować każdy komponent oprogramowania i ustalić, czy będzie się go testowało. Jeśli nie, musi istnieć tego przyczyna. Byłoby klęską, gdyby fragment kodu prześlizgnął się przez proces wytwórczy zupełnie nieprzetestowany - z powodu nieporozumienia.
Fazy testowania
Aby zaplanować różne fazy testowania, zespół testujący musi wziąć pod uwagę stosowany model wytwarzania i zadecydować, jakie fazy, albo etapy testowania muszą byc wykonane w trakcie projektu. W modelu prób i błędów będzie przypuszczalnie tylko jedna faza - testować dopóki ktoś nie zawoła „dość”. W modelu kaskadowym i spiralnym wyodrębnia sie zwykle kilka faz - od badania specyfikacji produktu aż do testowania akceptacyjnego. Tak, planowanie testowania też jest jedną z faz testowania.
Zidentyfikowawszy fazy testowania, zespół testowy powinien zakomunikować swoje rozstrzygnięcia całemu zespołowi projektowemu. Często dzięki temu cały zespół zaczyna lepiej rozumieć nie tylko test, ale cały model wytwarzania. Dwa bardzo ważne pojęcia związane z fazami testowania to są kryteria wyjścia i kryteria wejścia. Zespół testerów nie może po prostu przyjść do pracy w poniedziałek rano, rzucic okiem na kalendarz i stwierdzić, że oto są w kolejnej fazie. Dla każdej fazy muszą istnieć jednoznacznie zdefiniowane, obiektywne kryteria, pozwalające stwierdzić, że jedna faza się zakończyła, a następna zaczęła. Na przykład można zdefiniować, że etap przeglądu specyfikacji jest zakończony, gdy opublikowany został protokół przeglądu. Etap testowania beta zaczyna się, gdy test akceptacyjny dla wersji beta programu został zakończony bez znalezienia żadnych nowych błędów. Bez sprecyzowanych kryteriów wejścia i wyjścia, testowanie rozpadnie sie na małe, słabo ze sobą powiązane kawałki - podobnie jak w modelu prób i błędów.
Strategia testowania
Określenie faz testowania jest jednym z zadań w czasie formułowania strategii testowania. Strategia testowania opisuje, jak będzie wykonywane testowanie zarówno w całości jak i w każdej fazie z osobna1. Przypomnijmy sobie, czegośmy się dotąd nauczyli o testowaniau oprogramowania. Mając produkt do przetestowania, trzeba między innymi zadecydować, czy skoncentrować się na zastosowaniu technik czarnej czy szklanej skrzynki. Jeśli zastosować obie, kiedy i wobec których komponentów oprogramowania?
1 Często strategia testowania jest podstwą procesu testowania, jest więc wspólna dla wielu różnych proojektów (przyp. tłumacza).
Może być znakomitym pomysłem, żeby część kodu przetestować ręcznie, a część - przy użyciu narzędzi i automatyzacji. Jeśli będą użyte narzędzia, czy trzeba je będzie samemu skonstruować, czy wystarczy zakupić? Jeśli kupić, to które? A może byłoby najefektywniej zlecić testowanie wyspecjalizowanej, niezależnej firmie i pozostawić w projekcie tylko szczątkowy zespół testerów do kontrolowania przebiegu prac i do kontaktów z tą firmą?
Podjęcie decyzji odnośnie strategii to złożone zadanie. Decyzję tę powinni podejmować najbardziej doświadczeni testerzy, ponieważ może ona zaważyć na powodzeniu lub niepowodzeniu całej pracy. Istotne jest ponadto, aby każdy w zespole projektowym rozumiał i zgadzał się z przyjętym rozwiązaniem.
Wymagania dotyczące zasobów
Planowanie zasobów jest procesem definiowania swoich potrzeb. Trzeba wziąć pod uwagę wszystko, co może być potrzebne do testowania przez cały okres projektu. Na przykład: 15.Personel. Ile osób, z jakim doświadczeniem, z jakimi specjalnościami? Czy powinni być zatrudnieni w pełnym wymiarze godzin czy na krótszy okres czasu? 16.Sprzęt. Komputery, sprzęt testowy, drukarki, narzędzia. 17.Powierzchnia biurowa i laboratorium. Gdzie będą się mieścić? Jakie duże, jak urządzone? 18.Oprogramowanie. Programy do przetwarzania tesktu, bazy danych, specjalne narzędzia. Które można kupić, które trzeba zrobić samemu? 19.Firmy specjalistyczne w zakresie testowania. Czy będziey się do nich odwoływać? Przy pomocy jakich kryteriów zostanie dokonany wybór między nimi? Ile kosztują? 20.Różne dostawy: dyski, telefony, manuale, podręczniki. Co jeszcze może sie przydać pod koniec projektu?
Szczegółowe potrzeby zasobów zależą w znacznym stopniu od przedsiębiorstwa, projektu i zespołu, tak że każdy plan testowania musi przeprowadzić szczegółową analizę potrzeb. Często pod koniec projektu niemożliwe okazuje się uzyskanie tego, czego nie uwzględniło się w budżecie od początku, tak że warto wykonać tę prace drobiazgowo.

Zadania dla testerów
Kiedy fazy testowania, strategia i potrzeby są już określone, można tę informację wykorzystać - razem z danymi ze specyfikacji produktu - do określenia zadań dla poszczególnych testerów. Omówiony wcześniej podział miedzygrupowy dotyczył odpowiedzialności za zadania na wyższym poziomie ogólności. Określanie szczegółowych zadań dotyczy poszczególnych testerów. Tabela 16.1 pokazuje przykład - znacznie uproszczony - opisu zadań testrów.
Tabela 16-1  Definicje zadań testrów
Tester Zadanie Olek Formaty znaków: czcionki, rozmiary, kolory, style Sara Układ: punkty, akapity, tabulator, zawijanie wierszy Ludwik Konfiguracja i kompatybilność Jola Interfejs użytkownika: użyteczność, wygląd, dostepność Wanda Dokumentacja: pomoc interakcyjna
Roman Przeciążenie i obciążenie
Rzeczywiste opisy zadań byłyby o wiele bardziej szczegółowe, określając dokładnie zadania poszczególnych testerów tak, żeby na tej podstawie móc konstruować zadania testowe1.
Harmonogram testów
Harmonogram testów zbiera razem wszystkie dotąd zaprezentowane zagadnienia i wprowadza je do harmonogramu projektu. Ta faza często okazuje się krytyczna dla planowania testowania, ponieważ funkcje, które było nietrudno zaprojektować i kodować, okazują się niekiedy bardzo czasochłonne w testowaniu. Przykładem może być progra, który nie wykonuje niemal żadnych wydruków - prócz jednej, rzadko używanej funkcji. Nikt mógł sobie nie zdawać sprawy z wpływu tej funckcji na testownaie, ale może ona oznaczać tygodnie testowania konfiguracji. Harmonogam testowania powienien umożliwić kierownictwu projektu uzupełnienie harmonogramu całego projektu. Zdarza się, że uwzględnienie wymagań harmonogramu testownaia może wpłynąć na zmianę specyfikacji projektu, np. spowodować usunięcie szczególnie czasochłonnych w testowaniu funkcji.
Planując testowanie trzeba koniecznie uwzględnić fakt, że testownaie jest bardzo nierównomiernie rozmieszczone na osi czasowej typowych projektów. Pewna ilość testowania pojawia się na początku projektu w formie przeglądów kodu i specyfikacji, konstruowania narzędzi itd., ale ilość zadań i ilość zaangażowanych w nie osób wzrasta z czasem, osiągając szczyt tuż przed zakończeniem projektu. Rysunek 16.2 pokazuje typowy diagram zasobów projektu testowania.
Skutkie tego spiętrzenia jest wzrastająca zależność testowania od tego, co dzieje się w projekcie wcześniej. Jeśli jakiś składnik produktu zostanie dostarczony z dwutygodniowym opóźnieniem do fazy testowania, która była zaplanowana na trzy tygodnie, co się wtedy stanie? Czy trzytygodniowe testowanie zmieści się w cudowny sposób w jeden tydzień, czy też cały projekt zostanie opóźniony o dwa tygodnie? Ten problem znany jest jako zjadanie harmonogramu.
Miesiące
Zasoby w projekcie XXX
Testerzy
1 Jest to, powiedzmy, dość szczególna forma zarządzania projektem. Tematyka jest wprawdzie poza zakresem książki, ale istnieją bardziej elastyczne formy zarządzania (przyp. tłumacza).
Rysunke 16.2  Ilość testerów w projekcie zwykle wzrasta w kolejnych fazach procesu wytwórczego.
Żeby tego uniknąć, nie należy wstawiać do harmonogramu z góry ustalonych dat, kiedy poszczególne zadania zacznie się i zakończy. Tabela 16.2 jest przykładem harmonogramu, który na pewno doprowadzi do „znikania” czasu przeznaczonego na testowania.
Tabela 16.2  Harmonogram testowania oparty na z góry ustalonych datach
Zadanie Data Gotowy plan testowania 5 III 2001 Gotowe wszystkie zadania testowe 1 VI 2001 Wykonanie testów po raz pierwszy 15 VI 2001 - 1 VIII 2001 Wykonanie testów po raz drugi 15 VIII 2001 - 1 X 2001
Wykonanie testów po raz trzeci 15 X 2001 - 15 XI 2001
Jeśli zamiast stałych dat używać dat względnych, opartych na kryteriach wejścia i wyjścia zdefiniowanych dla poszczególnych faz testowych, wyraźniej widać wtedy, że większość zadań testowych zależy od wcześniejszych dostaw. Wyraźniej widzi się też ile czasu zajmują poszczególne zadania. Przykład takiego planu znajduje się w tabeli 16.3.
Tabela 16.3  Harmonogram testowania oparty na z datach względnych
Zadanie Data rozpoczęcia Trwanie Gotowy plan testowania 7 dni po zamknięciu specyfikacji wyagań 4 tygodnie Gotowe wszystkie zadania testowe Gotowy plan testowania 12 tygodni Wykonanie testów po raz pierwszy Gotowy połączony kod 6 tygodni Wykonanie testów po raz drugi Wersja beta 6 tygodni
Wykonanie testów po raz trzeci Wersja do oficjalnego wypuszczenia
4 tygodnie
Oprogramowanie do tworzenia harmonogramów ułatwia zarządzanie tego typu zależnościami. Kierownik projektu, ponoszący główną odpowiedzialność za haronogram, używa przypuszczalnie takiego programu.
Zadania testowe
Wiemy już co to są zadania testowe - nauczyliśmy się tego wcześniej. W rozdziale 17-ym „Jak pisać zadania testowe i rejestrować ich wyniki” poznamy więcej szczegółów na ten temat. W procesie planowania testowania określona zostaje metodyka generowania i wyboru zadań testowych, sposoby icharchiwizacji oraz zastosowanie i pielęgnacja.
Raporty błędów
W rozdziale 18-ym „Raportowanie wyników” opisane zostaną sposoby opisywania i kontroli znalezionych błędów. Rozstaw możliwości jest duży - od głośnego wołania z pokoju do pokoju, poprzez stosowanie żółtych samoprzylepnych kartek, aż do posłużenia się skomplikowaną bazą danych na składowanie i zarządzanie raportami błędów. Cały ten proces trzeba zaplanowac szczegółowo, tak żeby każdy błąd był pod kontrolą od momentu znalezienia aż do momentu, gdy jest naprawiony i zweryfikowany - i żeby niegdy żadnego się nie udało zgubić!
Pomiary i statystyka
Dokonywanie pomiarów, zbieranie i analiza danych to najlepszy sposób kontrolowania przebiegu projektu i testowania. W szegółach opisujemy je w rozdziale 19-ym „Pomiar sukcesu”. Planując testowanie trzeba szczegółowo zdefiniować, jakie dane będzie się gromadzić, jak podejmować na ich podstawie decyzje, kto będzie odpowiedzialny za zbieranie danych.
Przykłady pożytecznych danych: 21.Ilość znajdowanych codzienie błędów w trakcie trwania projektu 22.Lista błędów do naprawienia 23.Aktualnie otwarte raporty błędów ustawione według ważności 24.Ilość błędów znaleziona przez każdego testera 25.Ilość błędów znalezionych w każdej funkcji albo części programu
Ryzyko
W trakcie planowanie często wykonuje się próbę zidentyfikowania możliwych problemów albo zagrożeń w projekcie - tych, które mają znaczenia z punktu widzenia testowania.
Załóżmy że 10 nowych testerów, których całe doświadczenie w zakresie testowania sprowadza się do lektury tej książki, otrzymuje zlecenie przetestowania oprogramowania nowej elektrowni atomowej. Byłoby to duże ryzyko. Inny przykład - może nikt nie zdaje sobie sprawy, że jakieś nowe oprogramowanie powinno się przetestować z 1500 różnych modemów i harmonogram projektu nie przewiduje na to czasu - też ryzyko.
Testerzy odpowiedzialni są za rozpoznawanie zagrożeń w trakcie planowania i za powiadomienie o nich kierownika testowania albo kierownika projektu. Rozpoznane zagrożenia zostaną wzięte pod uwagę w planie testowania i uwzględnione w harmonogramie. Niektóre zagrożenia zrealizują się, innym uda się zapobiec. Ważne, by zdać sobie z nich sprawę zawczasu, żeby nie pojawiały się w postaci niemiłej niespodzianki pod sam koniec projektu. Podsumowanie
Skonstruowanie planu testowania - nawet dla niewielkiego projektu - to poważne zadanie, do którego nie można zabieać się nonszalancko. Oczywiście, nie jest trudno wypełnić puste rubryki w gotowym szablonie i po paru godzinach móc zacząć drukować nowy plan testowania, ale nie w tym rzecz. Planowanie testowania to zajęcie, w którym powinni uczestniczyć wszyscy testerzy i inne osoby z całego zespołu projektowego. proządne zrobienie tego może zająć tygodnie, a nawet miesiące. Jednak uzyskanie już na początku projektu dobrej orientacji w tym, co, dlaczego i jak będzie się testować powoduje, że wszystko później funkcjonuje o wiele sprawniej, niż gdy planowanie zrobi się na odczepne.
Początkujący tester - jaki zapewne jest wielu czytelników tej książki - przypuszczalnie nie otrzyma zadania skonstruowania planu testowania. Warto jednak być przygotowanym na to, by móc dostarczyć potrzebne dane kierownikowi zespołu testującego lub menedżerowi testowania. Każdy jest odpowiedzialny za jakiś fragment całokształtu testowania i cząstkowe harmonogramy, lokalne zagrożenia i indywidualne potrzeby łączą się w całość, zwaną głównym planem testowania. 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.Po co jest plan testowania? 2.Dlaczego istotny jest proces planowania, a nie sam plan? 3.Dlaczego zdefiniowanie celów jakości i niezawodności oprogramowania jest ważną częścią planowania testowania? 4.Co to są kryteria wejścia i kryteria wyjścia? 5.Wymień kilka typowych rodzajów zasobów potrzebnych do testowania, które bierze się pod uwagę podczas planowania.
6.Prawda czy fałsz: harmonogram powinien zawierać dokładne daty, tak żeby nie ulegało żadnej wątpliwości, kiedy dana faza testowania ma sie zacząć i kiedy skończyć.