rozdział 4

Rozdział 4 Badanie specyfikacji

W TYM ROZDZIALE  Jak zacząć  Ogólny przegląd specyfikacji  Techniki testowania specyfikacji

W tym rozdziale wreszcie zaczniemy uprawiać prawdziwe testowanie – ale może nie tak, jak niektórzy się spodziewają. Nie będzie się instalować ani puszczać żadnych programów, nie będzie się walić w klawiaturę z nadzieją na wywołanie awarii. W tym rozdziale nauczymy się testowania specyfikacji tak, by móc znajdować błędy zanim jeszcze wejdą do programu.

Nie wszyscy testerzy mają kiedykolwiek przywilej testowania specyfikacji produktu. Czasami przychodzi się do projektu w połowie drogi, kiedy specyfikacja jest już napisana i zaczęto pisanie kodu. Nawet wtedy można jeszcze zastosować opisane w tym rozdziale techniki do testowania ostatecznej wersji specyfikacji.

Kto ma szczęście znaleźć się w projekcie dostatecznie wcześnie i mieć dostęp do wstępnej wersji specyfikacji, będzie mieć okazję zastosować wiele opisanych w tym rozdziale technik. Znalezienie błędów w tak wczesnej fazie projektu może zaoszczędzić ogromną ilość czasu i pieniędzy.

Najważniejsze punkty tego rozdziału: 1. Co to są metody „czarnej skrzynki” i „szklanej skrzynki” 2. Różnice między testowaniem dynamicznym i statycznym 3. Jakie techniki są użyteczne do przeglądu specyfikacji produktu 4. Jakich typowych problemów warto szukać przystępując do szczegółowej inspekcji specyfikacji produktu Od czego zacząć

Przypomnijmy sobie cztery modele procesu wytwarzania opisane w rozdziale 2-im: skokowy, prób i błędów, kaskadowy i spiralny. W każdym modelu oprócz skokowego, zespół projektowy przygotowuje specyfikację produktu, zwaną niekiedy specyfikacją wymagań, aby zdefiniować co ma być zrobione.

 Najczęściej specyfikacja produktu to dokument, opisujący przy pomocy słów i ilustracji projektowany produkt1. Fragment specyfikacji Kalkulatora w Windowsach mógłby wyglądać tak:

Pozycja menu Edytuj będzie mieć dwie funkcje: Skopiuj i Wklej. Można je wybierać jedną z trzech metod: wskazując i klikając myszą, używając klawiszy dostępu (Alt-C dla funkcji Kopiuj, Alt-P dla funkcji Wklej), lub posługując się standardowym skrótem Windowsów Ctrl-C dla kopiowania i Ctrl-V dla wklejania.

Funkcja Kopiuj skopiuje bieżącą wartość z okna tekstowego do Schowka Windowsów. Funkcja Wklej wklei zawartość Schowka do numerycznego okna tekstowego.

Rysunek 4.1 Stadardowy kalkulator Windowsów z rozwijanym menu Edytuj.

Jak widać, opis zaledwie dwóch pozycji rozwijanego menu wymagał sporej ilości słów. Szczegółowa specyfikacja całej aplikacji może mieć wieleset stron.

Może wydawać się przesadą sporządzanie tak drobiazgowego opisu dla tak prostego programu. Czemu nie pozwolić po prostu programiście zrobić kalkulator po swojemu? Kłopot w tym, że nie wiedziałoby się wtedy dokładnie, co się w końcu otrzyma. Wyobrażenia programisty jak kalkulator ma wyglądać, jakie ma mieć funkcje i jak użytkownik będzie się nim posługiwać mogą różnić się gruntownie od oczekiwań zleceniodawcy. Jedynym sposobem zagwarantowania, że produkt końcowy będzie taki, jakiego oczekuje użytkownik – co pozwoli także porządnie zaplanować tesotwanie – jest opisanie produktu w specyfikacji wymagań.

Dodatkową zaletą pisanej specyfikacji – i podstawą tego rozdziału – jest to, że tester otrzymuje do dyspozycji dodatkowy przedmiot testowania. Testując specyfikację można czasem wykryć błędy jeszcze zanim zostanie napisana pierwsza linijka kodu.

Metody „czarnej skrzynki” i metody „szklanej skrzynki”

Testerzy dzielą techniki testowania na dwie duże grupy, znane jako test „czarnej skrzynki” i test „szklanej skrzynki”1. Rysunek 4.2 pokazuje różnice między tymi dwoma podejściami. W testowaniu metodami czarnej skrzynki, tester wie jedynie, co oprogramowanie ma zrobić – nie zagląda do „wnętrza skrzynki” żeby zobaczyć jak to działa. Kiedy wprowadzi się pewne dane wejściowe, otrzyma się pewne dane wyjściowe. Nie wiadomo czemu tak jest, tyle tylko, że tak jest.

Wróćmy do przykładu kalkulatora z rysunku 4.1 Jeśli napisać 3.14159 i nacisnąć klawisz „sqrt” (pierwiastek drugiego stopnia), otrzyma się wynik 1.7724531022341. Przy technikach czarnej skrzynki nie bierze się pod uwagę jak działał program aby wyliczyć pierwiastek kwadratowy z pi – po prostu to wykonał. Tester oprogramowania może zweryfikować otrzymany wynik na innym, już sprawdzonym kalkulatorze i skontrolować, czy Kalkulator Windows działa poprawnie.

Rysunek 4.2 Stosując techniki czarnej skrzynki, tester nie zna szczegółów działania programu, który testuje.

Testując technikami szklanej skrzynki, tester ma dostęp do kodu programu i analizuje go w poszukiwaniu wskazówek, które pomogą w testowaniu. Na podstawie tej analizy, tester może określić, jakie liczby mogą z większym prawdopodobieństwem spowodować zły wynik i dostosowuje do tego swoje testowanie.

Z metodami szkalnej skrzynki wiąże się ryzyko stronniczości – zbyt dokładne poznanie kodu może spowodować, że dostosuje się – nawet podświadomie - zadania testowe do kodu tak, by nie spowodowały awarii.

Testowanie statyczne i dynamiczne

Kolejne dwa terminy opisujące sposób testowania oprogramowania to testowanie statyczne i testowanie dynamiczne. Testowanie statyczne dotyczy czegoś, co nie jest wykonywane – np. kodu lub specyfikacji weryfikowanych przy pomocy analizy lub inpspekcji. Testowanie dynamiczne jest tym, co powszechnie uważane jest za testowanie – wykonywaniem i używaniem programu.

Najlepszą analogią dla tych określeń są czynności wykonywane przy sprawdzaniu używanego samochodu. Kopanie w opony, sprawdzanie lakieru, zaglądanie pod maskę – to statyczne techniki  testowania. Włączenie silnika, słuchanie jego pracy i jazda próbna – to dynamiczne techniki testowania.

Test specyfikacji: statyczny test metodą czarnej skrzynki

Testowanie specyfikacji jest statycznym testowaniem metodą czarnej skrzynki1. Specyfikacja jest dokumentem, nie programem do wykonywania, więc uważa się ją za statyczną. Specyfikacja została zbudowana w oparciu o dane z wielu różnych źródeł: badań nad użytecznością, badań preferencji klientów, danych z marketingu. Nie trzeba dokładnie wiedzieć, w jaki sposób wszystkie dane zostały zgromadzone – wystarczy, że zostały spisane w postaci specyfikacji wymagań. Ten dokument można wziąć do ręki, dokonać na nim testowania statycznymi metodami czarnej skrzynki, i uważnie szukać w nim błędów.

Wcześniej widzieliśmy przykład specyfikacji produktu dla Kalkulatora Windowsów. W tym przykładzie posłużono się standardowym pisemnym dokumentem z ilustracją, aby opisać działanie projektowanego oprogramowania. To najpowszechniejsza metoda pisania specyfikacji, ale istnieje wiele różnorodnych wariantów. Zespół projektowy może woleć diagramy niż opisy słowne, albo może posłużyć się samodokumentującym się językiem programowania, jak np. Ada2. Techniki opisane w tym rozdziale można stosować niezależnie od formy dokumentacji. Trzeba je będzie dostosować do formatu specyfikacji, ale istota rzeczy pozostanie bez zmiany.

Co robić jeśli projekt nie ma specyfikacji? Zespół może się przecież posługiwać modelem skokowym lub metodą prób i błędów. Dla testera to trudna sytuacja. Celem jest jak najwcześniejsze znalezienie błędów – najlepiej zanim jeszcze powstanie kod - ale jeśli nie istnieje specyfikacja, wydaje się to niemożliwe. Chociaż jednak nie istnieje pisemna specyfikacja, ktoś – programista, kierownik projektu albo sprzedawca - wie, co się usiłuje zbudować. Można się nimi posłużyc jak chodzącą, mówiącą specyfikacją i zastosować do tej „specyfikacji w głowie” te same techniki testowania co wobec specyfikacji spisanej na papierze1. Można posunąć się nawet jeszcze dalej, nagrywając zgromadzoną informację i rozpowszechniając ją w celu poddania inspekcji. Można wtedy poinformowć zespół projektowy: „Oto na czym zamierzać oprzeć mój plan testów i wobec czego będę kierował raporty błędów.” Będziemy zaskoczeni, jak wiele szczegółów zostanie po tej deklaracji pośpiesznie uzupełnionych.

Specyfikację można testować statycznymi metodami czarnej skrzynki niezależnie od formatu specyfikacji. Może to być dokument pisany albo graficzny, albo mieszany. Nawet niezapisaną specyfikację można testować, wypytując ludzi projektujących i piszących oprogramowanie. Ogólny przegląd specyfikacji

Niełatwo jest zdefiniować produkt informatyczny. Specyfikacja boryka się z wieloma niewiadomymi, oparta jest na zmieniających się danych i usiłuje połączyć je w dokument opisujący nowy produkt. Ten proces nie jest ścisłą nauką i narażony jest na trudności.

Pierwszym krokiem testowania specyfikacji nie jest szukanie konkretnych błędów. Pierwszym krokiem jest spojrzeć na specyfikację z góry, z lotu ptaka niejako. Sprawdza się, czy w dokumencie nie ma dużych, zasadniczych problemów i przeoczeń. Można to określać bardziej jako pracę badawczą niż jako testowanie, ale celem tego badania jest lepsze zrozumienie, co oprogramowanie właściwie ma robić. Rozumiejąc lepiej ukryte za specyfikacją rozmaite „jak” i „czemu”, będzie o wiele łatwiej dokonać szczegółowej analizy później.

Wejście w skórę klienta2

Otrzymawszy pierwszy raz do ręki specyfikację produktu, najlepiej jeśli tester spróbuje się wcielić w klienta/użytkownika. Należy zbadać kim jest klient. Rozmowy z pracownikami działu marketingu i sprzedawcami mogą niejedno ujawnić. Jeśli ma się do czynienia z produktem do użytku wewnętrznego, można znaleźć użytkowników i porozmawiać z nimi.1

Jest ważne, aby dobrze rozumieć oczekiwania klienta. Pamiętajmy definicję jakości, która określa jakość jako „stopień spełnienia potrzeb klienta”. Tester musi rozumieć te potrzeby, aby móc przetestować, czy oprogramowanie je spełnia. Nie oznacza to, że musi się być ekspertem w dziedzinie, gdzie będzie działać oprogramowanie: być specjalistą od techniki nuklearnej testując progamy dla elektrowni atomowej albo zawodowym pilotem testując symulator lotów. Jednak pewna orientacja w dziedzienie działania oprogramowania jest ogromnie przydatna.

Przede wszstkim jednak nie należy niczego robić pochopnych założeń. Jeśli czyta się część specyfikacji której się nie rozumie, nie należy zakładać że jest poprawna. W końcu przecież trzeba będzie na jej podstawie skonstruować swoje testy dynammiczne, więc jakoś trzeba ją będzie zrozumieć. Teraz jest na to najlepszy moment. Jeśli przy okazji znajdzie się błędy w specyfikacji, tym lepiej.

Zbadanie istniejące standardów i zbiorów reguł

W czasach przed powstaniem Windowsów i Macinotsha, prawie każdy produkt informatyczny miał inny interfejs użytkownika. Posługiwano się różnymi kolorami, strukturami menu, nieograniczoną ilością sposobów otwierania plików, tysiącami tajemniczych poleceń dla wykonania tego samego zadania. Przejście z jednego programu na drugi wymagało często ponownego przeszkolenia użytkownika.

Na szczęście nastąpiła znaczna standaryzacja oprogramownaia i sprzętu2. Dokonano także wielu badań nad tym, jak ludzie używają komputerów. Dzięki temu większość obecnych produktów jest względnie jednolitych jeśli chodzi o interfejs użytkownika i sposób posługiwania się nimi, i zostały zaprojektowane zgodznie z zasadami enrgonomii. Można się spierać, że daleko im jeszcze do doskonałości i że istnieją jeszcze lepsze metody, jednak wydajność poprawiła się ogromnie dzięki tej standaryzacji.

Rozdział 11 „Testowanie użyteczności”, zajmie się tymi zagadnieniami dokladniej. Na razie wystarczy pamiętać, że testując specyfikację produktu należy wiedzieć, jakie standardy i zbiory zasad powinna spełniać.

Różnica między standardem a zbiorem zasad dotyczy głównie stopnia. Standard jest bardziej jednoznaczny niż zbiór zasad i należy go ściśle przestrzegać. Zasady – np. branżowe czy wewnętrzne w danym przedsiębiorstwie – powinny ale nie muszą koniecznie być dokładnie przestrzegane.

Istnieje wiele przykładów standardów i zbiorów zasad, które należy barać pod uwagę. Poniższa lista nie jest ostateczna. Należy na własną rękę zbadać, co dotyczy specyfikacji, którą się testuje. 5. Terminologia i konwencje danego przedsiębiorstwa. Jeśli oprogramowanie jest robione specjalnie dla jednej firmy, należy przestrzegać konwencji i stosować nazewnictwo używane przez jej pracowników. 6. Wymagania branżowe. Branże medyczna, farmaceutyczna, przemysłowe i finansowe mają bardzo dokładne standardy branżowe, które oprogramowanie musi spełniać1. 7. Standardy państwowe. Instytucje państwowe, zwłaszcza wojskowe, mają zwykle własne standardy. 8. Graficzny interfejs użytkowanika (GUI). Oprogramowanie pracujące pod systemem Microsoft Windows lub Apple Macinotsh powinno spełniać dostępne, opublikowane standardy dotyczące konstrukcji i sposobu dzialania interfejsu. 9. Stadardzy sprzętowe i sieciowe. Oprogramowanie współpracujące bezpośrenio ze sprzętem komputerowym musi spełniać jego standardy.

Tester nie powinien musieć samemu definiować, jakie standardy stosują się się do danego oprogramowania. To jest zadaniem kierownika projektu czy też osoby, która pisze specyfikację. Tester powinien jednak przeprowadzić własne badania, czy rzeczywiście stosowane są właściwe standardy i czy żaden nie zostal przeoczony2. Powinno się też znać te standardy i móc przetestować, czy samo oprogramowanie je spełnia. Powinno się trakowanć obowiązujące standardy jak część specyfikacji, wobec której wykonuje się test.

Jednym z najlepszych sposobów, żeby zrozumieć czym ma być dany produkt, jest zapoznanie się z innymi, podobnymi programami. Może to być produkt konkurencji albo inny, podobny do tego który wytwarza dany projekt. Prawdopodobnie kierownik projektu albo zespół zajmujący się konstruowaniem specyfikacji wymagań już to zrobił, więc nie powinno być trudno zidnetyfikować i znaleźć taki program. Nie będzie on dokładną kopią budowanego programu (przecież projekt robi coś nowego), ale pozwoli być może zorientować się w stosownycm podejściu i możliwych technikach testowania. Mogą się też ujawnić problemy, których dotąd nie wzięto pod uwagę.

Badając podobne oprogramowanie, warto pamiętać o następujących rzeczach: 10.Wielkość. Czy produkt który będzie się testować jest wiekszy czy mniejszy i czy wpłynie to znacząco na sposoby testowania? 11. Złożoność. Czy produkt który będzie się testować jest bardziej czy mniej złożony i czy wpłynie to na testowanie? 12.Łatwość testowania. Czy będzie się mieć do dyspozycji środki, czas i wiedzę konieczne do przetestowania podobnego produktu? 13.Jakość/niezawodność. Czy badany produkt ma podobną jakość i niezawodność do projektowanego?

Nic nie jest w stanie zastąpić bezpośredniego doświadczenia, więc jeśli tylko da się zdobyć podobne oprogramowanie, warto poświęcić mu sporo czasu. Zdobędzie się w ten sposób doświadczenie, przydatne przy dalszym, szczegółowym testowaniu specyfikacji. Techniki szczegółowego testowania specyfikacji

Uporawszy się z ogólnym przeglądem specyfikacji, rozumie się lepiej produkt i wymagania, które wpływają na jego konstrukcję. Ta wiedza ulatwi testowanie specyfikacji na bardziej szczegółowym poziomie. Pozostała część rozdziału opisuje jak to zrobić1.

Kontrolna lista atrybutów specyfikacji

Dobra, przemyślana i staranna specyfikacja produktu, spełnia osiem ważnych wymagań: 14.Kompletna. Czy czegoś brakuje? Czy jest dokładna? Czy zawiera wszystko, czego potrzeba? 15.Trafna. Czy proponowane rozwiązanie jest prawidłowe? Czy cel jest właściwie zdefiniowany? Czy są jakieś błędy? 16.Dokładna, jednoznaczna, przejrzysta. Czy opis jest ścisły i nie jest mętny? Czy możliwa jest jednoznaczna interpretacja? Czy jest łatwy do zrozumienia? 17.Spójna. Czy opisy cech i funkcji nie są niezgodne i innymi albo sprzeczne wewnętrznie? 18.Istotna. Czy dany opis jest konieczny, czy można go opuścić? Czy dana funkcja daje się wyprowadzić z potrzeb klienta? 19.Wykonalna. Czy funkcję da się zrealizować przy pomocy dostępnego personelu, narzędzi i środków w ramach dostępnego budżetu i harmonogramu? 20.Wolna od szczegółów realizacji. Czy specyfikacja poprzestaje na zdefiniowaniu produktu i nie usiłuje określić konstrukcji, architektury i kodu oprogramowania? 21.Dająca się przetestować. Czy daną funkcję będzie można przetestować? Czy podana informacja jest dostateczna, aby tester mógł na jej podstawie określić poprawność jej działania?

Testując specyfikację, należy wziąć pod uwagę każde z powyższych wymagań i zadać sobie samemu pytanie, czy tekst i rysunki specyfikacji spełniają je. Jeśli nie, mamy do czynienia z błędem, na który należy coś zaradzić.

Kontrolna lista terminologii

Uzupełnieniem listy wymagań z poprzedniego podrozdziału jest lista słów, na które warto zwrócić szczególną uwagę w czasie czytania specyfikacji. Słowa, których brzmienie sugeruje, że mówią o czymś nie do końca przemyślanym, często są sygnałem istnienia błędów specyfikacji, podpadających pod omówioną listę wymagań. Należy ich szukać w czasie czytania i starannie przeanalizować ich kontekst. Specyfikacja albo zawiera precyzyjniejsze wyjaśnienie funkcji, albo poprzestaje na niejednoznaczym określeniu – wówczas mamy do czynienia z błędem specyfikacji, którego szukaliśmy. 22.Zawsze, każdy, wszystkie, żaden, nigdy. Natknąwszy się na takie słowa, oznaczające jednoznaczną pewność, warto sprawdzić, czy rzeczywiście opisane przez nie reguła jest jednoznaczna i pewna. Dobrą metodą takiego sprawdzianu jest próba znalezienia przypadków szczególnych, kiedy takie reguły być może nie obowiązują. 23.Niewątpliwie, dlatego, jasne, oczywiste, niewątpliwe. Te słowa usiłują przekonać czytelnika, żeby coś zaakceptował jako oczywiste. Nie dajmy się złapać w tę pułapkę. 24.Niektóre, czasami, często, zwykle, normalnie, najczęsciej, większość, głównie. Te słowa są zbyt niejednoznaczne. Nie da się przetestować funkcji, która działa „czasami”. 25.Itd., i tak dalej, i temu podobne, takie jak. Wyliczenia zakończone takimi zwrotami nie dają się przetestwoać. Wyliczenia muszą być kompletne albo wyjaśnione tak, żeby nie było wątpliwości w jaki sposób dany ciąg powstaje i co powinno nastąpić na liście w dalszej kolejności. 26.Dobry, szybki, tani, wydajny, mały, stabilny. To są określenia nie dające się wyrazić liczbowo, więc nie dające się przetestować. Jeśli pojawiły się w specyfikacji, muszą być dodatkowo wyjaśnione, żeby było dokładnie wiadomo co właściwie oznaczają. 27.Opracować, przetworzyć, odrzucić, pominąć, wyeliminować. Za tymi określeniami może kryć się skomplikowana funkcja, która powinna być wyspecyfikowana bardziej szczegółowo.

28.Jeśli… To (ale pominięte W przeciwnym razie)1. Warto poszukiwać zdań zawierających wyrażenia „Jeśli… To”, ale pozbawione zamykającego „W przeciwnym razie”. Wtedy trzeba postawić sobie pytanie, co ma się stać, jeśli „w przeciwnym razie” się spełni. Podsumowanie

Po przeczytaniu tego rozdziału można dojść do wniosku, że tesowanie specyfikacji to proces bardzo subiektywny. Przegląd ogólny eliminuje przeoczenia i braki, przegląd szczegółowy pozwala stwierdzić, czy właściwie zdefiniowane zostały wszystkie szczegóły. Jednak te techniki nie stanowią dokładnego procesu, który można realizować krok po kroku – z dwóch przyczyn: 29.Niniejsza książka jest podręcznikiem dla początkujących, którego celem jest szybkie podniesienie umiejętnośći zawodowych testerów. Na to właśnie pozwala zaprezentowany materiał – choć nie opisuje technik szczegółowych, pozwala jednak na całkiem solidne przetestowanie każdego rodzaju pisemnej specyfikacji. 30.Specyfikacje mają bardzo różnorodną formę. Metody opisane w tym rozdziale pozwolą przetestować specyfikację niezależnie od tego, czy znajduje się ona wyłącznie w czyjejś głowie, czy opisana jest w formie wykresów i diagramów, czy zdaniami, które trzeba przeanalizować.

Dla osób zainteresowanych bardziej szczegółowym opisem technik dokonywania przeglądów specyfikacji2, warto zapoznać się z pracami Michaela Fagana. Pracując w IBM-ie, Fagan był pionierem szczegółowego i metodycznego podejścia zwanego inspekcjami oprogramowania. Te metody są dziś stosowane przez wiele przedsiębiorstw3, zwłaszcza wytwarzających oprogramowanie krytyczne dla bezpieczeństwa, w celu dokonywania przeglądu specyfikacji i kodu źródłowego. Więcej informacji na ten temat można znalęźć na stronie www.mfagan.com. Pytania

Pytania mają na celu ułatwienie zrozumienia. W aneksie A „Odpowiedzi do pytań” znajdują się prawidłowe rozwiązania – ale nie należy ściągać! 1. Czy można dokonać testu specyfikacji metodą „szklanej skrzynki”? 2. Podaj kilka przykładów standardów albo reguł dla oprogramowania pod Winowsami albo dla Macintosha. 3. Wyjaśnij, jaki błąd znajduje się w powniższym zdaniu ze specyfikacji wymagań: Wybranie przez użytkownika opcji „Upakuj dane” spowoduje że program zagęści listę danych do najmniejeszej możliwej objętości przy użyciu metody macierzy Hoffmana. 4. Wyjaśnij, czemu testera powinno zaniepokoić poniższe zdanie ze specyfikacji wymagań: Oprogramowanie pozwoli na 100 milionów jednoczesnych połączeń, chociaż zwykle nie będzie stosowanych więcej niż 1 milion połączeń.