Z naszego marcowego wpisu dowiedzieliście się już, na jakie rodzaje możemy podzielić testowanie oprogramowania, bazując na celach, w jakich je przeprowadzamy. Dziś przyjrzymy się innemu zagadnieniu związanemu z podziałami testów; poziomami testów.
Często przez nas przywoływany Sylabus ISTQB Poziomu Podstawowego (wersja 2011.1.2.), na którym będziemy w tym wpisie bazować, wyróżnia 4 poziomy testowania, które odpowiadają 4 poziomom rozwoju oprogramowania (tzw. model V). Nie należy jednak bezkrytycznie trzymać się tego podziału, ponieważ w praktyce poziomy testowania mogą być inne; w zależności od rodzaju projektu. Działania testowe powinny być „szyte na miarę” konkretnego projektu, a nie bezmyślnie podążać za teorią z podręczników.
Sylabus wyróżnia następujące poziomy testów:
- Testy modułowe (zwane też testami jednostkowymi, Unit testing)
- Testy integracyjne (Integration testing)
- Testy systemowe (System testing)
- Testy akceptacyjne (Acceptance testing)
Niektórzy wyodrębniają testy regresywne, jako oddzielny poziom analizy oprogramowania, ale to niewłaściwe rozumowanie. Testowanie związane ze zmianami może być przeprowadzone na każdym z wymienionych wyżej poziomów.
Jaki jest cel dzielenia testowania na poziomy?
Zadaniem grupowania testów na poziomy jest rozpoznanie brakujących obszarów i zapobieganie nakładaniu się i powtarzaniu działań między fazami cyklu rozwoju projektu. W modelach cyklu życia oprogramowania wyróżniono kolejne etapy, takie jak: zbieranie i analiza wymagań, projektowanie, kodowanie lub implementacja, etc. Każda z tych faz przechodzi testy, stąd różne poziomy prowadzenia analizy.
Testy modułowe
Analizowane są poszczególne jednostki oprogramowania. Celem jest sprawdzenie, czy każdy moduł działa zgodnie z założeniami projektowymi, czy jest poprawny pod względem wymagań i funkcjonalności.
Ten typ analizy wykonywany jest przez programistów, zanim konfiguracja zostanie przekazana zespołowi testerskiemu.
Ograniczeniem testów modułowych jest liczba scenariuszy i danych testowych, które programista może wykorzystać w celu weryfikacji kodu źródłowego. Po wyczerpaniu wszystkich opcji nie ma wyboru, jak tylko zakończyć analizę i połączyć segment kodu z innymi jednostkami.
Typowe przedmioty analizy:
- Moduły
- Programy
- Programy do konwersji lub migracji danych
- Moduły bazodanowe
Testy integracyjne
Polegają na łączeniu poszczególnych jednostek i testowaniu ich jako grupy. Zadaniem jest ujawnienie błędów w integracji między zintegrowanymi jednostkami.
Można wyróżnić metody testowania integracyjnego, takie jak:
- Testowanie integracji Big Bang (Big bang integration testing)
- Z góry do dołu (Top-down)
- Z dołu do góry (Bottom-up)
- Funkcjonalny przyrostowy (Functional incremental)
Typowe przedmioty analizy:
- Implementacja baz danych podsystemów
- Infrastruktura
- Interfejsy
- Konfiguracja systemu i dane konfiguracyjne
Testy systemowe
Analizowany jest kompletny, zintegrowany system. Dąży do ocenienia zgodności całego systemu z określonymi w projekcie wymaganiami.
Dlaczego to jest ważne?
- To pierwszy raz w cyklu życia oprogramowania, gdy jest ono testowane jako całość
- Dokładnie sprawdza się, czy projekt spełnia specyfikacje funkcjonalne i techniczne
- Testy wykonywane są w środowisku bardzo zbliżonym do środowiska produkcyjnego, w którym oprogramowanie zostanie wdrożone
- Pozwala przeanalizować zarówno wymagania biznesowe, jak i architekturę oprogramowania
Typowe przedmioty analizy:
- Podręczniki systemowe, użytkownika i operacyjne
- Konfiguracje systemu i dane konfiguracyjne
Testy akceptacyjne
System badany jest pod kątem akceptowalności. Jest to prawdopodobnie najważniejszy rodzaj testów. Przeprowadza go zespół ds. Kontroli jakości, który ocenia, czy oprogramowanie spełnia zamierzone specyfikacje i realizuje wymagania klienta. Zespół dysponuje zestawem wstępnie napisanych scenariuszy i przypadków testowych, które będą używane do testowania aplikacji.
Testy akceptacyjne mają na celu nie tylko wskazanie prostych błędów ortograficznych, błędów kosmetycznych lub luk w interfejsie, ale także wskazanie wszelkich błędów w aplikacji, które spowodują awarię systemu lub poważne błędy w aplikacji.
Standardowe formy testów akceptacyjnych:
- Testowanie przez użytkownika – sprawdzanie przydatności systemu dla użytkownika
- (Akceptacyjne) Testy produkcyjne – akceptacja systemu przez administratorów
- Testy zgodności z umową i zgodności legislacyjnej – zgodność z kryteriami zapisanymi w kontrakcie oraz zgodność z normami prawnymi (np. przepisami dotyczącymi bezpieczeństwa i ochrony danych osobowych użytkowników)
Typowe przedmioty analizy:
- Proces biznesowy na systemie w pełni zintegrowanym
- Procesy utrzymania i obsługi
- Procedury pracy użytkowników
- Formularze
- Raporty
- Dane konfiguracyjne
W tekstach branżowych możemy natknąć się na wiele innych poziomów testowania oprogramowania. Wśród nich często wspomina się także o:
- Testowaniu integracji systemów – sprawdza, czy w danym środowisku wszystkie powiązane systemy utrzymują integralność danych i są w stanie działać w koordynacji z innymi systemami
- Testach alfa – odbywają się w witrynie dla programistów pod koniec procesu rozwoju
- Testach beta – przeprowadzane na stronie klienta tuż przed uruchomieniem produktu
- Testach bezpieczeństwa – mają na celu zidentyfikowanie wszelkich luk z punktu widzenia bezpieczeństwa i podatności na zagrożenia
Jak widzicie, zagadnienie poziomów testowania nie ma jedynej słusznej odpowiedzi. Poziomy są ściśle powiązane z cyklem życia projektu i do niego dostosowane. Nie dziwi więc, że systematyki różnią się między sobą.
Pozostaje uzbroić się w wiedzę i wykorzystać ją stosowanie do każdego projektu przez nas realizowanego 🙂 .
