Do tej pory w rozdziale trzecim skupialiśmy się wyłącznie na testowaniu statycznym – jego podstawach, procesie przeglądu i wartości, jaką wnosi do projektu.

Jednak świat testowania nie kończy się na analizie dokumentów i kodu bez ich uruchamiania.

Równie ważną, a historycznie często bardziej popularną, gałęzią jest testowanie dynamiczne, polegające na obserwowaniu zachowania oprogramowania podczas jego wykonywania.

Sylabus ISTQB Foundation Level v4.0 w sekcji 3.1.3 (FL-3.1.3 K2) podkreśla, że „Testowanie statyczne i testowanie dynamiczne wzajemnie się uzupełniają”.

Zrozumienie kluczowych różnic między tymi dwoma podejściami jest niezbędne, aby móc efektywnie planować i realizować strategię testową, wykorzystując mocne strony obu metod.

Ta lekcja poświęcona jest właśnie analizie tych różnic.

Podstawowa Różnica: Wykonywanie Kodu

Najbardziej fundamentalna różnica, od której wywodzą się pozostałe, dotyczy tego, czy badany obiekt (oprogramowanie lub jego część) jest uruchamiany podczas testu.

• Testowanie Statyczne: Odbywa się bez wykonywania kodu lub systemu. Polega na analizie produktów pracy (dokumentów, kodu źródłowego, modeli) w ich statycznej formie. Przykłady to przeglądy (manualne badanie) i analiza statyczna (automatyczne badanie kodu przez narzędzia).
• Testowanie Dynamiczne: Wymaga uruchomienia oprogramowania (lub jego komponentu) i obserwacji jego zachowania w odpowiedzi na określone dane wejściowe lub warunki. Celem jest sprawdzenie, czy system działa zgodnie z oczekiwaniami. Przykłady to testy jednostkowe, testy integracyjne, testy systemowe, testy akceptacyjne.

Ta podstawowa różnica ma daleko idące konsekwencje dla tego, co, kiedy i jak możemy testować za pomocą każdej z tych metod.

Cele i Wykrywane Defekty (FL-3.1.3 K2)

Chociaż obie metody mają wspólny nadrzędny cel – „wspomaganie wykrywania defektów w produktach pracy” (jak przypomina sylabus, odwołując się do sekcji 1.1.1) – różnią się sposobem, w jaki to robią, oraz rodzajami defektów, które są w stanie najefektywniej wykryć.

Wykrywanie Bezpośrednie vs Pośrednie:

• Testowanie statyczne „umożliwia bezpośrednie wykrywanie defektów” w analizowanym produkcie pracy (np. znalezienie błędu w logice podczas przeglądu kodu, wykrycie niespójności w dokumencie wymagań).
• Testowanie dynamiczne „powoduje występowanie awarii, które są następnie analizowane w celu zidentyfikowania związanych z nimi defektów”. Obserwujemy nieprawidłowe zachowanie systemu (awarię) i musimy przeprowadzić analizę (debugging), aby znaleźć przyczynę – czyli defekt w kodzie lub konfiguracji.

Rodzaje Wykrywanych Defektów:

Sylabus stwierdza: „istnieją pewne rodzaje defektów, które można wykryć tylko jedną z powyższych metod”.

Testowanie statyczne jest szczególnie skuteczne w wykrywaniu defektów, które są trudne do znalezienia dynamicznie, np.:

• Defekty w produktach pracy innych niż kod wykonywalny (wymagania, projekty, przypadki testowe).
• Defekty w kodzie, które niekoniecznie prowadzą do awarii w typowych scenariuszach testowych (np. naruszenia standardów kodowania, martwy kod, potencjalne problemy z wydajnością lub bezpieczeństwem, błędy w obsłudze rzadkich przypadków brzegowych).
• Defekty „znajdujące się na rzadko wykonywanych ścieżkach w kodzie lub w miejscach trudno dostępnych podczas testowania dynamicznego”.
• Niezgodności ze standardami, problemy z utrzymywalnością, czytelnością kodu.
• Sylabus podaje konkretne przykłady defektów łatwiejszych do wykrycia statycznie: defekty w wymaganiach (niespójności, niejednoznaczności), defekty w projekcie (nieefektywne struktury), niektóre defekty kodu (niezainicjowane zmienne, nieosiągalny kod), odchylenia od standardów, niepoprawne specyfikacje interfejsów, niektóre słabe punkty zabezpieczeń (podatność na przepełnienie bufora), luki w pokryciu podstawy testów.

Testowanie dynamiczne jest niezbędne do wykrywania defektów, które ujawniają się dopiero podczas działania programu, np.:

• Błędy w logice biznesowej, które prowadzą do nieprawidłowych wyników lub zachowań.
• Problemy z wydajnością pod obciążeniem.
• Błędy związane z interakcją między komponentami (testy integracyjne).
• Problemy ze środowiskiem wykonawczym, konfiguracją, zarządzaniem pamięcią w czasie rzeczywistym.
• Defekty ujawniające się tylko przy specyficznych danych wejściowych lub sekwencjach zdarzeń.

Kluczowe jest zrozumienie, że obie metody są potrzebne, aby uzyskać kompleksowy obraz jakości oprogramowania.

Poleganie tylko na jednej z nich pozostawiłoby wiele potencjalnych defektów niewykrytych.

Przedmiot Testowania (FL-3.1.3 K2)

Kolejna istotna różnica dotyczy tego, co może być przedmiotem testowania w obu podejściach.

• Testowanie Statyczne: Może być stosowane do niewykonywalnych produktów pracy. Obejmuje to szeroką gamę artefaktów projektowych, takich jak: specyfikacje wymagań, historyjki użytkownika, kryteria akceptacji, makiety interfejsu, modele architektury, dokumentacja projektowa, kod źródłowy (przed kompilacją/interpretacją), przypadki testowe, plany testów, skrypty testowe, a nawet dokumentacja użytkownika czy materiały marketingowe.
• Testowanie Dynamiczne: Może być stosowane tylko do produktów wykonywalnych – czyli skompilowanego kodu, zintegrowanych komponentów, całego systemu lub jego części, które można uruchomić i obserwować ich działanie.

Ta różnica podkreśla unikalną wartość testowania statycznego, które pozwala na ocenę jakości na bardzo wczesnych etapach, zanim jeszcze powstanie jakikolwiek działający kod.

Mierzone Charakterystyki (FL-3.1.3 K2)

Oba podejścia pozwalają na ocenę różnych charakterystyk jakościowych, ale skupiają się na innych aspektach.

• Testowanie Statyczne: Koncentruje się na wewnętrznych charakterystykach produktu pracy, takich jak: kompletność, spójność, poprawność logiczna, zgodność ze standardami, czytelność, utrzymywalność, testowalność (dokumentacji), potencjalne luki bezpieczeństwa w kodzie.
• Testowanie Dynamiczne: Koncentruje się na zewnętrznych charakterystykach działającego systemu, takich jak: poprawność funkcjonalna (czy robi to, co powinien?), wydajność (jak szybko działa?), niezawodność (jak często zawodzi?), użyteczność (czy jest łatwy w obsłudze?), bezpieczeństwo (czy jest odporny na ataki w czasie działania?).

Sylabus podsumowuje: „Testowanie statyczne pozwala ocenić kod i inne produkty pracy, podczas gdy testowanie dynamiczne pozwala ocenić zachowanie oprogramowania w trakcie jego wykonywania”.

Tabela Porównawcza

Dla lepszego zobrazowania kluczowych różnic, podsumujmy je w tabeli:

Komplementarność Metod

Najważniejszym wnioskiem płynącym z porównania jest fakt, że testowanie statyczne i dynamiczne nie są dla siebie konkurencją, lecz wzajemnie się uzupełniają.

Stosowanie obu podejść w ramach jednej strategii testowej pozwala na osiągnięcie znacznie wyższego poziomu jakości i pewności co do produktu.

Testowanie statyczne pomaga „oczyścić” produkty pracy na wczesnym etapie, redukując liczbę defektów, które mogłyby przedostać się do fazy testów dynamicznych.

Z kolei testowanie dynamiczne weryfikuje, czy system faktycznie działa poprawnie w rzeczywistych warunkach, czego samo testowanie statyczne nie jest w stanie zagwarantować.

Efektywna strategia testowa powinna uwzględniać obie metody, dobierając odpowiednie techniki statyczne i dynamiczne do specyfiki projektu, ryzyk i dostępnych zasobów.