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.

cztery cyfra biały ściana cegła

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

Testy bezpieczeństwo ręka telefon kod

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 🙂 .

19
  •  
    6
    Shares
  • 6
  •  
  •  
  •