Ogólne zasady testowania

 

W środowisku IT zaczyna rodzić się coraz większa świadomość, że testy są niezbędne w cyklu powstawania oprogramowania. Od pewnego czasu testerzy są pełnowartościowymi członkami zespołów wytwarzających oprogramowanie, dlatego też zostały opracowane ogólne zasady testowania.

Głównym celem testowania jest znajdowanie usterek i błędów, a w dalszej perspektywie zapobieganie defektom. Dzięki temu zwiększamy zaufanie do poziomu jakości oprogramowania. Dobre i rzetelne przygotowanie testów skutkuje dostarczeniem informacji, które mogą być bardzo ważne w różnych procesach decyzyjnych.

W zależności od ustalonych celów procesu testowego możemy wyróżnić wiele sposobów testowania. W testowaniu wytwórczym główny cel to wywoływanie jak największej ilości awarii, w testach akceptacyjnych staramy się potwierdzić, że system działa zgodnie z wymaganiami, a w testach pielęgnacyjnych dużą uwagę przykładamy do sprawdzenia, czy wprowadzone zmiany nie wywołują niepożądanego zachowania systemu.

Według sylabusa ISTQB istnieje siedem ogólnych zasad testowania. Poniżej przytaczam je wszystkie, wraz z wyjaśnieniem i przykładami uzupełniającymi.

Testowanie ujawnia usterki

Podczas nauki do egzaminu ISTQB bardzo ważne jest abyśmy umieli wyjaśnić różnice pomiędzy błędem, defektem i awarią. Według sylabusa ISTQB[1] człowiek popełnia błąd (pomyłkę), która powoduje powstanie defektu (usterki) w kodzie programu lub dokumencie. W przypadku, gdy kod zawierający defekt zostaje wykonany, system nie zrobi tego co powinien (lub wykona to co nie powinien) powodując awarię.

Naszym zadaniem jako testerów oprogramowania jest niedopuszczenie do pojawienia się awarii oraz próba znalezienia jak największej ilości błędów i usterek w testowanym systemie. Bardzo ważne jest, abyśmy pamiętali, że jeśli nie diagnozujemy już usterek to nie oznacza, że ich nie ma!

Testowanie gruntowne jest niewykonalne

Pod pojęciem testowania gruntownego rozumiemy: „metodę testowania polegającą na konstrukcji zestawu testów obejmujących wszystkie możliwe kombinacje wejść i warunków wstępnych”.[2]  Należy zapamiętać, że testowanie gruntowne jest niewykonalne. Dlaczego? Najczęściej ze względu na zbyt dużą ilość wariantów danych testowych, zbyt długi czas, ogromne koszty oraz złożoność organizacji i taktyki takiego procesu testowego.

Wyobraźmy sobie, że chcemy przetestować moduł logowania, który składa się z dwóch pól: hasła i loginu. Dla uproszczenia nasze hasło może składać się tylko z zer i jedynek oraz powinno zawierać trzy takie znaki. Możemy wyliczyć, że w przypadku tak prostego hasła już mamy osiem możliwości (000, 001, 010, 011, 100, 101, 110 i 111). A teraz spróbuj policzyć, ile jest możliwych haseł w przypadku, gdy składa się ono minimum z 8 znaków (liter – dużych i małych, cyfr, znaków szczególnych itd.). Jest to astronomiczna liczba, a nadal nie rozpatrzyliśmy jeszcze wariantów loginu. Na podstawie powyższego przykładu możesz zobaczyć, że gruntowne przetestowanie bardzo prostego modułu logowania składało by się z potężnej bazy danych testowych oraz kosztowałoby bardzo dużo czasu i pieniędzy.

Wczesne testowanie

Mówiąc ogólnie im szybciej rozpoczynamy testowanie tym lepiej dla nas, projektu i budżetu. Im wcześniej rozpoczynamy testowanie, tym wcześniej wykrywamy usterki i awarie. Często czas kiedy rozpoczynamy testy uzależniony jest od przyjętej metodyki oprogramowania i świadomości szefa.

W metodykach klasycznych (np. kaskadowych) proces testów zaczyna się późno, bo po procesie implementacji. Aby rozpocząć testy projekt powinien przejść przez następujące etapy: planowania, analizy, projektowania i implementacji. Koszt naprawy znalezionego błędu podczas etapu testowania jest bardzo duży, gdyż oznacza powrót do wcześniejszego stopnia kaskady. W metodykach zwinnych (np. SCRUM) testowanie zaczyna się najszybciej jak to jest tylko możliwe. Dzięki temu koszt naprawy znalezionego błędu jest o wiele niższy niż w metodyce klasycznej.

Podsumowując im wcześniej zaczniemy testowanie, tym mamy większą szansę na znalezienie większej ilości błędów i usterek, a ich naprawa zajmie mniej czasu i będzie mniej kosztowna. Zaufanie do jakości produktu znacząco wzrośnie.

Kumulowanie się błędów

Zazwyczaj błędy nie rozkładają się równomiernie w programie. Często obserwujemy zjawisko kumulowania się błędów w poszczególnych modułach. Najczęściej w literaturze spotykamy się z twierdzeniem, że 80% błędów kumuluje się w 20% kodu. Bardzo ważne jest, aby zdiagnozować, które są to miejsca i od nich rozpocząć proces testowy. Da to nam gwarancję, że zdążymy przetestować najbardziej błędogenne miejsca.

Paradoks pestycydów

Przygotowując się do egzaminu ISTQB możemy spotkać się z pojęciem paradoksu pestycydów. Te same testy, które odpalane są ciągle w kółko uodparniają się na błędy, nie wykrywają też nowych usterek. Utrzymuj testy i przypadki testowe! Projektuj nowe przypadki testowe i dbaj aby istniejące były aktualne.

Paradoks ten w większej ilości przypadków odnosi się do testów wysokopoziomowych, które są przeprowadzanie w fazie testów systemowych i akceptacyjnych.

Testowanie zależy od kontekstu

Bardzo ważne jest też, abyśmy nie testowali „jak automaty”. Podejdźmy z sercem do testowanego programu. Zastanówmy się na co powinniśmy zwrócić największą uwagę (np. bezawaryjność, wydajność), które funkcjonalności są najważniejsze, kluczowe i na nich skupić nasze wysiłki testerskie.

Ważne jest też, abyśmy testowali z kontekstem. Jeśli testujemy system bankowy zadajmy sobie trochę trudu, aby poznać podstawowe informacje na temat bankowości. Bo być może system rzeczywiście zwraca liczbę, ale w rzeczywistości nie powinna to być liczba ujemna? Dobry tester powinien testować system w sposób logiczny i kreatywny, a nie maszynowy!

Mylne przekonanie o braku błędów

Nigdy nie ma takiej sytuacji, w której moglibyśmy powiedzieć, że dany system nie ma już błędów. Nie polecam ryzykować takiego stwierdzenia, gdyż na pewno znajdzie się bardzo ciekawski tester, który znajdzie błąd (często są to błędy bardzo wyrafinowane, które powstają przy bardzo specyficznych danych testowych, ale jednak są!). Często na rozmowach rekrutacyjnych możemy usłyszeć pytanie, czy istnieje taka możliwość, że błędów już nie ma. Wtedy z czystym sercem możemy powiedzieć, że nie ma takiej możliwości i nie możemy dać gwarancji, że znaleźliśmy wszystkie błędy. Zadaniem testera nie jest znalezienie wszystkich błędów (bo to niemożliwe), tylko jak największej ich ilości, tak aby klient mógł bez problemów korzystać z systemu.

Warto przestrzegać ogólnych zasad testowania, gdyż to może uchronić nas przed zbędnymi kosztami, stresem i zmarnowanym czasem. Osobiście dodałabym jeszcze jedną zasadę: Bądź odpowiedzialny za swoje testy, gdyż mogą one mieć ogromny wpływ na życie i zdrowie osób korzystających z systemów, które testowałeś.

 

[1] http://sjsi.org/ist-qb/do-pobrania/

[2] A. Roman, „Testowanie i jakość oprogramowania”