Proces wytwarzania oprogramowania, niezależnie od przyjętego modelu cyklu życia, jest złożonym przedsięwzięciem.

Od pojedynczych linijek kodu, przez współpracujące ze sobą moduły, aż po kompletny system działający w docelowym środowisku – na każdym etapie pojawiają się potencjalne źródła błędów.

Aby skutecznie zarządzać procesem testowania i zapewnić odpowiednią jakość na każdym etapie, stosuje się koncepcję poziomów testów.

Jak definiuje sylabus ISTQB Foundation Level v4.0, „poziomy testów to grupy czynności testowych, które organizuje się i którymi zarządza się wspólnie”.

Każdy poziom skupia się na innym aspekcie systemu i ma inne cele.

W tej lekcji szczegółowo omówimy poszczególne poziomy testów zdefiniowane w sylabusie ISTQB, ich charakterystykę, cele oraz typowe zastosowania.

Czym Są Poziomy Testów?

Wyobraźmy sobie budowanie domu. Zanim powstanie gotowy budynek, przechodzimy przez różne etapy: wylewanie fundamentów, stawianie ścian, montaż dachu, instalacje, wykończenie wnętrz.

Na każdym z tych etapów można i należy przeprowadzać kontrole jakości, ale będą one miały inny zakres i cel.

Sprawdzanie wytrzymałości betonu w fundamencie to co innego niż testowanie szczelności okien czy działania instalacji elektrycznej.

Podobnie jest w oprogramowaniu.

Poziomy testów to logiczne etapy w procesie testowym, gdzie każdy etap koncentruje się na określonym zakresie testowanego oprogramowania.

Sylabus ISTQB definiuje poziom testów jako „instancję procesu testowego wykonywaną w odniesieniu do oprogramowania na danym etapie wytwarzania — od pojedynczych modułów po kompletne systemy lub, jeśli ma to zastosowanie w danym przypadku, po systemy systemów”.

Poziomy testów są ściśle powiązane z cyklem życia oprogramowania (SDLC).

W modelach sekwencyjnych (np. model V), poziomy testów często odpowiadają poszczególnym etapom wytwarzania (np. testy modułowe odpowiadają kodowaniu, testy systemowe – projektowaniu systemu).

Kryteria wyjścia z jednego poziomu (np. pomyślne przejście testów modułowych) mogą stanowić kryteria wejścia do następnego poziomu (np. rozpoczęcie testów integracyjnych).

W modelach iteracyjnych i zwinnych, poziomy testów mogą się bardziej przenikać i być wykonywane wielokrotnie w ramach każdej iteracji.

Ważne jest, że „czynności związane z wytwarzaniem oprogramowania mogą obejmować wiele poziomów testów, a poziomy testów mogą zachodzić na siebie w czasie”.

Poziomy Testów Według ISTQB

Sylabus ISTQB Foundation Level v4.0 opisuje pięć głównych poziomów testów:

1. Testowanie Modułowe (Component Testing / Unit Testing):

• Fokus: Najmniejsze testowalne części oprogramowania, czyli poszczególne moduły, komponenty, klasy, funkcje lub procedury. Testowanie odbywa się w izolacji od reszty systemu.
• Cel: Weryfikacja, czy dany moduł działa poprawnie zgodnie ze swoją specyfikacją. Wykrywanie defektów w logice, strukturze danych i algorytmach wewnątrz modułu.
• Kto wykonuje: Zazwyczaj programiści, często w ramach procesu kodowania (np. stosując TDD).
• Środowisko: Środowisko deweloperskie. Często wymaga stosowania elementów pomocniczych, takich jak „jarzma testowe” (test harnesses), zaślepki (stubs) i sterowniki (drivers), aby zasymulować zależności i umożliwić izolowane testowanie modułu. Popularne są frameworki do testów jednostkowych (np. JUnit dla Javy, NUnit dla .NET, pytest dla Pythona).
• Podstawa testów: Szczegółowy projekt modułu, specyfikacja komponentu, kod źródłowy.

Testowanie modułowe jest fundamentem piramidy testów i kluczowym elementem podejścia „Shift Left”. Pozwala na wczesne wykrywanie błędów, gdy są one najłatwiejsze i najtańsze do naprawienia.

2. Testowanie Integracji Modułów (Component Integration Testing):

• Fokus: Interfejsy i interakcje między zintegrowanymi modułami lub komponentami. Sprawdzenie, czy moduły poprawnie komunikują się i współpracują ze sobą.
• Cel: Wykrywanie defektów w interfejsach, przepływie danych i sterowania między modułami. Weryfikacja poprawności integracji.
• Kto wykonuje: Zazwyczaj programiści lub wyspecjalizowani testerzy integracyjni.
• Środowisko: Może wymagać częściowo zintegrowanego systemu lub specjalnego środowiska integracyjnego.
• Strategie: Sposób przeprowadzania testów integracji modułów zależy od przyjętej strategii integracji, np.:
  • Strategia „wielkiego wybuchu” (big bang): Wszystkie moduły są integrowane jednocześnie, a następnie testowane jako całość. Trudna w debugowaniu.
  • Strategia wstępująca (bottom-up): Integracja i testowanie rozpoczyna się od modułów najniższego poziomu, stopniowo dodając moduły wyższego poziomu. Wymaga sterowników (drivers).
  • Strategia zstępująca (top-down): Integracja i testowanie rozpoczyna się od modułów najwyższego poziomu, stopniowo dodając moduły niższego poziomu. Wymaga zaślepek (stubs).
  • Strategia przyrostowa (incremental): Moduły są integrowane i testowane pojedynczo lub w małych grupach.
• Podstawa testów: Projekt architektury, specyfikacje interfejsów, przypadki użycia obejmujące interakcje modułów.

3. Testowanie Systemowe (System Testing):

• Fokus: Cały zintegrowany system lub produkt jako całość. Ocena ogólnego zachowania i możliwości systemu w kontekście zdefiniowanych wymagań (funkcjonalnych i niefunkcjonalnych).
• Cel: Weryfikacja, czy system spełnia określone wymagania. Wykrywanie defektów w działaniu całego systemu, w tym w interakcjach między komponentami i z otoczeniem. Ocena charakterystyk niefunkcjonalnych (np. wydajności, bezpieczeństwa, użyteczności).
• Kto wykonuje: Zazwyczaj niezależny zespół testowy (testerzy).
• Środowisko: Środowisko testowe możliwie jak najbardziej zbliżone do środowiska produkcyjnego. Może wymagać symulacji niektórych elementów zewnętrznych.
• Podstawa testów: Specyfikacje wymagań systemowych (funkcjonalnych i niefunkcjonalnych), przypadki użycia, historyjki użytkownika, modele systemu, podręczniki użytkownika.

Testowanie systemowe obejmuje szeroki zakres typów testów, zarówno funkcjonalnych (sprawdzanie, „co” system robi), jak i niefunkcjonalnych (sprawdzanie, „jak dobrze” system działa).

4. Testowanie Integracji Systemów (System Integration Testing):

• Fokus: Interfejsy i interakcje między różnymi systemami, mikrousługami lub komponentami w ramach większego „systemu systemów”. Sprawdzenie, czy poszczególne systemy poprawnie współpracują ze sobą.
• Cel: Wykrywanie defektów w interfejsach między systemami, w przepływie danych, komunikacji (np. przez API, kolejki komunikatów). Weryfikacja poprawności współpracy w ramach całego ekosystemu.
• Kto wykonuje: Zespoły odpowiedzialne za poszczególne systemy lub dedykowany zespół ds. integracji.
• Środowisko: Zintegrowane środowisko testowe obejmujące wszystkie współpracujące systemy (lub ich symulacje).
• Podstawa testów: Dokumentacja architektury systemu systemów, specyfikacje interfejsów API, definicje przepływów pracy między systemami.

Ten poziom jest szczególnie ważny w architekturach rozproszonych, mikrousługowych czy przy integracji z systemami zewnętrznymi.

5. Testowanie Akceptacyjne (Acceptance Testing):

• Fokus: Ocena gotowości systemu z perspektywy biznesowej lub użytkownika końcowego. Sprawdzenie, czy system spełnia potrzeby, wymagania i oczekiwania interesariuszy.
• Cel: Uzyskanie pewności, że system jest odpowiedni do zamierzonego celu i może zostać zaakceptowany przez użytkowników lub klienta. Budowanie zaufania do systemu.
• Kto wykonuje: Zazwyczaj przedstawiciele biznesu, użytkownicy końcowi, właściciele produktu, analitycy biznesowi, wspierani przez testerów.
• Środowisko: Środowisko testowe jak najbardziej zbliżone do produkcyjnego, a czasem nawet samo środowisko produkcyjne (np. w ramach testów beta lub A/B).
• Podstawa testów: Wymagania biznesowe, przypadki użycia, historyjki użytkownika, procesy biznesowe, regulacje prawne lub branżowe.
• Formy testów akceptacyjnych:
  • Testy akceptacyjne użytkownika (User Acceptance Testing - UAT): Wykonywane przez użytkowników końcowych w ich środowisku pracy lub symulowanym środowisku.
  • Testy akceptacyjne operacyjne (Operational Acceptance Testing - OAT): Wykonywane przez administratorów systemu lub zespół operacyjny, sprawdzające aspekty związane z utrzymaniem, zarządzaniem, bezpieczeństwem, tworzeniem kopii zapasowych itp.
  • Testy akceptacyjne kontraktowe i regulacyjne: Weryfikacja zgodności z umowami, przepisami prawa, standardami branżowymi.
  • Testy alfa i beta: Testy wykonywane przez ograniczoną grupę użytkowników (alfa – wewnętrznie, beta – zewnętrznie) przed oficjalnym wydaniem produktu.

Testowanie akceptacyjne jest ostatnim poziomem testów przed wdrożeniem systemu i ma kluczowe znaczenie dla potwierdzenia wartości biznesowej dostarczonego rozwiązania.

Podsumowanie

Poziomy testów to zorganizowane grupy czynności testowych skupiające się na różnych aspektach i etapach rozwoju oprogramowania.

ISTQB wyróżnia pięć głównych poziomów: testowanie modułowe (najniższy poziom, fokus na izolowanych komponentach), testowanie integracji modułów (fokus na interakcjach między modułami), testowanie systemowe (fokus na całym systemie i jego wymaganiach), testowanie integracji systemów (fokus na interakcjach między systemami) oraz testowanie akceptacyjne (najwyższy poziom, fokus na potrzebach biznesowych i akceptacji przez użytkowników).

Każdy poziom ma swoje specyficzne cele, podstawę testów, typowe obiekty testów i często jest wykonywany przez inne role w zespole.

Zrozumienie i odpowiednie zastosowanie poziomów testów jest kluczowe dla skutecznego planowania, zarządzania i wykonywania procesu testowego.