Testowanie oprogramowania jest nieodłączną częścią procesu tworzenia oprogramowania: pozwala znaleźć błędy, luki i defekty w produkcie, zbadać jakość i wydajność oprogramowania, a także ocenić, na ile testowany system jest zgodny z zadaną specyfikacją oraz wymaganiami stawianymi przez klienta, użytkowników i środowisko techniczne, w którym produkt ma docelowo funkcjonować.

Zasady testowania

W procesie testowania oprogramowania, poza uzyskaniem zadowalających rezultatów i wyników końcowych, ważne jest, aby testy wykryły jak najwięcej błędów, które istnieją w oprogramowaniu. Dobranie właściwych testów – ich ilości, typu, poziomu, rodzaju – oraz przeprowadzenie ich to zadanie dla profesjonalisty. Dzięki odwołaniu się do ogólnie przyjętych wytycznych można zweryfikować jakość testów, a także zaprojektować testy dla nowego oprogramowania, jednak nic nie zastąpi doświadczenia, które pozwala usprawnić proces testowania. Jednakowoż każdy tester podczas pracy powinien cały czas pamiętać o kilku prostych zasadach, które opisano poniżej.

1. Testowanie ujawnia usterki, ale nie może dowieść ich braku

Innymi słowy, błędy, które wyjdą na jaw w trakcie testowania, zostaną zgłoszone i naprawione, jednak po całym procesie testowym w oprogramowaniu nadal mogą znajdować się ukryte błędy, które wyjdą na jaw dopiero po wypuszczeniu oprogramowania do użytkowników końcowych. Oczywiście testowanie znacząco zmniejsza liczbę błędów i niedociągnięć w końcowym produkcie, jednak nigdy nie ma stuprocentowej pewności, że oprogramowanie jest wolne od błędów. Wręcz przeciwnie – niezależnie od tego, jak dużo błędów wykryją testerzy, nadal mogą znaleźć się takie, które odkryją dopiero użytkownicy podczas normalnego korzystania z oprogramowania. Nie znaczy to, że testowanie zawiodło albo że testy były złe. Sednem tej zasady jest stwierdzenie, iż nigdy nie można mieć całkowitej pewności, że oprogramowanie jest wolne od błędów.

2. Testowanie gruntowne jest niewykonalne

Czyli: nie da się przetestować wszystkiego. Ilość kombinacji danych wejściowych/wyjściowych i ustawień oprogramowania zmierza do nieskończoności tym szybciej, im bardziej złożone jest oprogramowanie, a przetestowanie nieskończonej ilości przypadków wymagałoby nieskończenie dużo czasu, pieniędzy i mocy obliczeniowej. Rzecz jasna nikt nie dysponuje nieskończonymi zasobami, dlatego też testowanie trzeba ograniczyć, tzn. w pewnym momencie podjąć decyzję o zakończeniu testów. W praktyce testuje się kluczowe przypadki, które mogą wykryć potencjalne błędy pojawiające się w konkretnych sytuacjach. Sztuką jest wybranie właśnie tych kombinacji danych i ustawień, które pozwolą wykryć najwięcej błędów. Zwykle powinno polegać to na tym, że w pierwszej kolejności obieramy za cel testów najważniejsze funkcjonalności, które są kluczowe z biznesowego punktu widzenia. Jeśli np. naszym obiektem testów jest system do fakturowania to na pewno powinniśmy się skupić na testach funkcjonalności takich jak: wystawienia faktury, dodawanie kontrahentów, czy import / eksport dokumentów.

3. Wczesne testowanie

Tworząc oprogramowanie należy zacząć testy tak wcześnie, jak to możliwe – najlepiej już na etapie planowania i analizy. Koszty poprawy znalezionych błędów rosną wykładniczo wraz z czasem i postępem prac nad oprogramowaniem. Im projekt jest w bardziej zaawansowanej fazie, tym koszt naprawy błędu jest większy. Dużo łatwiej jest dokonać nawet znaczących zmian na etapie projektowania oprogramowania, niż w momencie, gdy deweloperzy skończą pisać kod, a do poprawy są całe funkcjonalności. Zwlekanie z testowaniem, poza podniesieniem kosztów, może również oznaczać przekroczenie terminów, gdyż poprawa kluczowych elementów na późnym etapie projektu będzie wymagać dużo więcej czasu.

Warto pamiętać, że testy to przede wszystkim szukanie błędów, można więc przeprowadzać je już na etapie planowania – w końcu błędy zdarzają się wszędzie! Nie uruchamia się wtedy aplikacji (testowanie dynamiczne), a weryfikuje zgodność zlecenia i założeń programu z jego projektem,planem (testowanie statyczne). Analiza wymagań powinna nastąpić jeszcze zanim deweloperzy zaczną pisać kod, bo błąd niewykryty na tym etapie może oznaczać, że w najgorszym przypadku trzeba będzie de facto tworzyć całe oprogramowanie, bądź jego część od nowa. Aplikacja stworzona “pod” niewłaściwe wymagania może działać wyśmienicie, jednak jeśli nie robi tego, co miała planowo robić, sprawność jej działania nie ma żadnego znaczenia, gdyż nie będzie spełniała potrzeb klienta.

4. Kumulowanie się błędów

Błędy nie są rozłożone równomiernie w oprogramowaniu. Zazwyczaj jest tak, iż jakaś konkretna grupa przypadków (kombinacji danych wejściowych i ustawień oprogramowania) generuje najwięcej błędów; mówi się nawet, że 20% przypadków powoduje 80% błędów. Wartości te nie są oczywiście ścisłe, warto jednak pamiętać, że faktycznie to te bardziej skomplikowane czy nietypowe przypadki mogą wykryć wiele wadliwych funkcjonalności.

Specyficzną własność kumulowania się defektów można wykorzystać, aby znacząco ograniczyć liczbę przeprowadzanych testów, skupiając się właśnie na tych “problematycznych” przypadkach. Z drugiej strony warto pamiętać, że uporczywe testowanie tych samych kombinacji w którymś momencie przestanie wykrywać nowe błędy, ponieważ zajdzie…

5. Paradoks pestycydów

Pojęcie “paradoksu pestycydów” odnosi się do sytuacji, w której ten sam zestaw testów powtarzany wielokrotnie na oprogramowaniu przestaje wykrywać błędy. Dzieje się tak dlatego, że usterki wykryte już przez ów zestaw testowy zostały naprawione, a innych nie ma on szans ujawnić. Swą nazwę paradoks ten zawdzięcza rolnictwu, gdzie od dawna wiadomo, że ciągłe opryskiwanie upraw tymi samymi pestycydami doprowadzi do uodpornienia się szkodników na te konkretne pestycydy. I choć oprogramowanie nie “uodparnia” się na test samo z siebie, ono również wymaga zmiany “pestycydów”.

Aby zapobiec efektom paradoksu pestycydów wystarczy zmieniać testy wraz z postępem prac nad oprogramowaniem. Dodawaniu nowych przypadków do grup testowych może towarzyszyć usuwanie starych, które przestały generować nowe błędy (chyba, że robimy typową regresję testów) i co do których jest pewność, że działają poprawnie.

6. Testowanie zależy od kontekstu

Każde oprogramowanie trzeba testować inaczej. Może się to wydawać oczywiste, jednak warto pamiętać, że każdy system jest inny i każdy trzeba testować inaczej. Już same różnice w wymaganiach stawianych oprogramowaniu sprawiają, że nie można go całkowicie zautomatyzować i ujednolicić. Inaczej będzie testowana aplikacja bankowa, a inaczej sklep internetowy, bo i do czego innego mają służyć. Zasada ta dotyczy również ilości testów: oprogramowanie dla infrastruktury krytycznej (np. sterujące ruchem na kolei) będzie testowane dużo dokładniej niż na przykład serwis z wideo szkoleniami o hodowli roślin.

7. Mylne przekonanie o braku błędów

Gotowe oprogramowanie musi być nie tylko w wysokim stopniu wolne od błędów, ale również zgodne z zadaną specyfikacją. Nikomu nie przyda się oprogramowanie, które może i nie generuje błędów, ale jednocześnie robi coś innego, niż miało robić w założeniach. Albo jest zbyt skomplikowane w użytkowaniu i osoby, które miały z niego korzystać nie są w stanie robić tego wydajnie. Oprogramowanie, które jest niefunkcjonalne to taka sama porażka, jak oprogramowanie pełne błędów.

Podsumowanie

Tych siedem zasad testowania pomaga przygotować i przeprowadzić właściwy proces testowania oprogramowania. Warto myśleć o nich jak o całości i wdrażać je wszystkie na każdym etapie testowania. Stosowanie się do poszczególnych punktów tej listy może pomóc uniknąć wielu problemów – choćby testowanie na wczesnym etapie, które wykryje niezgodność założeń projektu z zadaną specyfikacją, może sprawić, że końcowy produkt faktycznie będzie funkcjonalny. Działanie zgodnie z tymi zasadami jest oczywiste dla testerów, gdyż pozwala zoptymalizować proces testowania, czyniąc go jednocześnie skutecznym.

Autor: Tomasz Stelmach