W artykule są wykorzystane materiały z książki "Foundations of Software Testing: ISTQB Certification" autorstwa Dorothy Graham, Erika van Veenendaal, Isabel Evans & Rexa Blacka. O 7 zasadach testowania często się dyskutuje, ale w większości przypadków dość krótko. Niesamowita książka pod redakcją Dorothy Graham bardzo szczegółowo wyjaśnia te podstawowe zasady.

Zasada 1. Testowanie ujawnia obecność defektów

Testowanie może wykazać, że defekty są obecne, ale nie może dowieść, że defektów nie ma.

Z zasady trudno udowodnić, że coś nie istnieje. Bez względu na to, ile białych łabędzi widzimy, nie możemy powiedzieć, że wszystkie łabędzie są białe. Jednak jeżeli zobaczymy chociaż jednego czarnego łabędzia, możemy powiedzieć, że nie wszystkie łabędzie są białe.

Tak samo bez względu na to, ile pomyślnych testów wykonamy, nie możemy twierdzić, że nie ma innych testów, które by znalazły pluskwę. Gdy tylko znajdziemy chociaż jedną pluskwę, możemy powiedzieć, że dane oprogramowanie ma defekty.

Jednak nie oznacza to wcale, że testowanie nie ma sensu i nie może podnieść poziomu naszej pewności jakości kodu. Testowanie zmniejsza prawdopodobieństwo niewykrytych defektów oprogramowania, jednak nawet jeżeli żadnych defektów nie wykryto, nie jest to dowodem ich braku.

Zasada 2. Testowanie gruntowne nie jest możliwe

Zasada ta jest związana z pytaniem: "Ile trzeba testować?"

Jakie w ogóle są odpowiedzi na to pytanie? Możemy przetestować wszystko, nic nie testować albo przetestować część oprogramowania. Idealnie wygląda odpowiedź "przetestować wszystko", ale trzeba się zastanowić czy musimy, a nawet możemy to zrobić.

Ile testów trzeba przeprowadzić, aby przetestować jednocyfrowe pole numeryczne w całości? Zależy od tego, co się rozumie pod "całością". Istnieje 10 możliwych dozwolonych wartości numerycznych, ale także powinniśmy zapewnić odrzucanie wszystkich błędnych wartości. Jest 26 znaków alfanumerycznych w rejestrze górnym, 26 w rejestrze dolnym, co najmniej 6 znaków interpunkcyjnych, a także wartość pusta. Więc wyszło by co najmniej 68 testów, i to nawet nie wspominając o znakach specjalnych, itp.

Problem zaostrza się w kontekście bardziej realnych przypadków. W praktyce systemy mają więcej niż jedno pole wprowadzania danych, i pola te mogą być różnych rozmiarów. Dodatkowo, są jeszcze różne środowiska, w których trzeba wykonywać testy. Posłużmy się przykładem , gdzie jeden ekran ma 15 pól wprowadzenia danych, każde z których ma 5 możliwych wartości. W tej sytuacji do przetestowania wszystkich kombinacji dozwolonych wartości wejściowych musielibyśmy wykonać 30 517 578 125 (515) testów! Mało prawdopodobne jest, że ramy czasowe projektu pozwolą na taką liczbę testów.

Jest taka bajka o magicznym garneczku, który gotował i gotował kaszę aż zalał całe miasto. Tak samo i nasz "garnuszek" może gotować i gotować bez końca, i w pewnej chwili trzeba powiedzieć: "Dosyć, garnuszku!" 

Używając techniki podziału na klasy równoważności możemy zmniejszyć liczbę testów, ponieważ testowanie pola wprowadzania danych o jednej wartości numerycznej za pomocą wartości 2, 3 i 4 nie da nam więcej informacji, niż przetestowanie tego pola wyłącznie z wartością 3.

W prawdziwym życiu zakres testowania jest ograniczony ramami czasowymi i budżetem projektu, a jednocześnie trzeba dostarczyć rozwiązanie techniczne, spełniające potrzeby klienta. Klienci i menadżerowie projektów chcą zwrotu inwestycji (ROI) od czasu spędzonego na testowaniu (czas to pieniądz). Dotyczy to również zapobiegania występowania awarii po wydaniu, które zawsze są kosztowne. Nawet jeżeli klienci i menadżerowie projektów proszą o całościowe testowanie, po prostu ich na to nie stać..

Zamiast próbować "przetestować wszystko", potrzebujemy pewnego podejścia do testowania (strategii), które zapewni odpowiednią ilość testów dla danego projektu, danych klientów (oraz innych interesariuszy) i danego oprogramowania. W decydowaniu o dostatecznym zakresie testowania bierze się pod uwagę stopień ryzyka, w tym ryzyk technicznych i biznesowych, powiązanych z takimi ograniczeniami produktowymi i projektowymi jak czas i budżet. Jedna z najważniejszych aktywności w każdym projekcie to ocena i zarządzanie ryzykiem. Daje to możliwość regulacji nakładu pracy w testowaniu w zależności od stopnia ryzyka w różnych obszarach.

Poza tym, testowanie powinno dawać wystarczającą informację, aby interesariusze mogli podejmować świadome decyzje dotyczące wydania produktu czy przekazania klientom.

W drugiej części artykułu przyjrzymy się następnym dwóm zasadom testowania.

Victoria Slinyavchuk
Consultant on Software Testing