Blog

Testowanie oprogramowania to jedna z ciekawszych dziedzin we współczesnej informatyce. W teorii każda osoba techniczna wie, czym są testy. Często nawet wie, jak je wykonać. Niemniej jeśli zapytać o podstawowe zasady obowiązujące w testowaniu, to niewiele osób potrafi wymienić choćby jedną. O tych zasadach traktuje ten artykuł.

W wielu dziedzinach naszego życia staramy się zobaczyć pewne wzorce, schematy i prawdy. Nic w tym dziwnego. Nasz mózg działa w dużej mierze jak maszyna asocjacyjna (skojarzeniowa). Zatem występowanie powtarzalnych zjawisk (jak obrót ziemi wokół własnej osi) po prostu nazywamy (np. dniem). W przypadku uniwersalnych wzorców, schematów czy prawd o testowaniu oprogramowania mówimy o 7 zasadach. Brzmi to mądrze i takie jest. Jednak nie oznacza to, że są to zasady tajemne i trudne w zrozumieniu, szczególnie gdy dobrze je nakreślimy.

By zrozumieć faktyczny stan nauki, jaką jest informatyka, pozwolę sobie zacytować jednego z ojców dzisiejszej informatyki Donalda Knutha:

People think that computer science is the art of geniuses but the actual reality is the opposite, just many people doing things that build on each other, like a wall of mini stones.

Co w luźnym tłumaczeniu brzmi:

Ludzie myślą, że informatyka jest sztuką geniuszy, podczas gdy w rzeczywistości jest zupełnie na odwrót, po prostu wielu ludzi buduje na pracy innych, jak mur z wielu małych kamieni.

Analogię tę, jednak z większym patosem, przybliża nam utwór Juliusza Słowackiego „Testament mój”, z którego zaczerpnięto tytuł pięknej i trudnej, powieści „Kamienie na szaniec”. W tym momencie warto zadać sobie pytanie, dlaczego o tym w ogóle piszę?

Tematyka tego artykułu prawdopodobnie trafi do wielu początkujących testerów, a sam temat jest jednym z najważniejszych i stosunkowo prostych w testowaniu oprogramowania. Dlatego chciałbym dodać otuchy i życzyć czytelnikom, by swoją postawą mogli nawiązać do fragmentu wyżej wspomnianego wiersza:

Lecz zaklinam: niech żywi nie tracą nadziei
I przed narodem niosą oświaty kaganiec

Nie przedłużając, pozwolę sobie omówić 7 zasad testowania oprogramowania zgodnie z najnowszym syllabusem ISTQB^®.

Zasada 1. Testowanie ujawnia obecność defektów, a nie ich brak

Oznacza to, że w procesie testowania oprogramowania znalezione błędy wskazują na istnienie defektów (często potocznie, nie do końca poprawnie, nazywanych bugami od ang. bug. Termin bug zawdzięczamy jednej z pionierek informatyki Grace Hooper. Znalazła ona bowiem wraz ze swoim współpracownikiem ćmę, która powodowała przepięcie jednego z układów w komputerze Mark II), a nie na ich zupełny brak. Testowanie zmniejsza jedynie prawdopodobieństwo ich wystąpienia. Przetestowanie oprogramowania nie dowodem na jego poprawność, gdyż mogą istnieć błędy, które nie zostały w procesie testowania wykryte.

Zasada 2. Testowanie wyczerpujące (ang. exhaustive testing ) jest niemożliwe

Nie licząc trywialnych przypadków, przetestowanie programu ze wszystkimi możliwymi wejściami/warunkami jest po prostu niemożliwe. Wyobraźmy sobie taką funkcję jak wyliczanie odległości między dwoma punktami. Funkcja taka przyjmuje parametry: x1,x2,y1,y2. Odejmuje odpowiednie parametry od siebie, następnie podnosi je do kwadratu i dodaje, by finalnie wyciągnąć pierwiastek kwadratowy. Załóżmy, że:

• x1,x2,y1,y2 są 64-bitowymi liczbami (nie wchodzimy w sposób zapisu i interpretacje wartości)
• posiadamy zewnętrzną maszynę, która zawsze wskaże poprawny wynik operacji
• dzisiejsze komputery mają średnie taktowanie (optymistyczny wariant) procesora na poziomie 5 GHz
• funkcja ta zajmie dosłownie 1 takt procesora, a maszyna zewnętrznie porównująca, czy wynik jest poprawny, od razu zwraca wynik.

Mamy więc (2^64)*4 czyli (2^66) operacji do przetestowania. Można zmniejszyć ich ilość, zauważając, że część danych jest trywialna (np. x1=x2). Na dodatek część operacji (y1=n1 y2=n2 i y1=n2 y2=n1) jest redundantna. Niemniej nie będzie to wtedy jednak testowanie wyczerpujące.

Dzieląc ilość operacji przez ilość wykonywanych testów na sekundę (5*10^9 – tyle ile wynosi taktowanie procesora), następnie przez 60 (sekundy), 60 (minuty) i 24 (godziny), dostaniemy:

>>> (2**66)/(5*10**9)/(60*60*24)
170803L
>>> (2**66)/(5*10**9)/(60*60*24)/365
467L

Do przetestowania tak trywialnej funkcji potrzebujemy w bardzo optymistycznym wariancie (wysokie taktowanie, operacja trwa dosłownie jeden cykl procesora) 467 lat. Nie muszę chyba tłumaczyć dalej, dlaczego bardziej zaawansowane funkcje i programy ze swojej natury nie mogą być gruntownie (inna nazwa na testowanie wyczerpujące) testowane.

Zasada 3. Wczesne testowanie oszczędza czas i pieniądze

Sama zasada jest dość oczywista – znalezienie błędu we wczesnych etapach jest po prostu tanie. Dlatego ważne jest, by proces testowania został rozpoczęty jak najwcześniej to możliwe. Wczesne testowanie pozwala uniknąć wprowadzania kosztowych zmian w projekcie na późniejszych etapach jego życia.

Jednym z moich ulubionych artykułów na ten temat jest materiał przygotowany przez NASA, biorący pod uwagę wiele prawdziwych projektów tworzących oprogramowanie oraz specjalistyczny sprzęt – Error Cost Escalation Through the Project Life Cycle. Zgodnie z nim, w najgorszym przypadku naprawa błędu na etapie wdrożenia rozwiązania i jego utrzymania może być nawet 1500 razy droższa niż wykrycie go podczas zbierania wymagań.

Zasada 4. Defekty gromadzą się (klastrują) razem

Większość błędów w projekcie z reguły znajduje się w niewielkiej ilości modułów. Znalezienie błędu w module daje duże prawdopodobieństwo znalezienia wielu innych błędów w jego sąsiedztwie. Jest to też istotne przy analizie ryzyka i szacowaniu, którym modułom należy poświęcić więcej szeroko rozumianej pracy. Część badaczy wskazuje występowanie zasady Pareto, gdzie 20% modułów odpowiada za 80% błędów.

Zasada 5. Paradoks pestycydów

Pestycydy są środkami mającymi za zadanie wyeliminować pewną grupę organizmów szkodliwych. Wraz ze stosowaniem pestycydów w sposób naturalny występuje uodpornianie populacji organizmów na ich działanie. Podobnie działają antybiotyki – czego dowodem jest występowanie antybiotykoodpornych bakterii np. gruźlicy.

Tak samo testy mają za zadanie wykryć, a następnie wyeliminowanie defekty. W przypadku testowania błędy/defekty w kodzie stają się odporne na niezmieniane testy. Testy z czasem tracą swoją skuteczność w wykrywaniu defektów, należy więc na bieżąco je aktualizować i tworzyć nowe. Można to porównać do zmiany (proporcji i składu) mieszanki, którą spryskiwane jest pole uprawne w celu wyeliminowania „bugów”.

Zasada 6. Testowanie zależy od kontekstu

Inaczej testuje się poszczególne komponenty systemu na etapie ich integracji, a inaczej np. pojedynczą funkcję. Testowanie zależy także od metodyki wytwarzania oprogramowania (Inżynieria oprogramowania – część I. Kilka słów o metodykach) oraz od tego, co wytwarzamy. W inny sposób testuje się np. portal kliencki, a inaczej oprogramowanie rakiety kosmicznej. Nie bez powodu istnieje wiele specjalizacji w testowaniu oprogramowania, jak np. tester oprogramowania wbudowanego, tester aplikacji webowych czy tester automatyzujący.

Zasada 7. Przekonanie o braku błędów jest błędnym mniemaniem

Jest to jeden z błędów postrzegania oprogramowania występujący z reguły u osób nietechnicznych, jak np. project manager czy CEO. Oczekują one często, że tester będzie w stanie przeprowadzić wszystkie przypadki testowe (jest to niewykonalne – patrz zasada 2.) i że program nie będzie zawierał żadnych błędów (jest to niewykonalne – patrz zasada 1.). Rozliczanie osób testujących tylko z ilości wykrytych błędów jest z góry skazane na niepowodzenie – brak lub niewielka ilość wykrytych błędów (ponownie zgodnie z zasadą pierwszą) nie oznacza bowiem, że system jest gotowy do wdrożenia. Obowiązuje to także w drugą stronę, wykrycie dużej ilości błędów może/nie musi oznaczać zapewnienia odpowiedniej jakości kodu.

Na dodatek nawet najlepiej przetestowane oprogramowanie wciąż może nie spełniać oczekiwań klienta, być trudne w użyciu lub po prostu działać niezgodnie z przeznaczeniem (ale zgodnie z założeniami!).

Co dalej?

Znając już 7 zasad mówiących o testowaniu oprogramowania, polecam wszystkim osobom zainteresowanym przestudiowanie sylabusa ISTQB – znajduje się tam wiedza skumulowana w pigułce.

W najbliższym czasie na naszym blogu pojawi się więcej artykułów dotyczących testowania wraz z bardziej technicznymi przykładami. Jeśli spodobał Wam się ten artykuł, zachęcam do zapisu na nasz newsletter oraz do dzielenia się swoimi opiniami w komentarzach.