Witaj w kolejnej lekcji naszego kursu!

Po zrozumieniu, czym jest testowanie, dlaczego jest konieczne oraz jaka jest różnica między błędami, defektami i awariami, nadszedł czas na poznanie fundamentalnych zasad, które kierują całym procesem testowym.

ISTQB sformułowało siedem kluczowych zasad testowania, które wynikają z wieloletnich doświadczeń i praktyki w branży.

Zrozumienie i stosowanie tych zasad pomaga w efektywnym planowaniu, projektowaniu i wykonywaniu testów, a także w realistycznym zarządzaniu oczekiwaniami wobec procesu testowego.

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

Pierwsza i jedna z najważniejszych zasad mówi, że testowanie może wykazać, że defekty są obecne w oprogramowaniu, ale nie może udowodnić, że ich nie ma.

Nawet jeśli przeprowadzimy bardzo dużą liczbę testów i nie znajdziemy żadnych defektów, nie mamy absolutnej pewności, że oprogramowanie jest w 100% wolne od błędów.

Zawsze istnieje możliwość, że jakiś defekt pozostał niewykryty, ponieważ nie został uruchomiony przez żaden z wykonanych przypadków testowych lub jego objawy nie zostały zauważone.

Testowanie redukuje prawdopodobieństwo wystąpienia awarii i zmniejsza liczbę niewykrytych defektów pozostających w oprogramowaniu, ale nigdy nie daje gwarancji ich całkowitego braku.

Celem testowania jest więc zwiększenie zaufania do jakości produktu poprzez znalezienie jak największej liczby istotnych defektów, a nie udowodnienie perfekcji.

Zasada 2: Testowanie gruntowne jest niemożliwe

Druga zasada stwierdza, że przetestowanie wszystkiego (wszystkich kombinacji danych wejściowych i warunków wstępnych) nie jest wykonalne, z wyjątkiem trywialnych przypadków.

Wyobraźmy sobie prosty formularz z kilkoma polami tekstowymi, listami rozwijanymi i przyciskami. Liczba możliwych kombinacji danych, które można wprowadzić, kolejności działań, stanów systemu i warunków środowiskowych (np. różne przeglądarki, systemy operacyjne) jest astronomiczna.

Próba przetestowania każdej możliwej ścieżki i kombinacji zajęłaby nieskończenie wiele czasu i zasobów.

Dlatego zamiast próbować testować wszystko (co jest niemożliwe), musimy skupić nasz wysiłek testowy na najważniejszych obszarach.

Wymaga to zastosowania analizy ryzyka i priorytetyzacji, aby zdecydować, które funkcje, scenariusze i kombinacje są najważniejsze do przetestowania w dostępnym czasie i budżecie.

Techniki projektowania testów (omawiane w Rozdziale 4) pomagają w wyborze optymalnego podzbioru testów, które mają największą szansę na wykrycie defektów.

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

Trzecia zasada podkreśla znaczenie rozpoczynania działań testowych jak najwcześniej w cyklu życia oprogramowania.

Aby wcześnie wykryć defekty, czynności testowe, zarówno statyczne, jak i dynamiczne, powinny być rozpoczęte możliwie jak najwcześniej w procesie tworzenia oprogramowania.

Jak już wspominaliśmy, koszty naprawy defektów rosną wykładniczo wraz z postępem projektu.

Defekt znaleziony i naprawiony na etapie wymagań jest wielokrotnie tańszy niż ten sam defekt znaleziony podczas testów systemowych lub, co gorsza, przez klienta po wdrożeniu.

Wczesne testowanie statyczne (np. przeglądy wymagań, projektu, kodu) pozwala wykryć defekty, zanim zostaną one zaimplementowane lub zanim spowodują problemy w późniejszych fazach.

Wczesne rozpoczęcie testowania dynamicznego (np. testy komponentowe) również pomaga szybko zidentyfikować problemy w poszczególnych modułach.

Ta zasada jest często określana mianem "shift left testing", czyli przesunięcia działań testowych w lewo na osi czasu projektu.

Zasada 4: Kumulowanie się defektów

Czwarta zasada mówi, że defekty nie są rozłożone równomiernie w systemie; zazwyczaj niewielka liczba modułów lub komponentów zawiera większość wykrytych defektów lub jest odpowiedzialna za większość awarii w środowisku produkcyjnym.

Zjawisko to jest często ilustrowane przez zasadę Pareto (80/20), która w tym kontekście sugeruje, że około 80% defektów znajduje się w 20% kodu.

Identyfikacja tych "gorących punktów" (ang. *defect clusters*) jest niezwykle ważna dla efektywnego planowania testów.

Jeśli wiemy, które moduły są historycznie bardziej podatne na błędy (np. ze względu na ich złożoność, częste zmiany, niedoświadczony zespół), możemy skoncentrować na nich większy wysiłek testowy.

Przewidywane i rzeczywiste klastry defektów są istotnym czynnikiem w analizie ryzyka i planowaniu testów opartych na ryzyku (więcej o tym w Rozdziale 5).

Zasada 5: Testy się zużywają (Paradoks pestycydów)

Piąta zasada, znana jako paradoks pestycydów, stwierdza, że jeśli te same testy są powtarzane wielokrotnie, stają się coraz mniej skuteczne w wykrywaniu nowych defektów.

Podobnie jak owady uodparniają się na ciągle stosowany ten sam pestycyd, tak oprogramowanie staje się "odporne" na ciągle te same testy.

Po pewnym czasie dany zestaw testów będzie znajdował coraz mniej nowych błędów, ponieważ te, które mógł wykryć, zostały już znalezione i naprawione.

Aby przezwyciężyć ten efekt i utrzymać skuteczność testowania, konieczne jest regularne przeglądanie i aktualizowanie istniejących testów oraz dodawanie nowych, które pokrywają inne obszary systemu, inne scenariusze lub wykorzystują inne dane.

Szczególnie ważne jest to w przypadku testów regresji, które muszą ewoluować wraz ze zmianami w oprogramowaniu.

Zasada 6: Testowanie zależy od kontekstu

Szósta zasada podkreśla, że nie ma jednego uniwersalnego podejścia do testowania; sposób testowania zależy od kontekstu.

Oprogramowanie tworzone jest w różnych celach, dla różnych branż i z różnymi wymaganiami jakościowymi.

Inaczej testuje się system bankowy, gdzie kluczowe jest bezpieczeństwo i poprawność obliczeń, inaczej grę komputerową, gdzie ważna jest grywalność i wydajność grafiki, a jeszcze inaczej stronę e-commerce, gdzie liczy się użyteczność i szybkość działania.

Kontekst obejmuje takie czynniki jak: rodzaj oprogramowania, wymagania biznesowe, poziom ryzyka, ograniczenia czasowe i budżetowe, stosowane technologie, model cyklu życia oprogramowania (np. Waterfall, Agile), regulacje prawne.

Podejście do testowania, wybór technik, poziom formalności, zakres automatyzacji – wszystko to musi być dostosowane do specyfiki danego projektu i jego kontekstu.

Zasada 7: Mylne przekonanie o braku błędów

Ostatnia, siódma zasada ostrzega przed pułapką myślenia, że znalezienie i naprawienie wielu defektów automatycznie oznacza, że system jest wysokiej jakości lub użyteczny.

Możliwe jest, że oprogramowanie, które przeszło wszystkie testy i w którym naprawiono wiele błędów, nadal nie spełnia potrzeb użytkowników lub jest trudne w obsłudze.

Wyobraźmy sobie system, który technicznie działa bez zarzutu, ale jego interfejs jest tak skomplikowany, że nikt nie potrafi go efektywnie używać, albo realizuje funkcje, które nie są potrzebne biznesowi.

Dlatego samo testowanie pod kątem zgodności ze specyfikacją (weryfikacja) nie wystarczy.

Konieczna jest również walidacja, czyli sprawdzenie, czy tworzony system jest tym, czego faktycznie potrzebują użytkownicy i interesariusze, i czy rozwiązuje ich problemy.

Nawet system bez defektów może być bezużyteczny, jeśli nie spełnia rzeczywistych potrzeb.

Podsumowanie

Siedem zasad testowania stanowi drogowskaz dla każdego testera i zespołu projektowego.

Przypominają one o ograniczeniach testowania (zasady 1 i 2), o korzyściach płynących z wczesnego działania (zasada 3), o nierównomiernym rozkładzie defektów (zasada 4), o konieczności adaptacji testów (zasada 5), o wpływie kontekstu (zasada 6) oraz o tym, że brak błędów nie gwarantuje sukcesu (zasada 7).

Świadomość tych zasad pozwala na bardziej efektywne, realistyczne i wartościowe podejście do zapewniania jakości oprogramowania.