Przebranżowienie na testera

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ć.

Rozdział 15  Polowanie na błędy i testowanie beta
W TYM ROZDZIALE Nie wszystko da się zauważyć Jak podzielić się testowaniem Testowanie beta Jak zlecić testowanie innej firmie
W rozdziale 14-ym „Automatyzacja i narzędzia do testowania” dowiedzieliśy się, jak technologia w postaci narzędzi pozwala uczynić testowanie skuteczniejszym. Zastosowanie programów do testowania programów jest świetną metodą przyśpieszenia pracy i sposbem na znajdowanie błędów, które trudno byłoby znaleźć inaczej.
Innym sposobem uczynienia pracy testera skuteczniejeszą jest wykorzystanie innych ludzi. Gdyby udało się znaleźć więcej osób - niekoniecznie zawodowych testerów - do testowania, można by znajdować błędy przeoczone przez testerów w projekcie.
Najważniejsze punkty tego rozdziału: 47.Czemu ważne jest wykorzystanie wielu osób do testowania 48.Jak znaleźć ludzi 49.Co to jest testowanie beta i jaką rolę mają w nim testerzy 50.Jak skutecznie zlecić testowanie innej firmie Nie wszystko da się zauważyć
Na rysunku 15.1 znajdują się dwa niemal identyczne obrazki, przedstawiające tę samą scenę. Teraz wyjmujemy timer do jajek, nastawiamy go na minutę i szukamy różnic między obrazkami. Zapisujemy znalezione różnice i kolejność, w jakiej je znajdowaliśmy.
Rysunek 15.1 Ile różnic między obrazkami zdąży się znaleźć w ciągu minuty. Ilustracja za zgodą www.cartoonworks.com.
Teraz dajmy to samo zadanie kilku kolegom i porównajmy uzyskane listy. Okazuje się, że każdy ma trochę inne wyniki. Ile różnic się znalazło, które i w jakiej kolejności -  będzie różne dla różnych osób. Jeśli teraz połączyć te listy i odrzucić duplikaty, otrzyma się pełniejszą listę różnic - ale nawet wtedy nie ma pewności, czy znalezione zostały wszystkie.
Tak samo rzecz się ma z testowaniem oprogramowania. Pracuje się pod presją harmonogramu, znajduje błędy w dostępnym nam czasie, ale jeśli pozwolić poszukać też komuś innemu, znajdzie on przypuszczalnie jeszcze inne błędy. Może to zniechęcać. Można sobie pomyśleć: jak można było - mimo całej ciężkiej pracy - przeoczyć taki oczywisty błąd? Jest to jednak całkiem normalne i jest na to kilka sposobów. 51.Wykorzystanie drugiej pary oczu zapobiega paradoksowi pestycydów. Jak widać na przykładzie eksperymentu z rysunkiem 15.1, ludzie zauważają różne rzeczy. Błędy które z jakiegoś powodu przeoczy jedna osoba, z łatwościa może zuważyć ktoś inny. 52.Tak samo jak różni ludzie zauważają różne rzeczy, rozmaicie też zabierają się za wykonanie tej samej pracy. Tester dokonał starannej analizy specyfikacji i wybrał zadania testowe, ale zawsze ktoś inny może wziąć pod uwagę coś, co mu nie przyszło do głowy - nacisnąć inny klawisz, kliknąc myszą szybciej, uruchomić funkcję w inny sposób. Mamy tu ponownie do czynienia z paradoksem pestycydów. 53.Mając kogoś do pomocy, łatwiej uporać się z nudą. Testowanie tego saego raz po razie, używanie ciągle tych samych funkcji programu szybko staje się monotonne. Nuda powoduje rozproszenie uwagi i można wtedy przeoczyć najbardziej oczywiste błędy. 54.Patrzeć jak ktoś inny zabiera się za rozwiązanie zadania jest świetnym sposobem nauczenia się nowych technik testowania, które potem można dodać do swego repertuaru sposobów.
Łatwo ulec pokusie i chcieć zachować wyłączność oraz całą odpowiedzialność za „swój” kawałek testowanego oprograowania, ale lepiej tego unikać. Pozwalając innym sobie pomóc, mżna wiele zyskać. Jak podzielić się testowaniem
O ile nie pracuje się w bardzo małym projekcie, zapewne kilka osób będzie zajmować się testowaniem. Jest wiele sposobów na to, by więcej niż jedna osoba szukała błędów w tej samej części programu.
Testerzy mogą - na kilka godzin albo na kilka dni - zaienić się swoimi zadaniami. „Ja wykonam twoje testy, a ty wykonaj moje”. Obie strony zyskają dzięki temu dodatkowe, niezależne spojrzenie na testowany produkt lub jego część. Każdy może się też nauczyć nowych sposobów - i dzieki temu wymyslic później nowe zadania testowe. Warto przynajniej znaleźć kogoś, żeby przyjrzał się wybranym przez siebie klasom równoważności i zadaniom testowym. Na podstawie swego doświadczenia ktoś inny może zaproponować dodatkowe obszary do przetestowania.
Zabawnym sposobem podzielenia się pracą przy testowaniu jest „tłuczenie błędów”. Polega to na tym, że na jakiś czas - zwykle na kilka godzin - zawiesza się zwykłe zadania i wszyscy razem biorą udział w „tłuczeniu błędów”. Wybiera się jeden fragment czy aspekt oprogramowania i wszyscy koncentrują się na nim. Wybrać można na przykład obszar, gdzie było szczególnie wiele błędów, żeby sprawdzić czy nic tam więcej się już nie kryje. Albo można wybrać fragment podejrzanie bezbłędny - taki zmasowany atak pozwoli ustalić, czy błędy ukryły się przed zwykłymi testami, czy też ma się do czynienia z rzeczywiście dobrze napisanym fragmentem kodu. Objekt „tłuczenia błędów” można wybierać na podstawie rozmaitych kryteriów, ale wspólnym celem jest zawsze to, by wiele różnych osób jednocześnie szukało błędów w na ty samym terenie.
Sprzyierzeńcem w polowaniu na błędy jest dział wsparcia klientów - ludzie, którzy mają kontakt z klientami potrzebującyi pomocy albo instrukcji. Ci ludzie są bardzo czuli na punkcie błędów i moga naprawdę wiele pomóc przy testowaniu. Warto dowiedzieć się, kto będzie odpowiadał za pomoc klientom i poprosić te osoby o wzięcie udziału w testowaniu. Będą potrafili znaleźć zdumiewające błędy.
Bodaj najczęściej dział obsługi klienta spotyka się z problemami z zakresu użyteczności. Wiele pytań przychodzi od osób, które po prostu usiłują zrozumieć, jak posłużyć się oprogramowanie. Dlatego warto spróbować włączyć osoby z działu obsługi w testowanie jak najwcześniej, żeby wcześnie mogli pomóc znaleźć i naprawić właśnie błędy użyteczności. Testowanie beta
Opisane dotąd metody podzielenia się testowaniem mają charakter wewnętrzny - to znaczy osoby, które nam pomagają, należą do tego samego zespołu testującego albo do tego samego projektu. Inną powszechnie stosowaną metodą walidacji i weryfikacji oprogramowania przy pomocy innych osób jest tak zwane testowanie beta.
Testowanie beta polega na tym, że oprogramowanie jest testowane przez wybranych klientów (lub potencjalnych klientów) w rzeczywistym, operacyjnym środowisku. Testowanie beta zwykle stosuje się pod koniec projektu i właściwie powinno być wyłącznie walidacją tego, że oprogramowanie jest już zupełnie gotowe do dostarczenia klientom.
Cele testowania beta mogą być rozmaite: począwszy od tego, żeby spowodować pojawienie się w fachowej prasie wczesnych artykułów na temat tego oprogramowania, poprzez walidację interfejsu użytkownika, aż po ostatni atak w poszukiwaniu błędów. Tester powinien umieć zakomunikować osobom kierującym testami beta, jaki jest - z jego punktu widzenia - ich cel.
Następujące rzeczy warto wziąć pod uwagę planując testowanie beta: 55.Kim są osoby wykonujące testowanie beta? Jest to ważne w kontekście przyjętego celu testowania. Na przykład producent może być zainteresowany znalezieniem pozostałych jeszcze problemów z użytecznością, ale testerami beta okazują się być doświadczeni programiści, bardziej zainteresowani działaniem na niskim poziomie, nie zaś użytecznością. Jeśli tesowanie beta ma przynieść spodziewane korzyści, trzeba z góry określić, kto powinien je wykonywać. 56.Skąd będzie wiadomo, czy wykonawcy testów beta rzeczywiście używali rorgramu? Jeśli 1000 osób miało program do dyspozycji przez miesiąc i nie raportowało żadnych problemów, czy to znaczy że nie było żadnych błędów, czy też że błędy znajdowano ale nikt nie potrudził się napisaniem raportu, czy też że raporty zostały zagubione na poczcie? Często się zdarza, że osoby mające wykonać testowaniue beta przystępują do tego dopiero po pewnym czasie, a ponadto wykonują je tylko w ograniczonym zakresie. Trzeba dopatrzeć, by mieć nad ty wszystkim kontrolę. 57.Testowanie beta często jest dobrym sposobem znajdowania błędów konfiguracji i kompatybilności. Jak dowiedzieliśy się w rozdziałach 8-ym „Testowanie konfiguracji” i w 9-ym „Testowanie kompatybilności”, trudno jest zidentyfikować i przetestować reprezentatywną próbę możliwych układów sprzętu i programów. Jeśli uczestnicy testów beta zostali trafnie wybrani z grupy potencjalnych klientów, powinni znaleźć wiele problemów dotyczących właśnie konfiguracji i kompatybilności.
58.Testowanie beta może też dać interesujące wyniki w zakresie testowania użyteczności, jeśli właściwie wybrało się jego uczestników - odpowiednią mieszanke osób o różnym poziomie doświadczenia. Widząc oprogramowanie po raz pierwszy, będą mogli bez trudu zauważyć wszelkie mylące czy trudne do zastosowania funkcje. 59.Oprócz konfiguracji, kompatybilności i użyteczności, testowanie beta jest zdumiewająco nieefektywne w znajdowaniu błędów. Uczestnicy często nie mają dość czasu na używanie programu, tak że znajdują tylko najbardziej oczywiste, powierzchowne problemy - przypuszczalnie i tak są już one znane wytwórcy. Poza tym, ponieważ testowanie beta zwykle odbywa się pod koniec cyklu wytwarzania, nie ma zbyt wiele czasu na naprawianie znajdowanych błędów.
Jednym z największych zagrożeń w projekcie wytwarzania oprogramowania jest próba potraktowania testowania beta jako namiastki prawdziwcyh testów. Nie wolno tego robić!  Jeśli to miałoby zadziałać, czemu nie zrobić tego samego również z projektowaniem i implementacją oprogramowania? 60.Program testowania beta zajmuje dużo czasu. Często początkujący testerzy otrzymują właśnie za zadanie pomaganie klintom w ich problemach, odpowiadanie na ich pytania i potwierdzanie znalezionych przez nich błędów. Wykonując takie zadanie, trzeba też współpracować z resztą zespołu testującego, aby zrozumieć, dlaczego błędy nie zostały znalezione wczesniej i zaplanować poprawienie zadań testowych tak, żeby ich nie móc ponownie przeoczyć w przyszłości. To wszystko łatwo wypełnia cały czas pracy, tak że nie zostaje go już na testowanie samemu.
Planując program testowania beta, należy zaplanować go zawczasu, najlepiej jeszcze w czasie ustalania harmonogramu projektu. Trzeba zadbać o to, by cele testowania beta pokrywały się z potrzebami zespołu testującego i współpracować ścisle z kierownikiem tego programu tak, by głos testerów był brany pod uwagę.
Testowanie beta może być dobry sposobem uzyskania niezależnych wyników testów, ale aby mógł on być skuteczny, trzeba nim opowiednio pokierować - można niemal powiedzieć, że trzeba go odpowiednio… przetestować.
Jak zlecić testowanie innej firmie
Często spotykaną praktyką w wielu firmach jest zlecenie wykonania części testowania przedsiębiorstwom specjalizującym się w różnych aspektach testowania. Chociaż może to się wydawać bardziej skoplikowane i niewygodne niż zlecenie wykonania tej samej pracy testerom we własnym zespole projektowym, jest to zwykle skuteczny sposób podzielenia się odpowiedzialnością za testowanie - jeśli zrobić to z głową.
Zwykle dobrze jest zlecić innnej firmie test konfiguracji i kompatybilności. Ten rodzaj testów wymaga dużego laboratorium z wieloma rozmaitymi platformami sprzętowymi i z różnymi rodzajami oprogramowania, wraz z kilkuosobowym personelem zarządzającym tym wszystkim. Większość małych firm nie może sobie pozwolić na koszty utrzymania takich laboratoriów. Jest sensownym wariantem przekazać takie zadanie firmom specjalizującym się w tego typu testowaniu.
Testowanie ulokalnienia też dobrze nadaje się, by zlecić jego wykonanie komuś innemu. O ile zespół testerów nie jest naprawdę wielki, trudno oczekiwać by mieć do dyspozycji pracowników znających wszelkie języki, w których program ma działać. Może się opłacać mieć w zespole kilku testerów znających obce języki, aby zidentyfikować podstawowe problemy, ale najpewniej lepiej jest powierzyć całość testów przedsiębiorstwu mającemu odpowiednie kompetencje. Takie firmy dysponują zwykle psrsonelem zarówno znającym języki, jak i znającym się na testowaniu.
Początkujący tester zapewne nie będzie musiał podejmować decyzji w sprawie tego, jakie rodzaje testów można powierzyć innej firmie, ale może musieć współpracować z taką firmą, jeśli testuje ona oprogramowanie, za które jest się odpowiedzialnym. Wówczas powodzenie lub niepowodzenie pracy firmy wykonującej testy może zależeć od współpracy z tym właśnie testerem. Oto lista spraw, które trzeba uwzględnić, aby współpraca przebiagała jak najlepiej: 61.Jakie dokładnie zadania zostały powierzone tej firmie? Kto je definiuje? Kto je weryfikuje i zatwierdza? 62.Jaki jest harmonogram ich pracy? Kto go ustala? Jakie będą skutki ewentualnych opóźnień? 63.Jakie dostawy ma otrzymywać firma wykonująca testy? Przykłady to specyfikacja, kolejne dostawy nowych wersji i zadania testowe. 64.Jakie mają być dostawy z firmy testującej do producenta oprogramowania? Co najmniej musi to być lista znalezionych błędów.
65.Jakie będą sposoby porozumiewania się z firmą? Telefon, poczta komputerowa, Internet, wspólna baza danych, codzienna wizyta? Osoby wyznaczone jako odpowiedzialne za współpracę i kontakt z obu stron. 66.Skąd będzie wiadomo czy testująca firma wywiązuje się ze swoich zobowiązań? Skąd firma ma wiedzieć czy spełnia oczekiwania zleceniodawcy?
To wszystko nie jest wprawdzie ścisłą matematyką, ale często te banalne sprawy są zapomniane w pośpiechu, aby jak najszybncie przekazać testowanie wybranej firmie. Postawa, aby jak najszybciej „pozbyć się” programu i zwalić jego testowanie na kogoś innego, to recepta na klęskę. Pod warunkiem jednak właściwego planowania całego przedsięwzięcia, przekazanie części testów innej firmie może być skutecznym sposobem na wykonanie specjalistycznych testów, na których wykonanie samemu nie ma się odpowiednich środków. Podsumowanie
Wnioski jakie należy wynieśc z tego i z poprzedniego rozdziału są takie, że wszelkie środki są dobre, żeby stać się lepszym testerem. W jednej sytuacji trzeba posłużyć się technologią, w innej postarać się o pomoc innych ludzi, jeszcze inna wymaga brutalnej siły - testowania ręcznego. Każda sytuacja jest inna i przy każdej można sie czegoś nowego nauczyć. Trzeba eksperymentować, próbować różnych podejść, obserwować jak robią inni - i cały czas mieć na uwadze skutecznośc testowania i prawdopodobieństwo znajdowania błędów.
Ten rozdział zamyka część książki poświęconą sposobom wykonywania testowania. To była dobra zabawa. Poznaliśmy proces wytwarzania oprogramowania, podstawowe techniki testowania, jak je stosować, jak je wspomagać. W części V-ej "Praca z dokumentacją" zobaczymy, jak to wszystko czego nauczyliśmy się dotąd połączyć w całość: jak zaplanować i zorganizować testowanie, jak zapisywać i śledzić znajdowane błędy, i jak mieć pewność, że zostaną odpowiednio naprawione. 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.Opisz paradoks pestycydów i w jaki sposób zaangażowanie nowych osób w testowanie może mu zapobiec. 2.Jakie są możliwe korzyści programu testowania beta? 3.Z czym należy zachować ostrożność planując testowanie beta? 4.Jeśli pracuje się w małym przedsiębiorstwie robiącym oprogramowanie, czy warto przekazać test konfiguracji innej fimie?