Witaj w drugim rozdziale naszego kursu przygotowującego do egzaminu ISTQB Poziom Podstawowy!

W poprzednim rozdziale zgłębiliśmy fundamentalne koncepcje testowania, jego cele, zasady oraz podstawowy proces.

Teraz przeniesiemy naszą uwagę na szerszy kontekst – jak testowanie wpisuje się w cały cykl życia oprogramowania, znany jako SDLC (Software Development Lifecycle).

Zrozumienie tej relacji jest kluczowe, ponieważ model wytwarzania oprogramowania, który wybiera organizacja, ma bezpośredni i znaczący wpływ na to, jak, kiedy i przez kogo przeprowadzane są testy.

Czym jest Model Cyklu Życia Oprogramowania (SDLC)?

Zanim zagłębimy się w szczegóły, zdefiniujmy, czym właściwie jest model cyklu życia oprogramowania.

SDLC to strukturalne podejście, swoista mapa drogowa, która opisuje poszczególne fazy i czynności zaangażowane w proces tworzenia, wdrażania i utrzymania systemu informatycznego.

Można go postrzegać jako abstrakcyjne odwzorowanie całego procesu, od pomysłu po wycofanie produktu z użytku.

Model ten określa nie tylko sekwencję działań, ale także wzajemne powiązania między nimi – zarówno logiczne, jak i chronologiczne.

Wybór odpowiedniego modelu SDLC jest jedną z fundamentalnych decyzji w każdym projekcie IT, ponieważ wpływa na organizację pracy, zarządzanie ryzykiem, komunikację w zespole i, co dla nas najważniejsze, na strategię i realizację testów.

Istnieje wiele różnych modeli SDLC, a każdy z nich ma swoje specyficzne cechy, zalety i wady.

Możemy je ogólnie podzielić na kilka głównych kategorii, które warto znać, przygotowując się do egzaminu ISTQB:

Sekwencyjne modele wytwarzania oprogramowania:

Te modele charakteryzują się liniowym, uporządkowanym przepływem pracy, gdzie każda faza musi zostać formalnie zakończona i zatwierdzona przed rozpoczęciem następnej.

Przypomina to wodospad, stąd nazwa najpopularniejszego modelu – kaskadowego (Waterfall).

Innym znanym modelem sekwencyjnym jest model V, który wyraźnie pokazuje powiązanie między fazami wytwarzania a odpowiadającymi im poziomami testów.

W tych modelach wymagania są zazwyczaj definiowane na początku i oczekuje się, że pozostaną stabilne przez cały projekt.

Testowanie w modelach sekwencyjnych często koncentruje się w późniejszych fazach, po zakończeniu implementacji kodu.

Chociaż testerzy mogą uczestniczyć we wcześniejszych przeglądach dokumentacji, główne działania związane z testowaniem dynamicznym (uruchamianiem oprogramowania) odbywają się dopiero po fazie kodowania.

Iteracyjne modele wytwarzania oprogramowania:

W przeciwieństwie do modeli sekwencyjnych, modele iteracyjne polegają na tworzeniu oprogramowania w powtarzalnych cyklach, zwanych iteracjami.

Każda iteracja obejmuje wszystkie kluczowe czynności: planowanie, analizę, projektowanie, implementację i testowanie.

Wynikiem każdej iteracji jest działający, choć niekoniecznie kompletny, prototyp lub wersja produktu.

Pozwala to na stopniowe rozwijanie systemu i zbieranie informacji zwrotnych od użytkowników lub interesariuszy na wcześniejszych etapach.

Przykładami modeli iteracyjnych są model spiralny, który kładzie duży nacisk na zarządzanie ryzykiem, oraz prototypowanie, gdzie szybko tworzy się uproszczone wersje systemu w celu weryfikacji koncepcji lub wymagań.

W modelach iteracyjnych testowanie jest integralną częścią każdej iteracji, co umożliwia wczesne wykrywanie i naprawianie błędów.

Przyrostowe modele wytwarzania oprogramowania:

Modele te są blisko związane z iteracyjnymi, ale główny nacisk kładą na dostarczanie funkcjonalności w małych, użytecznych częściach, zwanych przyrostami.

Każdy przyrost dodaje nową, działającą funkcjonalność do systemu, który stopniowo rośnie.

Podobnie jak w modelach iteracyjnych, każda faza tworzenia przyrostu obejmuje planowanie, analizę, projektowanie, kodowanie i testowanie.

Model Unified Process (UP) jest często podawany jako przykład modelu łączącego cechy iteracyjne i przyrostowe.

Testowanie w modelach przyrostowych odbywa się w ramach tworzenia każdego przyrostu, co również sprzyja wczesnemu wykrywaniu defektów i regularnemu dostarczaniu wartości.

Warto również wspomnieć, że oprócz tych ogólnych modeli, istnieje wiele bardziej szczegółowych metodyk i praktyk, często kojarzonych z podejściem zwinnym (Agile), które również wpływają na cykl życia i testowanie.

Należą do nich między innymi: Scrum (framework zarządzania projektami oparty na iteracjach zwanych sprintami), Kanban (metoda wizualizacji przepływu pracy i ograniczania pracy w toku), eXtreme Programming (XP) (zestaw praktyk inżynierskich, w tym silny nacisk na testowanie), Test-Driven Development (TDD) (pisanie testów przed kodem), Behavior-Driven Development (BDD) (opisywanie zachowania systemu w sposób zrozumiały dla biznesu) czy Acceptance Test-Driven Development (ATDD) (wspólne definiowanie kryteriów akceptacji w formie testów).

Te zwinne podejścia kładą nacisk na elastyczność, szybkie dostarczanie wartości, bliską współpracę w zespole i ciągłe testowanie jako nieodłączny element procesu wytwarzania.

Wpływ Wybranego Modelu SDLC na Testowanie

Jak już podkreśliliśmy, wybór modelu SDLC ma fundamentalne znaczenie dla procesu testowania.

Nie można po prostu zastosować uniwersalnej strategii testowej – musi ona być starannie dopasowana do specyfiki przyjętego cyklu wytwarzania.

Zastanówmy się, na jakie konkretnie aspekty testowania wpływa model SDLC, co jest kluczowe z perspektywy egzaminu ISTQB:

Zakres i czas wykonywania czynności testowych:

To jeden z najbardziej widocznych wpływów.

W modelach sekwencyjnych, takich jak Waterfall czy V-Model, główne fazy testowania (np. testy systemowe, testy akceptacyjne) odbywają się zazwyczaj pod koniec projektu, po zakończeniu implementacji.

Testerzy mogą być zaangażowani wcześniej w przeglądy dokumentacji (np. wymagań, projektu), co jest formą testowania statycznego, ale testowanie dynamiczne (uruchamianie kodu) jest możliwe dopiero na późniejszych etapach.

To może prowadzić do późnego wykrywania błędów, co jest kosztowne.

W modelach iteracyjnych i przyrostowych, a zwłaszcza w podejściach zwinnych, testowanie jest czynnością ciągłą, rozłożoną na cały cykl życia.

W każdej iteracji lub przyroście wykonuje się różne poziomy (np. modułowe, integracyjne, systemowe) i typy testów (np. funkcjonalne, niefunkcjonalne).

Pozwala to na wczesne wykrywanie błędów i szybkie dostarczanie informacji zwrotnych do zespołu deweloperskiego.

Szczegółowość dokumentacji testów (Testware):

Modele sekwencyjne często wymagają tworzenia bardziej formalnej i szczegółowej dokumentacji testowej (plany testów, przypadki testowe, raporty).

Wynika to z potrzeby precyzyjnego zdefiniowania zakresu testów przed ich rozpoczęciem i udokumentowania wyników dla formalnej akceptacji oraz śledzenia postępów.

W podejściach zwinnych preferuje się lżejszą, bardziej pragmatyczną dokumentację.

Nacisk kładzie się na działające oprogramowanie i bezpośrednią komunikację, a dokumentacja jest tworzona tylko wtedy, gdy przynosi realną wartość (np. dla celów audytu, przekazania wiedzy).

Przypadki testowe mogą być mniej formalne, zapisane w narzędziach do zarządzania testami, a czasem zastępowane przez listy kontrolne (checklists) lub testy eksploracyjne.

Poziom niezależności testowania:

W modelach sekwencyjnych często występuje większy stopień niezależności testowania.

Może istnieć oddzielny zespół testowy, który otrzymuje gotowy produkt do weryfikacji.

W podejściach zwinnych preferuje się mniejszą niezależność, ale większą współpracę.

Testerzy są integralną częścią zespołu deweloperskiego, pracując ramię w ramię z programistami i analitykami.

Chociaż pewien poziom niezależności (np. inna osoba testuje kod niż go napisała) jest nadal zalecany, nacisk kładzie się na wspólną odpowiedzialność za jakość.

Role i odpowiedzialności:

W modelach sekwencyjnych role są często bardziej wyspecjalizowane i oddzielone (np. analityk, programista, tester, kierownik testów).

W podejściach zwinnych role mogą być bardziej płynne, a członkowie zespołu często posiadają szerszy zakres umiejętności (tzw. T-shaped skills) i wspólnie realizują zadania, w tym testowanie.

Odpowiedzialność za jakość jest bardziej rozproszona.

Zarządzanie zmianą:

Modele sekwencyjne słabo radzą sobie ze zmianami wymagań w trakcie projektu.

Każda zmiana może wymagać powrotu do wcześniejszych faz i ponownego wykonania wielu czynności, w tym testów.

Modele iteracyjne i zwinne są zaprojektowane tak, aby łatwiej adaptować się do zmian.

Zmiany mogą być wprowadzane w kolejnych iteracjach, a ciągłe testowanie pomaga szybko ocenić ich wpływ i zapewnić, że nie wprowadzają regresji.

Podsumowanie

Model cyklu życia oprogramowania (SDLC) stanowi ramy dla procesu wytwarzania oprogramowania i ma kluczowy wpływ na strategię i realizację testów.

Modele sekwencyjne (np. Waterfall, V-Model) charakteryzują się liniowym przepływem i koncentracją testowania w późniejszych fazach.

Modele iteracyjne i przyrostowe (w tym podejścia zwinne jak Scrum, Kanban) opierają się na cyklach i ciągłym testowaniu w ramach każdej iteracji/przyrostu.

Wybór modelu wpływa na czas i zakres testów, szczegółowość dokumentacji, poziom niezależności oraz role i odpowiedzialności w zespole.

Zrozumienie tych zależności jest niezbędne dla efektywnego planowania i przeprowadzania testów w danym kontekście projektowym.