Redakcja
Wodospad (Waterfall)
Model wodospadowy jest jednym z pierwszych formalnych opisów projektów informatycznych. Jest to prosta próba przedstawienia czynności w projekcie, gdzie dwie najważniejsze fazy, tworzenie i weryfikacja, następują po sobie. W uproszczeniu najpierw tworzony jest system lub oprogramowanie, a dopiero potem następują testy. Model ten ma wielu przeciwników, krytykujących przede wszystkim długi czas od definiowania potrzeby do dostawy.
Model V
Pierwszym stadium tworzenia oprogramowania w modelu V jest "idea". Kiedy podejmiemy decyzję, że będziemy daną ideę realizować w postaci oprogramowania, "wchodzimy" w model V i fazę projektową. Analizę modelu dokonamy na przykładzie programu „Przypominacz”. Jego podstawowym założeniem będzie, jak nie trudno się domyślić, przypominanie o wydarzeniach. Musimy zacząć od wymagań: O czym ma nam przypominać? Jak ma przypominać? Jakie parametry można w nim ustawić?, itp. Stworzone wymagania są podstawą do rozpoczęcia definiowania zakresu weryfikacji. Wiedząc, co chcemy osiągnąć możemy określić, jak chcemy to sprawdzić i skąd będziemy wiedzieli, że to działa. Pierwszy i podstawowy test to sprawdzenie (jeśli program się uruchomi), czy przypominacz przypomina.
Wymagania podlegają analizie, podczas której zespoły architektów czy programistów decydują, czy dana idea jest możliwa do zrealizowania. Czy da się zaimplementować wszystkie wstępne założenia? Ważne, choć niestety rzadko stosowane, jest to, aby w procesie analizy uczestniczyli testerzy, którzy na poziomie weryfikacji mogliby zacząć tworzyć podwaliny testowania systemowego.
Następnie do gry wchodzą architekci projektu, dzieląc go na poszczególne komponenty (architektura komponentu). Tworzą oni specyfikację, będącą informacjami wejściowymi dla programistów oraz testerów. Każdy projekt ma swoje interfejsy, które pozwolą mu np. współpracować z systemem operacyjnym. Z kolei każdy komponent może być poddany osobnemu sprawdzeniu zanim zostanie zintegrowany w całość. Tu pojawiają się pojęcia testowania interfejsów i komponentów.
Implementacja jest teoretycznym końcem fazy projektowej (lewego ramienia litery V). Prawe ramię, czyli weryfikacja to, najprościej rzecz ujmując, sprawdzanie, czy założenia zostały spełnione; poczynając od sprawdzania najmniejszych komponentów na całym zintegrowanym systemie kończąc. Testy końcowe to zazwyczaj tzw. testy akceptacyjne, odpowiadające na pytanie, czy dany produkt spełnia wymagania klienta. W naszym przypadku jest to sprawdzenie, czy przypominacz zachowuje się tak, jak zakładaliśmy to sobie na początku.
Model V precyzyjnie pokazuje zależności, jakie powinny łączyć kolejne etapy projektu. Każdy etap projektowania kończy się tworzeniem danych wejściowych do następnej fazy oraz do korespondującej z nią fazy weryfikacji.
Zachęca się do jak najwcześniejszego rozpoczynania procesu tworzenia planów testów, specyfikacji testowej i samego testowania.
Model V ciągle jest jednym z najważniejszych modeli tworzenia oprogramowania. Choć mało szczegółowy i mało wydajny, daje przykład idealnego świata kooperacji między architektami, programistami, testerami i odbiorcami. Jest niedoścignionym wzorcem, o którym każdy człowiek chcący zajmować się oprogramowaniem powinien przynajmniej wiedzieć.
Model iteratywny
Rozwój oprogramowania oparty na metodach iteratywnych jest procesem ustalania wymagań, projektowania, budowania i testowania systemu poprzez podzielenie całego procesu na mniejsze elementy. Wyróżniamy dwa główne nurty: inkrementację, czyli wzrost oprogramowania poprzez dodawanie małych cząstek oraz nurt ewolucyjny, czyli stopniowy.
Przykłady: procesy prototypowe, szybki rozwój aplikacji (ang. RAD), zunifikowany proces firmy Rational (RUP), metodyka Agile.
Efekt iteracji może być testowany na różnych poziomach rozwoju oprogramowania. Elementy dodane do procesu wcześniej tworzą cały system, który również musi zostać przetestowany. Szczególnie ważne jest testowanie regresyjne po każdej iteracji. Weryfikacja i walidacja mogą również być włączone w każdą inkrementację.
Testowanie w różnych modelach cyklu życia oprogramowania
Podstawowe cechy dobrego testowania dopasowane do modelu jego wytwarzania:
- każdy poziom testowy ma określone cele,
- analiza i projektowanie testów dla konkretnego poziomu powinny rozpoczynać się wraz z odpowiadającym im poziomem projektowania,
- tester powinien być zaangażowany w przegląd dokumentów, od momentu pojawienia się ich pierwszych szkiców.
Poziomy testowe mogą być łączone i reorganizowane w zależności od natury projektu lub architektury systemu. Przykładowo: integracja komercyjnego oprogramowania prosto z półki sklepowej z systemem. Klient kupujący taki produkt sam i w tym samym czasie wykonuje testy integracji w systemie (np. integracja z infrastrukturą i innymi systemami) oraz testy akceptacyjne (funkcjonalne i niefunkcjonalne).
Temat modeli w ten sam sposób omawiamy podczas szkolenia ISTQB Poziom Podstawowy.
Inne podejście do opisów modeli wytwórczych znajdziecie w publikacji "Miejsce testowania w modelach cyklu tworzenia oprogramowania".
