Poziomy testowania

Wiele źródeł opisuje poziomy testów, ale pierwszy źródłem podzielenia testowania na poziomy wydaje się być model V. To w nim zdefiniowano poziomy wytwarzania oprogramowania i zmapowano na nie poziomy weryfikacji.

W słowniku pojęć testerskich poziom testów jest definiowany jako "grupa czynności testowych, które są razem zorganizowane i zarządzane. Poziom testów jest powiązany z poziomami odpowiedzialności w projekcie. Przykładami poziomów testów są testy modułowe, integracyjne, systemowe i akceptacyjne".

W modelu V wyróżniamy:

• Unit testing
• Integration tesing  
• System testing
• User acceptance testing.

W publikacjach ISTQB terminy te tłumaczone są jako:

• Poziom testów modułowych (jednostkowych)
• Poziom testów integracyjnych
• Poziom testów systemowych
• Poziom testów akceptacyjnych.

ISTQB dostrzega, że może być więcej, mniej lub mogą istnieć w ogóle inne poziomy testowania i rozwoju oprogramowania, zależnie od konkretnego projektu i wytwarzanego oprogramowania. Na przykład po testach modułowych może pojawić się poziom testowania integracji modułów, a po poziomie testów systemowych - poziom testów integracji systemów.

Poziomy testowania mogą być łączone lub organizowane na różne sposoby w zależności od natury projektu lub architektury systemu. Na przykład przy integracji oprogramowania z półki w jeden system nabywca może przeprowadzić testy integracyjne na poziomie systemowym (np. integracja z infrastrukturą i innymi systemami lub wdrożenie systemu) oraz testy akceptacyjne (funkcjonalne i niefunkcjonalne oraz testy akceptacyjne użytkownika i testy produkcyjne).

Podobnie poziomy testów definiuje model usprawniania procesów testowych - TMMi oraz standard testowania - ISO 29119.

W ramach każdego poziomu testowania możemy wyróżnić:

• ogólne cele
• produkty, na podstawie których tworzy się przypadki testowe (podstawę testów)
• przedmiot testów (to, co jest testowane)
• typowe defekty i awarie do wykrycia
• wymagania na jarzmo testowe oraz wsparcie narzędziowe
• środowisko testowe
• specyficzne podejście
• odpowiedzialność.

Poziom testów modułowych

Podstawą projektowania testów w testach modułowych są:

• wymagania na moduły
• projekt szczegółowy
• kod.

Typowe obiekty poddawane testowaniu to:

• moduły
• programy
• programy do konwersji lub migracji danych
• moduły bazodanowe.

Testy modułowe polegają na wyszukiwaniu defektów i weryfikacji funkcjonalności oprogramowania (np. modułów, programów, obiektów, klas), które można testować oddzielnie. Może być wykonywane w izolacji od reszty systemu, w zależności od kontekstu cyklu rozwoju oprogramowania i od samego systemu. Można podczas nich użyć zaślepek, sterowników testowych oraz symulatorów.

Testy modułowe mogą zawierać testy funkcjonalności oraz niektórych atrybutów niefunkcjonalnych, takich jak stopień wykorzystania zasobów (np. wycieków pamięci) lub odporności, jak również testy strukturalne (np. pokrycia decyzji). Przypadki testowe są projektowane na podstawie takich produktów jak specyfikacja modułu, projekt oprogramowania lub model danych.

Testy modułowe zwykle wykonuje się mając dostęp do kodu źródłowego i przy wsparciu środowiska rozwojowego (np. bibliotek do testów jednostkowych, narzędzi do debagowania) oraz, w praktyce, zwykle angażują też programistę, który jest autorem kodu. Usterki są usuwane jak tylko zostaną wykryte, bez formalnego zarządzania nimi.

Jednym z podejść do testów modułowych jest przygotowanie i zautomatyzowanie przypadków testowych przed kodowaniem. Podejście to nazywane jest "najpierw testuj" lub "wytwarzanie sterowane testami". Jest to podejście wysoce iteracyjne i opiera się na cyklach tworzenia przypadków testowych, a następnie budowaniu i integracji niewielkich fragmentów kodu, wykonywaniu testów modułowych, poprawianiu usterek i powtarzaniu tego procesu aż testy zostaną zaliczone.

Poziom testów integracyjnych

Podstawa testów:

• projekt oprogramowania i systemu
• architektura
• przepływy procesów
• przypadki użycia.

Typowe obiekty testów:

• implementacja baz danych podsystemów
• infrastruktura
• interfejsy
• konfiguracja systemu i dane konfiguracyjne.

Testy integracyjne sprawdzają interfejsy pomiędzy modułami, interakcje z innymi częściami systemu (takimi jak system operacyjny, system plików i sprzęt) oraz interfejsy pomiędzy systemami.

Testy integracyjne mogą być wykonywane na więcej niż jednym poziomie i dla przedmiotów testów o różnej wielkości:

• testowanie integracji modułów sprawdza interakcje pomiędzy modułami oprogramowania i jest wykonywane po testach modułowych
• testowanie integracji systemów sprawdza interakcje pomiędzy różnymi systemami lub pomiędzy sprzętem a oprogramowaniem i może być wykonywane po testach systemowych

W takim przypadku organizacja rozwijająca system może kontrolować tylko jedną stronę interfejsu. Może to zostać uznane za ryzyko. Procesy biznesowe zaimplementowane jako przepływ pracy mogą angażować wiele systemów. W takim przypadku istotne mogą okazać się różnice między platformami, na których zaimplementowane są poszczególne systemy.
Im większy jest zakres integracji, tym trudniejsze może być określenie, który moduł lub system zawiera defekt co powoduje zwiększone ryzyko i dłuższy czas rozwiązywania problemów.

Systematyczne strategie integracji mogą bazować na architekturze systemu (np. strategie wstępująca i zstępująca), zadaniach funkcjonalnych, sekwencjach przetwarzania transakcji albo na innym aspekcie systemu lub modułu. Żeby ułatwić namierzanie usterek oraz ich wczesne wykrywanie, w normalnych warunkach integracja powinna być raczej prowadzona metodą inkrementalną niż metodą "wielkiego wybuchu".

Podczas testów integracyjnych można wykonać testy niektórych atrybutów niefunkcjonalnych (np. wydajności) na równi z testami funkcjonalnymi.

Na każdym etapie integracji, testerzy koncentrują się wyłącznie na samej integracji. Na przykład, gdy integrują moduł A z modułem B, interesują się tylko testowaniem komunikacji pomiędzy modułami, a nie funkcjonalnością poszczególnych modułów, gdyż ta była sprawdzona wcześniej w testach modułowych. Można tu wykorzystać zarówno podejście funkcjonalne jak i strukturalne.

W idealnym przypadku tester powinien rozumieć architekturę i mieć wpływ na planowanie integracji. Jeżeli testy integracyjne planowane są zanim moduły lub systemy zostały wyprodukowane, można ich rozwój ustawić w kolejności pozwalającej na najbardziej efektywne testowanie.

Poziom testów systemowych

Podstawa testów:

• wymagania na system i oprogramowanie
• przypadki użycia
• specyfikacja funkcjonalna
• raporty z analizy ryzyka

Typowe obiekty testów:

• podręczniki systemowe, użytkownika i operacyjne
• konfiguracje systemu i dane konfiguracyjne

Testy systemowe zajmują się zachowaniem systemu/produktu. Zakres testów powinien być jasno określony w głównym planie testów oraz w planach testów poszczególnych poziomów.

Środowisko testowe, podczas testów systemowych, powinno być zgodne ze środowiskiem docelowym /produkcyjnym w jak najwyższym możliwym stopniu, żeby zminimalizować ryzyko wystąpienia awarii spowodowanych przez środowisko, które nie zostałyby wykryte podczas testów.

Testy systemowe mogą zawierać testy oparte na ryzyku lub wymaganiach, procesie biznesowym, przypadkach użycia lub jeszcze innych wysokopoziomowych opisach słownych lub modelach zachowania systemu, interakcji z systemem operacyjnym i zasobami systemowymi.

Testy systemowe powinny sprawdzać funkcjonalne jak i niefunkcjonalne wymagania na system oraz jakość danych. Wymagania mogą być wyrażone w formie tekstu lub modeli. Testerzy muszą umieć sobie poradzić z wymaganiami niekompletnymi lub nieudokumentowanymi. Testowanie systemowe wymagań funkcjonalnych rozpoczyna się przez użycie najbardziej odpowiednich technik opartych na specyfikacji (czarnoskrzynkowych) dla testowanego aspektu systemu. Na przykład można utworzyć tablicę decyzyjną zawierającą kombinacje skutków opisane w regułach biznesowych. Następnie można użyć technik opartych na strukturze (białoskrzynkowych) do oceny dokładności testowania w odniesieniu do elementów struktury, takich jak menu lub nawigacja po stronach webowych.

Testy systemowe są często wykonywane przez niezależny zespół testowy.

Poziom testów akceptacyjnych

Podstawa testów:

• wymagania użytkownika
• wymagania systemowe
• przypadki użycia
• procesy biznesowe
• raporty z analizy ryzyka

Typowe obiekty testów:

• proces biznesowy na systemie w pełni zintegrowanym
• procesy utrzymania i obsługi
• procedury pracy użytkowników
• formularze
• raporty
• dane konfiguracyjne.

Odpowiedzialność za testy akceptacyjne leży często po stronie klientów lub użytkowników systemu. Mogą w nie być zaangażowani również inni interesariusze.

Celem testów akceptacyjnych jest nabranie zaufania do systemu, jego części lub pewnych atrybutów niefunkcjonalnych. Wyszukiwanie usterek nie jest tym, na czym skupiają się testy akceptacyjne. Mogą one oceniać gotowość systemu do wdrożenia i użycia, chociaż nie muszą być ostatnim poziomem testowania. Na przykład może po nich następować testowanie integracji systemów w większej skali.

Testy akceptacyjne mogą pojawić się w wielu momentach cyklu życia oprogramowania. Na przykład:

• oprogramowanie z półki może podlegać testom akceptacyjnym, gdy jest instalowane lub integrowane
• testy akceptacyjne użyteczności modułu mogą być wykonane w czasie testów modułowych
• testy akceptacyjne nowej funkcjonalności mogą być przeprowadzone przed testami systemowymi

Typowymi formami testów akceptacyjnych są:

• Testowanie akceptacyjne przez użytkownika

Zwykle sprawdza przydatność systemu dla użytkowników.

• (Akceptacyjne) testy produkcyjne

Akceptacja systemu przez administratorów:

• testowanie wykonywania i odtwarzania kopii zapasowych
• uruchamianie systemu po awarii
• zarządzanie użytkownikami
• zadania związane z utrzymaniem systemu
• ładowanie danych i inne zadania związane z migracją
• okresowe sprawdzenie słabych punktów zabezpieczeń

• Testy akceptacyjne zgodności z umową i testy zgodności legislacyjnej.

Testy zgodności z umową są wykonywane przez sprawdzenie spełnienia kryteriów akceptacji zapisanych w kontrakcie na wykonanie oprogramowania na zamówienie. Te kryteria akceptacji powinny być zdefiniowane w momencie negocjacji umowy. Testy zgodności legislacyjnej wykonuje się sprawdzając, czy oprogramowanie jest zgodne z wszystkimi przepisami prawnymi, z którymi musi być zgodne, takimi jak rozporządzenia rządowe, inne akty prawne lub przepisy dotyczące bezpieczeństwa.

• Testy alfa i beta (lub testy w warunkach polowych)

Producenci oprogramowania tworzonego na szeroki rynek ( oprogramowanie z półki) często chcą uzyskać opinię potencjalnych lub obecnych klientów, zanim oprogramowanie zostanie wypuszczone do sprzedaży. Testy alfa są wykonywane u producenta, ale nie przez zespół projektowy. Testy beta, lub testy polowe, wykonywane są przez klientów lub potencjalnych klientów w ich własnych lokalizacjach.

W różnych organizacjach mogą być w użyciu inne nazwy, takie jak fabryczne testy akceptacyjne lub docelowe testy akceptacyjne w sytuacji, gdy system jest testowany przed i po zainstalowaniu u klienta.