Miejsce testowania w modelach cyklu tworzenia oprogramowania

alt
Prezentujemy tekst, który stanowi fragment przygotowywanego doktoratu Sylwii Bartman.

Tematem pracy jest przedstawienie miejsca jakie zajmuje testowanie w cyklu tworzenia oprogramowania. Przedstawiono modele tworzenia/cyklu życia oprogramowania ze szczególnym uwzględnieniem etapu testowania.


Modele tworzenia/cyklu życia oprogramowania

  • Model kaskadowy 1970 rok

Model kaskadowy wg pracy [1] jest pierwszym opublikowanym modelem procesu tworzenia oprogramowania. Model ten składa się z następujących po sobie faz (stąd nazwa kaskadowy). Wadą modelu kaskadowego jest zawarty w nim nieelastyczny podział na rozłączne etapy. Zobowiązania muszą być podejmowane w bardzo wczesnej fazie procesu. Oznacza to tym samym trudności w reagowaniu na pojawiające się zmiany tzn. nowe wymagania klienta. Zaleca się stosowanie tego modelu w przypadku, gdy wymagania są jasne i zrozumiałe. Kroki tego modelu odpowiadają następującym czynnościom tworzenia:

  1. Definiowanie i analiza wymagań. Cele systemu, jego usługi i ograniczenia są ustalane podczas narad z użytkownikami systemu. Są szczegółowo definiowane aby potem służyć za specyfikację systemu.
  2. Projektowanie systemu i oprogramowania. Proces projektowania systemu prowadzi do podziału wymagań na systemy sprzętu i oprogramowania. Ustala ogólną architekturę systemu. Projektowanie oprogramowania obejmuje identyfikowanie i opisywanie zasadniczych abstrakcji systemu oprogramowania i związki między nimi.
  3. Implementacja i testowanie jednostek. W tym kroku projekt oprogramowania jest realizowany w postaci zbioru programów albo jednostek programów. Testowanie jednostek polega na sprawdzeniu, czy każda jednostka spełnia swoją specyfikację.
  4. Integracja i testowanie systemu. Jednostki programów albo programy są integrowane i testowane jako kompletne systemy, aby upewnić się, czy spełniono wymagania. Po zakończeniu testowania system jest dostarczany klientowi.
  5. Działanie i pielęgnacja. Zazwyczaj jest to najdłuższa faza cyklu życia. System jest zainstalowany i przekazany do praktycznego użytkownika. Pielęgnacja obejmuje poprawianie błędów, których nie wykryto we wcześniejszych fazach cyklu  życiu, poprawianie implementacji jednostek systemu i wzbogacanie usług systemu w miarę odkrywania nowych wymagań.




alt
Rysunek 1 – Opracowanie własne na podstawie pracy [1]

 

  • Model przyrostowy 1980 rok

Wg pracy [2] model ten stosowany jest w praktyce modeli oraz metodyk iteracyjnych. W modelu dokonuje się dekompozycji przyszłego produktu na mniejsze fragmenty. Model wymusza konieczność stosowania dokładnych opisów poszczególnych interfejsów. Jako zaletę można wymienić łatwość implementacji w modelach kaskadowych i iteracyjnych. Patrząc na schemat widzimy, że formalnie faza testowania w ogóle nie jest uwzględniona. Nie jest to jednak prawdą. Oczywiście również w tym modelu testowanie ma miejsce. Każdy zrealizowany fragment oprogramowania jest testowany a następnie dostarczony klientowi.



alt
Rysunek 2 – Opracowanie własne na podstawie pracy [2]

 

  • V model 1980 rok

Wg autora pracy [2] w modelu tym wyeliminowano niemożność testowania produktu danej fazy. Prace nad tworzeniem oprogramowania według V-modelu wymuszają pracę dwóch zespołów: projektowego i testującego. Pierwszy zespół opracowuje produkty poszczególnych faz natomiast drugi zespół testuje produkt każdej fazy.


alt
Rysunek 3 – opracowanie własne na podstawie pracy [3]

 

  • W – model (zwany również modelem testowania)– początek lat 90-tych XX wieku

Na podstawie pracy [4] model ten określany jest jako przedstawiający zgodność testów i procesów rozwoju i tłumaczy podejście zaczerpnięte z  V-modelu. W modelu tym aktywności związane z przygotowywaniem testów są prowadzone równolegle do aktywności dotyczących definicji i specyfikacji wymagań oraz komponentów tworzonego systemu. Czynności przygotowawcze to te, które w procesie testowania  poprzedzają ich wykonywanie, są to np. planowanie, analiza i implementacja testów. Prawa gałąź V-modelu jest zazwyczaj podzielona na dwie różne czynności: wykonywanie testów oraz debuggowanie. To ostatnie jest często utożsamiane z testowaniem chociaż tak naprawdę są to dwie różne rzeczy wykonywane przez różnych ludzi. W ścisłym znaczeniu, testerzy są odpowiedzialni za wykonywanie testów, rejestrację testów oraz ich ocenę. W W-modelu testerzy są zaangażowani w aktywności rozwojowe zaraz na starcie projektu czyli n.p. zapoznają się z wymaganiami po to aby być w stanie wyspecyfikować odpowiednie przypadki testowe. Wg W-modelu pytania dotyczące testów akceptacyjnych powinny być zadane podczas przeglądu wymagań. Wymagania analizowane są nie tylko pod kątem dostępności dokumentacji ale również pod kątem tego czy są wystarczająco precyzyjnie określone tak aby można było przygotować odpowiednie przypadki testów akceptacyjnych. W przypadku W-modelu, wymagany jest udział dwóch project managerów, jeden ma być odpowiedzialny za testy natomiast drugi za wewnętrzny proces tworzenia systemu informatycznego/oprogramowania. Ponadto dobrą praktyką jest zaangażowanie trzeciego project managera który czuwałby nad całością.



alt

Rysunek 4 – opracowanie własne na podstawie pracy [4]

 

  • Model kaskadowy – rozbudowa testowania

W modelu tym  wg pracy [2] oprócz fazy testowania, dodany został element, który traktować można jako jedną z faz – plan testów.


alt
Rysunek 5 – opracowanie własne na podstawie pracy [2]

 

  • Model kaskadowy z iteracjami

W pracy [2] zaprezentowano również model kaskadowy z iteracjami. W modelu tym przyjmuje się założenia, że rezultaty żadnej fazy nie są kompletne i muszą ulegać modyfikacjom. Model dopuszcza konieczność zmiany wymagań oraz kosztu i czasu realizacji. Zastosowanie znalazł w skomplikowanych zagdanieniach, wieloaspektowych, prowadzących do złożonego systemu. W zależności od źródła przyjęte jest, że w modelu tym nie ma testowania a jedynie weryfikacja. Spotkać można również opis, że testowanie jest przedostatnim etapem wytwarzania oprogramowania w tym modelu.


alt
Rysunek 6 – opracowanie własne na podstawie pracy [2]

 

  • Model – Programowanie odkrywcze

Zaprezentowany w pracy [2] model stosowany jest w systemach z trudnymi do sprecyzowania wymaganiami, system tworzy się cyklicznie przy czym każdy cykl zostaje zakończony weryfikacją klienta. Model ten może być stosowany jako amatorski sposób tworzenia oprogramowania. Profesjonalnie stosuje się go w prototypowaniu. Wstępne testowanie systemu odbywa się zaraz po jego ogólnej budowie.


alt
Rysunek 7 – opracowanie własne na podstawie pracy [2]

 

  • Model konstrukcji prototypów

Model w pracy [2] stosowany jest w złożonych systemach o wymaganiach niejasnych lub wieloznacznych – system realizowany jest cyklicznie poprzez prototypy weryfikowane przez klienta. Prototypy tzw. prowizoryczne mogą być realizowane w małych kosztach i bardzo szybko. Zastosowana metodologia pozwala na weryfikację wymagań. Testowanie odbywa się po etapie implementacji systemu.


alt
Rysunek 8 – opracowanie własne na podstawie pracy [2]

 

  • Model spiralny 1998 roku

W pracy [1] autor opisuje, że model ten został opracowany przez Boehma w 1988 roku. Cztery główne fazy cyklu życia oprogramowania wykonywane są cyklicznie: analiza ryzyka, konstrukcja, atestowanie, planowanie.   

 


alt
Rysunek 9 – opracowanie własne na podstawie pracy [1]

 

  • Czym jest testowanie oprogramowania?

Zanim zostanie podana odpowiedź na pytanie czym jest testowanie oprogramowania, warto przytoczyć definicję takich pojęć jak weryfikacja i walidacja. Weryfikacja to wg autora pracy [5] potwierdzenie, poprzez przebadanie, i dostarczenie oczywistego dowodu, że konkretne wymagania zostały spełnione. W projektowaniu i w wytwarzaniu, weryfikacja dotyczy procesu badania wyniku danej aktywności w celu ustalenia zgodności z podanym dla tej aktywności wymaganiem. Walidacja natomiast, cytując za tym samym autorem [5], to potwierdzenie, poprzez przebadanie, i dostarczenie oczywistego dowodu, że konkretne wymagania w stosunku do specyficznego, zamierzonego użycia są spełnione. W projektowaniu i w wytwarzaniu, walidacja dotyczy procesu badania produktu w celu ustalenia jego zgodności z potrzebami użytkownika. Walidacja jest zwykle wykonywana dla produktu końcowego. Testowanie łaczy w sobie zarówno weryfikację jak i walidację oprogramowania. Testowanie oprogramowania wg definicji podanej przez [6] jest wykonaniem kodu dla kombinacji danych wejściowych i stanów w celu wykrycia błędów. Celem testów jest wykrycie błędów. Testowanie jest analizą dynamiczną ponieważ kod podlegający testowaniu jest wykonywany.

 

  • Zatwierdzanie oprogramowania – pięcioetapowy proces testowania według pracy [1]

W pracy [1] fazy procesu testowania przedstawione są w następujący sposób:

  1. Testowanie jednostek. W pierwszej fazie testuje się komponenty  aby zapewnić, że działają poprawnie. Każdy z komponentów testowany jest niezależnie bez udziału innych komponentów systemu.
  2. Testowanie modułów. Moduł stanowi kolekcję niezależnych komponentów takich jak klasy obiektów, abstrakcyjne typy danych czy też kolekcją funkcji i procedur. Ponieważ moduł zamyka w sobie powiązane komponenty, można go testować bez udziału innych modułów systemu.
  3. Testowanie podsystemów. W tej fazie odbywa się testowanie kolekcji modułów, które zintegrowano w podsystemie. Niezgodności interfejsów są jednym z problemów spotykanych w przypadku wielkich systemów. Proces testowania tej fazy powinien prowadzić do wykrycia błędów interfejsów.
  4. Testowanie systemu. Podsystemy zostały już zintegrowane w system. W tej fazie testowanie powinno wykryć błędy wynikające z nie przewidzianych interakcji pomiędzy podsystemami oraz problemy z interfejsami podsystemów. Weryfikacji podlega również funkcjonalność i niefunkcjonalność a dokładnie wymagania funkcjonalne i niefukcjonalne całego systemu.
  5. Testowanie odbiorcze. Końcowa faza procesu testowania przed przekazaniem systemu użytkownikowi. System testuje się wykorzystując zestaw danych otrzymanych od użytkownika. Ten etap testowania może wykryć błędy i niedopatrzenia w definicji wymagań stawianych systemowi. Ponad to ujawnione mogą zostać problemy polegające na tym, że udogodnienia systemu nie w pełni odpowiadają wymaganiom użytkownika lub efektywność systemu jest nie do zaakceptowania



alt
Rysunek 10 – opracowanie własne na podstawie pracy [1]

Zwykle za testowanie jednostek i modułów odpowiadają programiści, którzy utworzyli komponent  Opracowują oni kod i własne dane testowe. Ma to swoje ekonomiczne uzasadnienie, ponieważ programista tworzący dany komponent zna ten komponent najlepiej. Późniejsze fazy testowania obejmują integrację prac wielu programistów. Prace te należy zaplanować przed przystąpieniem do testów. Zaleca się aby testowanie wykonał niezależny zespół testerów na podstawie specyfikacji i przygotowanych scenariuszy testowych. Na rysunku (fazy testowania w procesie tworzenia oprogramowania) przedstawiono, jak plany testów stanowią połączenie między czynnościami tworzenia i testowania. Warto wspomnieć w tym miejscu o testach alfa i testach beta. Testowanie alfa to inaczej nazywane testowanie odbiorcze. W przypadku testów beta mamy do czynienia gdy do pewnej grupy użytkowników trafia produkt programowy. Użytkownicy informują wytwórców o problemach pojawiających się podczas użytkowania. Rozwiązanie takie sprawia, że produkt podlega prawdziwemu użytkowaniu i umożliwia wykrycie błędów, których nie przewidzieli projektanci i wykonawcy systemu. Po otrzymaniu zwrotnych informacji modyfikuje się system i  udostępnia do dalszego testowania beta lub do ogólnego użytku.
Podsumowując, widać z przedstawionych w tej pracy modeli, że znaczenie testowania w wytwarzaniu oprogramowania wzrasta. Najwięcej faz testowych zaprezentowano w W-modelu.


Autor: Sylwia Bartman
O autorze: Aktualnie pracuję jako Młodszy Tester Oprogramowania w warszawskiej firmie Mobica. Jestem na studiach trzeciego stopnia na Wydziale Inżynierii Produkcji Politechniki Warszawskiej. Z wykształcenia jestem chemikiem oraz informatykiem. Obszar wiedzy jakim jest testowanie, a zwłaszcza skuteczne zarządzanie procesem testowania, zainteresował mnie na tyle, że postanowiłam zmienić temat swojej rozprawy doktorskiej na taki, który dotyczyć będzie testowania. Powyższy tekst stanowi fragment przygotowywanego doktoratu.

Bibliografia i netografia:
[1] Ian Sommerville "Inżynieria oprogramowania", WNT, Warszawa 2003
[2] 26-Lis-2012 https://mail.pk.edu.pl/~mareks/modele.pdf
[3] 29-Lis-2012 http://www.nistep.go.jp/achiev/ftx/eng/stfc/stt029e/qr29pdf/STTqr2902.pdf
[4] A.Spillner, T.Rossner, M.Winter, T.Linz, "Software Testing Practice: Test Management", A Study Guide for the Certified Tester Exam ISTQB Advanced Level, 1st Edition 2007 by Rocky Nook Inc.
[5] Core Magazine "Zarządzanie procesem testowania oprogramowania" Marcin Towcik
[6] 26-Lis-2012 wazniak.mimuw.edu.pl/images/9/9b/Io-10-wyk.pdf

 

 

Najbliższe terminy szkoleń

 

15-16 stycznia - Wrocław

Automatyzacja testowania


22-24 stycznia - Poznań

ISTQB Poziom Podstawowy (Foundation Level)


25-26 stycznia - Wrocław

Dobry Przypadek Testowy - Laboratorium


26 stycznia - Katowice

Java dla testerów oprogramowania

 

Partnerzy

Narzędzia testerskie