Rozdział 17

Rozdział 17  Jak pisać zadania testowe i rejestrować ich wyniki
W TYM ROZDZIALE Cele planowania zadań testowych Przegląd planowania zadań testowych Organizacja i zarządzanie zadaniami testowymi
W rozdziale 16-ym „Planowanie testowania” poznaliśmy proces planowania i konstruowania planu testowania dla projektu. Informacje znajdujące się w tym planie są niezbędzne, ale na zbyt wysoki poziomie i zbyt abstrakcyjne, aby bezpośrednio kierować codzienną praca poszczególnych testerów.
Następny poziom w planowaniu testowania - konstruowanie zadań testowych - wpływa wprost na to, co wykonują testerzy. Początkujący tester zwykle tylko wykonuje zadania testowe skonstruowane i opisane przez kogoś innnego, ale wkrótce zaczyna się samemu pisać zadania testowe. W tym rozdziale dowiemy się, jak skutecznie wytwarzać i zarządzać zadaniami testowymi tak, aby swoja pracę testera wykonywać maksymalnie skutecznie.
Najważniejsze punkty w tym rozdziale: 26.Znaczenie konstruowania i zarządzania zadaniami testowymi 27.Co to jest specyfikacja projektu testów 28.Co to jest specyfikacja zadania testowego 29.Jak pisze się procedurę testową 30.Jak zorganizować zadania testowe Cele planowania zadań testowych
W początkowych rozdziałach tej książki była mowa o różnych modelach wytwarzania oprogramowania i jak różne techniki testowe dają się zastosować, by w tych modelach móc realizować skuteczne testowanie. W modelach skokowym i prób i błędów, testerzy są na łasce i niełasce projektu, często muszą domyślać się, co mają testować i czy znajdowane anomalie to rzeczywiście błędy? Przy zastosowaniau bardziej sformalizowanych modeli wytwarzania testowanie staje się nieco łatwiejsze, ponieważ ma się do dyspozycji dokumentację, taką jak specyfikacja wymagań i specyfikcaja architektury. Tworzenie oprogramowania - projektowanie, architektura i programowanie - stają się prawdziwym procesem, a nie tylko chaotyczną gonitwą, żeby produkt jak najszybciej wepchnąć użytkownikowi. W takim środowisku testowanie staje sie o wiele bardziej skuteczne i przewidywalne.
Dobrze zorganizowany projekt jest korzystny dla wszystkich, nie tylko dla testerów. Wiemy już, że programista, który natychmiast zaczyna produkować kod na podstawie specyfikacji wyagań, nie sporządziwszy wprzódy planu konstrukcji i nie poddawszy jej przeglądowi, przypuszczlanie narobi więcej szkody niż korzyści. Podobnie, tester konstruujący zadania testowe na podstawie tylko planu testowania, zapewne nie osiągnie zachwycających wyników. Jeśli testerzy oczekują od innych zdyscyplinowania, powinni sami świecić dobrym przykładem.
Satranne i metodyczne planowanie zadań testowych jest krokiem we właściwym kierunku. Jest ono istotne z czterech powodów: 31.Organizacja. Nawet w niewielki projekcie mogą istnieć tysiące zadań testowych, skonstruowanych przez kilku różnych testerów w ciągu kilku miesięcy czy nawet lat. Właściwie zaplanowana organizacja pozwoli innym korzystać z nich wygodnie i skutecznie. 32.Powtarzalność. Jak już wiemy, w trakcie projektu niejednokrotnie trzeba te same zadania testowe powtarzać więcej niż raz, szukając nowych błędów i sprawdzając, czy błędy znalezione wcześniej zpostały dobrze naprawione. Bez odpowiedzniego planowania, nie dałoby sie stwierdzić, które zadania rzeczywiście zostały wykonane i w jaki sposób, tak żeby móc je powtórzyć dokładnie tak sao. 33.Zarządzanie. W trakcie projektu trzeba umieć odpowiedzieć na kilka ważnych pytań. Ile zadań testowych planowało się wykonać? Ile zostało wykonanych na ostatniej wersji programu? Ile przeszło, a ile zawiodło? Ilu zadań nie wykonano? I tak dalej. Nie zaplanowawszy odpowiedznio układu zadań testowych, nie da się na te pytania udzielicć sensownych odpowiedzi. 34.Dowód przeprowadzenia testów. Przy wytwarzaniu systemów krytycznych ze względu na bezpieczeństwo, często trzeba móc udowodnić, że naprawdeę wykonało się wszystkie zaplanowane zadania testowe. Niezgodne z prawem - i niebezpieczne - jest wówczas wypuszczenie oporogramowania, na którym nie wszystkie zaplanowane testy zostały wykonane. Właściwie zaplanowane zadania testowe i rejestracja ich wyników pozwala udowowdnić, co się naprawdę przetestowało.
Nie należy mieszać planowania zadań testowych z ich identyfikacją, o której nauczyliśmy się w części II-iej „Podstawy testowania”. Tamte rozdziały uczyły nas, jak testować i jak wybierać zadania testowe, podobnie jak programistów uczy się programowania w danym języku. Planowanie zadań testowych jest kolejnym krokiem, podobnym do tego, kiedy prograista uczy się, jak projektować architekturę wyższego rzędu i jak poprawnie udokumentowac swoją pracę. Testowanie ad hoc Tak zwane testowanie ad hoc polega na ty, że oprogramowanie testuje się bez planu - nie ma się żadnych zadań testowych ani nawet planu testowania, tylko tester zasiada przed komputerem i zaczyna walić w klawisze. Niektórzy mają do tego wrodzony talent i szybko zaczynają znajdować błędy. Robi to zwykle wrażenie i może być cennym uzupełnieniem planowanych testów - na przykład w czasie zmasowanego „ataku na błędy” - ale nie jest zorganizowane, nie daje sie powtórzyć, nie daje się nim zarządzać, a kiedy jest zakończone, nie ma żadnego dowodu, że rzeczywiście zostało zrobione. Tak jak tester woli unikać oprogramowania, które powstało metodami ad hoc, tak klienci nie chcą mieć do czynienia z oprogramowaniem, które w sposób ad hoc zostało przetestowane. Przegląd planowania zadań testowych
Jak więc właściwie planowanie zadań testowych mieści się w wielkim planie testowania? Rysunek 17.1 pokazuje zależności między różnymi typami planów.
Plan Testowania
Specyfikacja Projektu Testów
Plan Testowania Plan Testowania Specyfikacja Zadań Testowych
Plan Testowania Plan Testowania Specyfikacja Procedur Testowych
Specyfikacja Projektu Testów Rosnąca rola procesu tworzenia planu
Rosnąca rola pisemnego planu
Rysunek 17.1 Planowanie testowania na rożnych poziomach jest ze soba ściśle powiązane. Różnica polega na tym, czy najważniejszy jest sam plan, czy też proces jego konstruowania.
Wiemy już, że w przypadku planu testowania na poziomie projektu ważniejszy jest proces planowania niż sam pisany dokumnet. Następne trzy poziomy: specyfikacja projektu testów, specyfikacja zadań testowych i specyfikacja procedur testowych, opisane są w dlaszych częściach tego rozdziału.
Jak widać na rysunku 17.1, im niżej schodzi w hierarchii tych dokumentów, tym ważniejszy staje się sam napisany dokumnet, a mniej ważny proces jego konstruowania. Te dokumenty bowiem - zwłaszcza specyfikacja zadań testowych i specyfikacja procedur testowych - używane są cały czas przez testerów wykonujących zadania testowe. Jak się dowiemy, na najniższym poziomie specyfikacja staje się szczegółową instrukcją jak - krok po kroku - wykonać zadanie testowe, przez co szczególnej wagi nabieraja dobra organizacja, przejrzystość i zwięzłość materiału, a mniej ważne jest, jakimi sposobami udało się to osiągnąć.
Treść tego rozdziału opiera się na Standardzie Dokumentacji Testu Oprogramowania1 ANSI/IEEE Std 829-1983 (dostępny pod http://standards.ieee.org). Wiele zespołów testowych dostosowało swoją dokumentację testowania do niego - świadomie lub nie - ponieważ ten standard stanowi logiczną i zdroworozsądkową zarazem medodę planowania testowania. Należy zdawać sobie sprawę, że o ile nie jest się zobligowanym do ścisłego przestrzegania tego standardu przez oficjalną politykę swego przedsiębiorstwa lub gałęzi przemysłu, należy posługiwać się nim raczej jako zbiorem dobrych rad niż jak szczegółowym standardem. Zarówno jego treść jak i proponowane w nim metody są dziś równie aktualne jak w 1983, kiedy standard powstał. Jednak to, co niegdyś najlepiej było przedstawić w formie pisanego dokumentu, dziś często lepiej i skuteczniej jest zrealizować w postaci arkusza kalkulacyjunego albo bazy danych. Przykłady takich sytuacji znajdują się w dalszej części tego rozdziału.
Podsumuwując, plan testowania dla zespołu testującego powinien obejmować pałny zakres planu testowania wg ANSI/IEEE 829. Jeśli najlepsze są dla kogoś papierowe wydruki (choć trudno w to uwierzyć), nichże je stosuje. Jeśli ktoś jest zdania, że najlepsza będzie centralna baza danych, a zespół dysponuje czasem i budżetem, by ją stworzyć samemu albo zakupić, nic nie stoi na przeszkodzie. Ważne jest tylko, by zakończywszy pracę, osiągnąć cztery główne cele planowania zadań testowych: organizację, powtarzalność, kontrolę i dowodzenie poprawności.
Grupy  zadań testowych2
1 Standard for Software Test Documentation (przyp. tłumacza).
2 Autor dzieli - zgodnie ze standardem - opis zadań testowych na trzy poziomy: grupy zadań testowych (test design), zadania testowe (test cases) oraz procedury testowe (test procedures). W rzeczywistości
Plan testowania pisze się na bardzo ogólnym poziomie. Dzieli się w nim oprogramowanie na poszczególne funkcje i elementy dające się przetestować, ale nie wyszczególnia jak będzie się je testować. Być może określi się zastosowanie automatyzacji, testowania czarnej skrzynki lub szkalnej skrzynki, ale plan nie wchodzi w szczegóły, gdzie i jak te metody zastosować. Kolejny poziom szczegółowości, opisujący sposób testowania poszczególnych funkcji i elementów, to specyfikacja grup zadań testowych (projekt konstrukcji zadań testowych), której poświęcony jest ten podrozdział.
ANSI/IEEE 829 stwierdza, że specyfikacja grup zadań testowych „opisuje bardziej szczegółowo metody [opisane w planie testowania] oraz identyfikuje funkcje, które należy uwzględnić przy tworzeniu konstrukcji testów1. Ponadto określa się zadania i procedurey testowe, o ile są wymagane, konieczne do osiągnięcia celu testowania, oraz kryteria zaliczenia/niezaliczenia.”
Celem tej specyfikacji jest zorganizowanie i opisanie testowania, które musi być wykonane na danej funkcji. Nie zawiera ona jednak szczegółowych zadań testowych ani opisu poszczególnych kroków koniecznych do wykonania zadania testowego. Następujące elementy - zaadaptowane ze standardu ANSI/IEEE 829 - powinny wchodzić w skład tej specyfikacji: 35.Identyfikatory. Unikalny identyfikator daje możliwość referowania do specyfikacji. W specyfikacji powinny znajdować się referencje do ogólnego planu testowania i do wszelkich innych wykorzystanych planów i specyfikacji. 36.Funkcje do przetestowania. Opis funkcji oprogramowania, której dotyczy ta specyfikacja, na przykład „funkcja dodawania Kalkulatora”, „wybór i wyświetlenie wielkości czcionki w WordPad”, „test konfiguracji karty wideo w QuickTime”.
cześciej spotyka się podział dwupoziomowy: zadania testowe (co jest testowane) opisane w specyfikacji testowania (test specification) oraz procedury testowe - zwane też często instrukcjami testowymi - (jak wykonać zadanie testowe). W wielu przedsiębiorstwach nawet te dwa poziomy zlewają się w jeden ("co" i "jak" opisane wspólnie w jednym dokumencie). Dodatkowo komplikuje sprawę fakt, że dla wygody i szybkości wykonywania zadań testowych zwykle opłaca się łączyć je w długie ciągi, obejmujące wiele zadań testowych (np. w ramach jednej procedury wpisać, usunąć i dokonać ponownej próby usunięcia osoby z bazy danych - trzy różne zadania testowe). Przyp. tłumacza.
1 Co to jest "test" standard nie wyjaśnia - to brak konsekwencji i spójności typowy dla wielu międzynarodowych i branżowych standardów (przyp. tłumacza).

W tej części wylicza się też funkcje, które zostaną przetestowane jako efekt uboczny podczas testowania głównej funkcji. Na przyklad: „choć nie wchodzi to w zakres niniejszego planu, interfejs użytkownika okna dialogowego otwierania plików zostanie przetestowany w trakcie testowania funkcji ładowania i zapisywania”. Wymienia się też funkcje których się nie przetestuje, lecz o których można by fałszywie sądzic że będą przetestowane przy okazji testowania głównej funkcji. Na przykład: „testowanie funkcji dodawania Kalkulatora zostanie wykonane automatycznie przy pomocy programu wysyłającego dane o naciśniętych klawiszach wprost do aplikacji, nie zostanie więc wykonane żadne pośrednie testowanie interfejsu użytkownika. Testowanie interfejsu użytkownika opisane jest w innej grupie zadań testowych”. 37.Metody. Ogólny opis metody zastosowanej do przetestowania danej funkcji. Opis metody - często zawarty już w planie testowania - zostaje tutaj pogłębiony, technika szczegółowo zdefiniowana, a sposób weryfikacji poprawności wyników określony.

Na przykład: „Zostanie sporządzone narzędzie do sekwencyjnego ładowania i zapisywania przygotowanych wcześniej plików różnych rozmiarów. Ilość plików z danymi, ich rozmiary oraz rodzaj danych zostaną określone przy pomocy technik czarnej skrzynki i uzupełnione przykładami uzyskanymi metodą szkalnej skrzynki, przygotowanymi przez programistów. Weryfikacja wyników testów będzie wykonana poprzez proównanie (na poziomie pojedynczych bitów) zapisanego pliku z oryginałem, przy użyciu narzędzia do proównywania plików”. 38.Identyfikację zadań testowych. Lista i zwięzłe definicje zadań testowych użytych do przetestowania danej funkcji. Należy okreśłić użyte klasy równoważności i podać referencje do zadań, które je testują. Na przykład: Sprawdzenie najwyższej możliwej wartości - Zadanie testowe nr 10 Sprawdzenie najniższej możliwej wartości - Zadanie testowe nr 11 Sprawdzenie kilku różnych potęg dwójki - Zadanie testowe nr 12 Nie należy w tym miejscu określać dokładnie stosowanych wartości. Dla celów inspekcji specyfikacji pod kątem pokrycia testowego, o wiele istotniejsze jest podanie klas równoważności niż konkretnych wartości użytych do ich przetestowania.
39.Kryteria zaliczenia/niezaliczenia. Określa się dokładnie jakie są warunki pozytywnej i negatywnej weryfikacji testowanej funkcji. Niekiedy jest to proste - funkcję uznaje się za działającą poprawnie, jeśli wszystkie zadania testowe zostaną wykonane bez znalezienia błędu. Czasem jest niejednoznaczne - np. funkcję weryfikuje się negatywnie, jeśli niezaliczonych zostało poad 10% zadań testowych. Nie powinny jednak istnieć żadne wątpliwości co do samego sformułowania kryterium. Tak, awaria systemu to błąd Pracowałem kiedyś w projekcie, gdzie test konfiguracyjny aplikacji multimedialnej został przekazany wyspecjalizowanej firmie. Nie była to najlepsza firma, ale jedyna dostępna w tym momencie. Żeby mieć pewność że wszystko zostanie wykonane zgodnie z zasadami sztuki, przekazano testującej firmie specyfikacje grup zadań testowych, specyfikacje zadań testowych i procedury testowe - w ten sposób nie powinno było być żadnych wątpliwości, co zostało, a co nie zostało przetestowane. Minęło kilka tygodni i wszystko zdawało się przebiegać gładko - zbyt gładko - kiedy pewnego dnia zatalefonował kierownik zespołu testującego. Złożył raport na temat tego, co znaleziono w ciągu tygodnia - nie było tego wiele -  i tuż przed odłożeniem słuchawki zapytał, czy ma również raportować błędy nie uwzględnione w dokumentacji. Okazało się, że od pierwszego dnia jego testerzy od czasu do czasu spotykali się z tymi dużymi, białymi komunikatami mówiącymi coś na temat „błędu ochrony pamięci”. Komunikaty te lekceważono, ale po jakimś czasie ekran komputera stawał się jaskrawoniebieski z kolejnym niezrozumiałym meldunkiem o błędzie, co już wymagało ponownego wystartowania maszyny. Ponieważ taki błąd nie był wymieniony jako kryterium niepowodzenia zadania testowego, kierownik zespołu nie był pewien, czy było to ważne i postanowił się upewnić1.
Zadania testowe
W rozdziałach od 4-ego do 7-ego opisane zostały podstway testowania oprogramowania - analizowanie specyfikacji, kodu źródłowego i całej aplikacji po to, by móc wygenerować minimalną ilość zadań testowych, które umożliwiają skuteczne przetestowanie tego oprogramowania. Nie omawiano jednak kwestii, jak najlepiej opisać i udokumentować wybrane zadania testowe. Kto zajmował się już testowaniem, zetknął się przypuszczalnie z rozmaitytmi sposobami i formatami zapisu. Ta część książki pozwoli zpoznać się bliżej z różnymi możliwośćiami.
1 Sarkazm autora jest trochę nie na miejscu - to, że tester czy automatyczny program testujący zignoruje nieprzewidziane skutki uboczne zadania testowego, jest zjawiskiem często spotykanym. Zapobieganiu mu służy zespół technik testowania zwany analizą dynamiczną (przyp. tłumacza).
ANSI/IEEE 829 definiuje, że specyfikacja zadań testowych „dokumentuje faktyczne wartości użyte jako dane wejściowe wraz z oczekiwanymi wartościami danych wyjściowych. Opis zadania testowego określa także ograniczenia dotyczące procedury testowej wynikające z zastosowania tego właśnie zadania testowego”.
Szczegóły opisu zadania testowego powinny więc wyjaśniać dokładnie, jakie wartości lub warunki wprowadzane są do testowanego oprogramowania i jakiego należy spodziewać się wyniku1. Standard ANSI/IEEE 829 wylicza także niektóre inne ważne pozycje, które powinny się w tym opisie znaleźć: 40.Identyfikatory. Jednoznaczny identyfikator, do którego odnośniki znajdują się zarówno w specyfikacji grup zadań testowych, jak i w specyfikacji procedur testowych. 41.Przedmiot testu. Opisana tu jest w szczegółach funkcja, moduł, czy inny przedmiot testu. Ten opis jest dokładniejszy niż w listach funkcji znajdujących się w specyfikacji grup zadań testowych. Gdy na przykłąd specyfikacja grupy zadań testowych określiła testowaną funkcję jako „dodawanie na Kalkulatorze”, to specyfikacja zadania testowego określi na przykład „test górnej granicy w procedurze obsługi przepełnienia”. Powinny się tutaj też znaleźć odnośniki do specyfikacji produktu lub innych specyfikacji, na podstawie której stworzone zostało to zadanie testowe. 42.Specyfikacja danych wejściowych2. Określa się tu wszelkie dane wejściowe i inne warunki zapoczątkowujące wykonanie zadania testowego. Jeśli testuje się Kalkulator, te dane mogą być tak proste jak na przykład 1+1. Kiedy testuje się oprogramowanie centrali do telefonii komórkowej, ma się do czynienia z setkami i tysiącami warunków wejściowych. Kiedy testuje się aplikację do obsługi plików, danymi wejściowymi mogą byc np. nazwa pliku oraz jego zawartość.
1 Autor bez wątpienia się tu bez wszelkiej potrzeby powtarza - tłumacz prosi o wybaczenia, ale taki jest często styl amaerykańskich książek…
2 Autor zdaje się - przypuszczalnie dla uproszczenia - utożsamiać dane wejściowe z czynnościami uruchamiającymi zadanie testowe, zaś dane wyjściowe - z wynikiem zadania testowego. Tak jest bardzo często, ale na pewno nie zawsze: na przykład wynikiem zadania testowego może być zmiana stanu programu, zmiana danych w rejestrze lub bazie danych, a nawet to, że żadna dająca się zaobserwować zmiana nie następuje! (przyp. tłumacza).
43.Specyfikacja danych wyjściowych. Jest to opis oczekiwanyego wyniku wykonania zadania testowego. Czy 1+1 dało wynik równy 2? Czy tysiące danych wyjściowych otrzymało prawidłowe wartości w aplikacji obsługi centrali? Czy zawartość pliku została prawidłowo załadowana? 44.Definicja wymagań środowiska. Wymagania środowiska to sprzęt, oprogramowanie, narzędzia do testowania, warunki, personel itd. potrzebne do wykonannia zadania testowego. 45.Szczególne wymagania proceduralne. Tutaj opisuje się wszystkie odbiegające od normy wymagania, które muszą być spełnione, aby móc wykonać zadanie testowe. Testowanie programu WordPad pewnie niczego takiego nie wymaga, ale testowanie elektrowni atomowej - przypuszczalnie tak. 46.Zależności pomiędzy zadaniami testowymi. W rozdziale 1-ym „Podstawy Testowania” znajdował się opis błędu, który spowodował katastrofę lądownika NASA na Marsie. Jest to doskonały przykład nieudokumentowanej zależności między zadaniami testowymi. Jeśli jedno zadanie zależy od drugiego albo może podlegać wpływom jeszcze innego zadania testowego, tę informację należy tutaj umieścić.
Czy już wpadamy w panikę? Jeśli ściśle przestrzegać opisanych tu zasad dokumentowania zadań testowych, to trzeba by było pisać co najmniej stronę tekstu do każdego zadania testowego! Tysiące zadań testowych wymagałyby tysięcy stron specyfikacji. Projekt byłby opóźniony zanim jeszcze skończyłoby się ją pisać.
Oto jeszcze jeden powód, dla którego standard ANSI/IEEE 829 należy traktować jako wskazówkę raczej niż przestrzegać go w 100 procentach - o ile się nie musi. Wielel projektów rządowych i niektóre gałęzie przemysłu muszą dokumentować zadania testowe aż w tym stopniu, ale zwykle można sobie pozwolić na uproszczenia.
Uproszczenia i skróty nie mają oznaczać, że odrzuca się lub pomija istotną informację, a jedynie że usiłuje się znaleźć bardziej skuteczne metody przekazywania tej informacji. Na przykład, nie istnieje żaden powód, żeby ograniczać się do specyfikowania zadań testowych w formie opiosowej. Rysunek 17.2 pokazuje przykład macierzy do testowania kompatybilności drukarki.

Identyfikator zadania testowego
Producent drukarki
Model Tryb pracy Opcje

Czarno-biały … Kolorowy … Wysoka rozdzielczość Średnia rozdzielczość Niska rozdzielczość
Tekst Superfoto Automatyczny Roboczy Tekstowy …
Rysunek 17.2  Zadania testowe często można opisać przy pomocy maacierzy lub tabeli.
Każda linia macierzy jest zadaniem testowym mającym własny identyfikator. Pozostała informacja - przedmiot testu, specyfikacja danych wejściowych, specyfikacja danych wyjściowych, wymagania środowiska, specjalne wymagania i zależności - jest przypuszczalnie jednakowa dla wszystkich wymienionych zadań i może być opisana dla nich wspólnie gdzieś indziej. Dokonując przyglądu specyfikacji można najpierw przeczytać i skontrolować tę wspólną informację, a następnie łatwo przejrzeć tabelę pod kątem pokrycia testowego.
Inne możłiwe sposoby opisywania zadań testowych to listy albo nawet diagramy graficzne takie jak diagram stanów programu albo diagram przepływu danych. Chodzi o to, by przekazać komu innemu opis zadania testowego i wybiera się najskuteczniejszy sposób. Warto być pomysłowym i twórczym, pamiętając jednak, że głównym celem jest udokumentowanie zadań testowych.
Procedury testowe
Udokumentowawszy grupy zadań testowych i zadania testowe, pozostaje jeszcze opisanie procedur, według których zadania testowe będą wykonywane. ANSI/IEEE 829 stwierdza, że specyfikacja procedur testowych „identyfikuje wszystkie kroki niezbędne do sterowania systemem i wykonania określonych zadań testowych w celu urzeczywistnienia grupy zadań testowych.”
Procedura tesotwa albo skrypt testowy definiuje kroki określające w szczegółach jak wykonać zadanie testowe. Oto znajdująca się w niej informacja: 47.Identyfikator. Unikalny identyfikator, łączący procedurę z odpowiednim zadaniem testowym i z grupą zadań testowych. 48.Cel. Cel procedury i odnośniki do zadań testowych, które realizuje. 49.Specjalne wymagania. Inne procedury, specjalne umiejętności testerów, albo specjalny sprzęt potrzebny do wykonania procedury. 50.Kroki procedury. Szczegółowy opis jak wykonywać test: − Log. Opis w jaki sposób będzie się nagrywać i zapisywać wyniki i inne obserwacje. − Przygotowanie. Wyjaśnienie jak przygotować test. − Start. Wyjaśnia jakie kroki potrzeben są by zacząć wykonywanie testu.
− Procedura. Opis kroków w trakcie wykonywania testu. − Pomiar. Wyjaśnienie, jak uzyska się wyniki zadań - na przykład przy pomocy stopera albo obserwacji wizualnej. − Zatrzymanie. Wyjaśnienie, jak czasowo zawiesić wykonywanie testu. − Ponowny start. Wyjaśnienie dla testera w jaki sposób ponownioe podjąć wykonywanie zadania w określonym miejscu, jeśli przyczyną zawieszenia była awaria lub zawieszenie się całego systemu. − Zakończenie. Opisuje kroki jak w kontrolowany sposób zakończyć test. − Odtworzenie warunków. Wyjaśnia jak doprowadzić środowisko do stanu poprzedzającego wykonywanie testu. − Nieprzewidziane wypadki. Wyjaśnia co robić, kiedy coś dzieje się niezgodnie z planem.
Nie wystarczy, by procedura testowa brzmiała na przykład: „Prosze wykonać następujące zadania testowe i napisać w raporcie co się stało…” Byłóby to proste i łatwe do napisania, ale nie mówiłoby testerowi nic o tym, jak wykonywać samo testowanie. Taka instrukcja nie byłaby powtarzalna i nie byłoby żadnego sposobu udowodnienia, które kroki zostały w rzeczywistości wykonane. Używając szczegółowej procedury wie się dokładnie, co i jak będzie testowane. Rysunek 17.3 pokazuje fragment fikcyjnego przykładu procedury testowania dla Kalkulatora Windows.
Realistyczny poziom szczegółowości
Stare powiedzenie „najlepszy jest złoty środek” stosuje się w zupełności do planowania zadań testowych. Pamiętajmy o czterech podstawowych celach: organizacji, powtarzalności, kontroli i uzyskaniu dowodów. Tester produkujący zadania testowe działa z grubsza w kierunku osiągnięcia tych celów, ale ich poziom określają wymagania branżowe, przedsięborstwa, projektu lub nawet zespołu. Zwykle tester nie musi dokumentować swoich zadań testowych na bardzo szczegółowym poziomie, ale też względnie rzadko ląduje się w bałaganiarskim projekcie, gdzie w ogóle niczego nie trzeba dokumentować. Zwykle praca testera znajduje się gdzieś między tymi dwiema wartościami brzegowymi.
Sztuką jest utrafić we właściwy poziom. Przypatrzmy się procedurze pokazanej na rysunku 17.3, która wymaga, że na PC musi być zainstalowany system Windows 98. Procedura wprawdzie stwierdza w części wstępnej, że potrzebne jest Windows 98, ale nie precyzuje jaka wersja. Co się stanie za rok lub dwa, kiedy pojawi się kolejna wersja Windows 98? Czy procedurę trzeba będzie zmienić, by uwzględnić tę zmianę? Aby uniknąć tego kłopotu, można pominąć numer wersji i użyć określenia „najnowsza”, ale co począć, gdy nowa wersja pojawi się w trakcie cyklu produkcyjnego? Czy należy wówczas zmienić używaną do testowania wersję w trakcie projektu?
Identyfikator: WinCalcProc98. 1872
Cel: procedura opisuje kroki, które należy wykonać aby uruchomić zadania testowe funkcji Dodawanie, od numeru WinCalc98.0051 do WinCalc98.0185.
Specjalne wymagania: Nie jest potrzebny żaden sprzęt ani oprogramowanie prócz tego, które okreśłone jest w opisie samych zadań testowych.
Kroki procedury:
Log: Tester posłuży się aplikacją WordPad z szablonem Testowanie do notowania przebiegu wykonania procedury. Wszystkie pola zaznaczone jako obowiązkowe muszą być wypełnione. System do rejestracji i śledzenia błędów Mantis służy do rejestracji wszelkich problemów, które zaistnieją w trakcie wykonywania procedury.
Ustawienie: Tester musi zainstalować czystą kopię Windows 98 na swojej maszynie przed wykonaniem procedury. Przed zainstalowaniem najnowszej wersji Windows 98 należy posłużyć się aplikacjami WipeDisk i Clone. Więcej wiadomości na temakt posługiwania się tymi narzędziami można znaleźć w dokumencie „Zaczynając od nowa”.
Start: Wystartować Windows 98 Kliknąć przycisk Start Wybrać Programy Wybrać Akcesoria Wybrać Kalkulator.
Procedura: Dla każdego z podanych wyżej zadań testowych, należy wprowadzić dane przy użyciu klawaitury (nie klawiszy numerycznyych widocznych na ekranie) i proównać wynik z oczekiwanym.
Pomiar: …
Rysunek 17.3  Przykład (fikcyjny) procedury testowej pokazuje ilość szczegółów, które trzeba uwzględnić.
Inna kwestia to zalecenie procedury, aby zainstalować „czystą kopię” Windows 98. Co to oznacza? Procedura wymienia kilka narzędzi, WipeDisk i Clone, którymi należy posłużyć się w trakcie czynności poprzedzających test, i odsyła testera do innego dokumentu po wyjaśnienia jak się nimi posłużyć. Czy kroki procedury nie powinny być bardziej szczegółowe i wyjaśnić, gdzie dokładnie znajduje się ten dokument i te narzędzia? Kto kiedykolwiek instalował system operacyjny, wie również, że jest to skomplikowany proces i  że instalator musi odpowiedzieć na wiele pytań i wybrać wiele możliwych opcji. Czy ta albo inna procedura testowa powinna wchodzić w tego typu szczegóły? Jeśli nie, to skąd będzie można wiedzieć, na jakiej dokładnie konfiguracji wykonano testy. Jeśli tak, a proces instalacji kiedyś ulegnie zmianie, może to oznaczać konieczność poprawienia stetek innych procedur testowych. Co za zamieszanie!
Niestety nie istnieje jedna, poprawna odpowiedź. Bardzo szczegółowe specyfikacje testów redukują niejednoznaczność, powodują że zadania testowe są powtarzalne i pozwalają doświadczonym testerom wykonywać je dokładnie zgodnie z opisem. Z drugiej strony, tak dokładny opis wymaga czasu i wysiłku, utrudnia zmiany oraz - z przyczyny tej całej masy szczegółów - hamuje testowanie, powodując że wymaga ono więcej czasu.
Piszać zadania testowe najlepiej dostosować się do standardów projektu, w którym się pracuje. Testując nowy sprzęt medyczny, będzie się przypuszczalnie pisać o wiele bardziej szczegółowe procedury niż przy testowaniu nowych gier komputerowych. Jeśli ma się za zadanie ustalenie metodyki i rekomendacji sposobu opisywania grup zadań testowych, zadań testowych i procedur testowych dla nowego projektu, najlepiej wziąć pod uwagę formaty zdefiniowane przez ANSI/IEEE 829, wypróbować kilka przykładów i stwierdzić, co najlepiej pasuje do zespołu i do wymagań projektu. Organizacja i zarządzanie zadaniami testowymi
Pisząc dokumentację trzeba brać pod uwagę, w jaki sposób informacja jest zorganizowana i jak będzie ją można znajdować. Oto przykłady pytań na które tester - albo zespół tesowy - powinien umieć odpowiedzieć: 51.Które zadania testowe będą wykonane? 52.Ile zadań planuje się wykonać? Ile czasu to zajmie? 53.Czy jest się w stanie wybrać grupy zadań testowych dostosowane do testowania wybranej funkcji albo części systemu? 54.Czy będzie się w stanie zanotować, które zadania zostały zaliczone, a które nie, podczas ich wykonywania?
55.Spośród zadań które nie zostały zaliczone, ile nie zostało zaliczonych również podczas wcześniejszych prób? 56.Jaki procent zadań testowych zostało zaliczonych poprzednim razem?
To są przykłady ważnych pytań, które często spotyka sie w trakcie typowego projektu. W rozdziale 19-ym „Pomiar sukcesu” zajmiemy się zbieraniem danych i statystki dokładniej, ale w tej chwili uznajmy po prostu że potrzebny jest jakiś proces pozwalający na kontrolę zadań testowych i rejestrację ich wyników. Istnieją cztery opdstwaowe typy systemów: 57.W głowie. Nie powinno się tego nawet brać pod uwagę nawet w najprostszych projektach, chyba że testuje się oprogramowanie do własnego prywatnego użytku i nie ma sie żadnego powodu dokładnego śledzenia przebiegu testowania. 58.Papier/dokumenty. W małych projektach możliwe jest zarządzanie zadaniami testowymi wyłącznie na papierze. Służyły do tego niejednokrotnie zupełnie dobrze tabele i listy kontrolne. Jest to oczywiście metoda słaba z punktu widzenia organizowania i poszukiwania danych, ale ma jedną cechę dodatnią: lista kontrolna na papierze zawiera zwykle sygnaturę albo podpis testera, co w razie potrzeby stanowi doskonały dowód w sądzie, że testy faktycznie zostały wykonane. 59.Arkusz kalkulacyjny. Popularną i bardzo dobrze działającą metodą organizowania zadań testowych jest umieszczenie ich w arkuszu kalkulacyjnym. Na rysunku 17.4 znajduje się przykład zastosowania tej metody. Dzieki temu, że wszystkie dane na temat zadań testowych zgromadzone sa w jednym miejscu, arkusz kalkulacyjny pozwala na skuteczną i szybka ocenę statusu testowania. Łatwo sie go używa, względnie łatwo konstruuje, a przede wszystkim przy jego pomocy można zupełnie dobrze organizować i kontrolować zadania testowe oraz rejestrować ich wyniki.

Rysunak 17.4  Do organizacji i zarządzania zadaniami testowymi można używać arkuszy kalkulacyjnych. 60.Baza danych. Najlepsza metodą organizacji zadań testowych jest baza danych skonstruowana specjalnie pod tym kątem. Wiele dostępnych na rynku narzędzi jest skonfigurowanych waśnie pod w ten sposób. Korzystając z dołączeń opisanych w rozdziale 21-ym „Kariera dla testera”, można zapoznać się z wieloma takimi narzędziami i z rekomnedacjami od innych testerów. Kto chce zbudować własny system, może z łątwością posłużyć się narzędziami takimi jak Claris FileMaker Pro, Microsoft Acees, i wiel innych, pozwalającymi niemal bez programowania - tylko przy użyciu myszki - w ciągu kilku godzin stworzyć bazę danych dopasowaną do formatu dokumentacji ANSI/IEEE 829. Posługując się wbudowanymi w bazę danych metodami wyszukiwania różnych kombinachji danych, jest się w stanie bezzwłocznie odpowiedzieć na prawie każde niemal możliwe pytanie dotyczące zadań testowych i przebiegu testowania.
Trzeba zdawać sobie sprawę, że zadań testowych mogą być tysiące i bez sposobu kontrolowania ich można bardzo łatwo utonąć w morzu dokumentacji. Trzeba znaleźć metodę na to, by jednym rzutem oka móc uzyskać odpowiedź na pytanie: „Co będziemy testowali jutro, ile zadań testowych trzeba będzie wykonać?” Podsumowanie
Pora już na to, by ponownie przypomnieć cztery podstawowe powody, dla których konieczne jest staranne planowanie zadań testowych: organizacja, powtarzalność, kontrola i dowody wykonania. Nigdy dość powtarzania tych zasad, bo doświadczenia poucza, że często zaniedbuje się bardzo istotna część pracy testera: szczegółowe dokumentowanie tego, co się zrobiło.
Nikt nie chciałby prowadzić samochodu, który został zaprojektowany przez zespół konstruktorski na odwrocie serwetki, ani mieszkać koło elektrowni atomowej, gdzie programy kontrolne testował zespół posługujący się wyłącznie metodami ad hoc. Chce się, by inżynierowie odpowiedzialni za jakość tych systemów posługiwali się dobrymi praktykami inżynierskimi i tak dokumentowali swą pracę, by dało się stwierdzić, czy to co zbudowano zgodne jest z pierwotnymi planami.
Początkujący tester zwykle nie ma wpływu na to, jakie metody planowania i dokumentacji stosuje projekt, ale może się starać wykonywać swoją pracę jak najskuteczniej. Trzeba odróżniać rzeczy konieczne od zbędznych, badać jak można by usprawnić proces i nigdy nie iść na łatwiznę. Na tym polega różnica między profesjonalizmem a hakerstwem.
Ten rozdział i rozdział 16-y opisuje planowanie i dokumentację tego, co zamierza się przetestować. Następne dwa rozdziały zajmą się tym, jak dokumentować uzyskane wyniki testów i w jaki sposób powiedzieć innym, że znalazło się błąd. 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.Jakie są cztery powody, aby planować zadania testowe? 2.Co to jest test metodami ad hoc? 3.Czemu służy specyfikacja grup zadań testowych? 4.Co to jest specyfikacja zadań testowych? 5.Jakich innych metod - oprócz tradycyjnej formy pisemmnego dokumentu - można używać do opisu zadań testowcyh? 6.Po co jest specyfikacja procedur testowych? 7.Jak szczegółowa powinna być procedura testowa?