Agile a testy. Kiedy jakość naszego produktu jest wyższa?

Walidacja polega na sprawdzeniu, czy tworzone oprogramowanie jest zgodne z oczekiwaniami użytkownika naszego systemu (najczęściej, jako testy akceptacyjne), zaś weryfikacja to sprawdzenie, czy dostarczone oprogramowanie spełnia zdefiniowane wymagania projektowe – testy jednostkowe, integracji, czy systemowe.
Aby lepiej zrozumieć jak zmieniła się rola testowania w cyklu życia projektu po przejściu z modelu kaskadowego na zwinny, posłużmy się przykładem.

Podejście kaskadowe

W przypadku podejścia kaskadowego w projekcie mielibyśmy następujący terminarz:

1. 01.04-31.05 – przygotowanie specyfikacji wymagań i projektu wdrożenia
2. 01.06-30.09 – implementacja rozwiązania
3. 01.10-31.10 – testowanie systemowe i integracyjne
4. 01.11-30.11 – testowanie akceptacyjne
5. 01.12-31.12 – uruchomienie produkcyjne

W tym podejściu testy jednostkowe i funkcjonalne zaczynają się wraz z rozpoczęciem fazy implementacji, więc na poziomie weryfikacji pojedynczych funkcjonalności z dość dużą dozą pewności jesteśmy w stanie określić jakość naszego produktu. System, jako działający produkt będzie gotowy 1 października. Wówczas zostanie przekazany niezależnemu zespołowi testerów i po zweryfikowaniu poprawności działania, trafi do końcowej akceptacji.
Powyższy plan wygląda na osiągalny i ułożony w logiczną całość i w przypadku, gdy nie ma nieprzewidzianych problemów oraz zmian w specyfikacji, projekt zapewne zakończyłby się sukcesem.
 

Co mogłoby zaburzyć idealnie ułożony plan?

Przyjrzyjmy się kilku z możliwych scenariuszy:

1. Zespół merytoryczny zgłasza istotny wniosek o zmianę (Change Request) w późnej fazie implementacji, gdyż zmieniła się interpretacja nowych przepisów prawa pracy. Przewidziany czas wdrożenia zaproponowanych zmian, to dodatkowe 3 tygodnie.
2. Jeden z dostawców informuje, że spóźni się o miesiąc z dostarczeniem implementacji modułu dotyczącego szkoleń.
3. Jeden z projektów wewnętrznych, mający podnieść atrakcyjność pracodawcy na rynku pracy, zakończył się w połowie września i każdy z implementowanych modułów wymaga zmian oszacowanych na dodatkowe 2 tygodnie pracy.

Każdy z tych przykładów ma oczywiście negatywny wpływ na zatwierdzony harmonogram prac, ale na pierwszy rzut oka nie jest to wpływ katastrofalny.
Warunki wejściowe dla testów systemowych i integracyjnych powinny być następujące:

1. System jest gotowy i wszystkie moduły są ze sobą zintegrowane.
2. Dane testowe są przygotowane i załadowane do systemu.
3. Plany testów, narzędzie do zarządzania testami i przypadki testowe są gotowe.

W trzech wyżej wymienionych scenariuszach, punkt z gotowością systemu nie został spełniony i zespół testowy musi poczekać dodatkowe parę tygodni, aż ten problem zostanie rozwiązany. Dodatkowo nasze testy akceptacyjne nie powinny rozpocząć się przed zakończeniem testów systemowych. Będąc w roli Project Managera oraz Komitetu Sterującego/Zarządu zostalibyśmy postawieni przed następującymi dylematami: Czy skrócić okres testów i wypuścić system na świat zgodnie z oczekiwaniami 1 stycznia 2020? Czy przyznać się do porażki projektu i postawić własną firmę w sytuacji braku działającego systemu do obsługi pracowników?
W takim wypadku najczęściej wybieranym rozwiązaniem, minimalizującym straty, jest wypuszczenie systemu, który nie jest dokładnie zweryfikowany i sukcesywne rozwiązywanie problemów, na które natknęli się użytkownicy końcowi. O ile nasz system miałby defekty w modułach, które nie są kluczowe (np. moduł do szkoleń wewnętrznych), to nie miałoby katastroficznego wpływu na działanie firmy. Ale co w przypadku, gdyby w styczniu pensje pracowników zostałyby naliczone niepoprawnie i większość pracowników otrzymałaby wypłaty znacznie różniące się od tych na umowie?
 

Podejście zwinne

Przejdźmy teraz do alternatywnej rzeczywistości, w której ten sam projekt byłby prowadzony w sposób zwinny. Zgodnie z dogmatami agile, oczekiwaniem jest posiadanie sprawnego systemu po każdym ze sprintów. Aby spełnić ten warunek musimy, oprócz developmentu nowego kodu, zaplanować również aktywności związane z utrzymaniem jakości.

Patrząc na schemat powyżej możemy dostrzec, że wraz z upływem czasu progres pracy następuje w każdym z obszarów – nie tylko związanym z wytwarzaniem oprogramowania, ale również weryfikacją jakości. W tym podejściu oczywiście możemy priorytetyzować pracę, np. skupić się w pierwszych miesiącach trwania projektu na kluczowym module wyliczania wypłat, a w module szkoleń zapewnić tylko podstawową funkcjonalność, która będzie wystarczająca dla użytkownika przez pierwsze miesiące po wdrożeniu. Na każdym etapie projektu następuje jednak sprawdzenie, czy przygotowane rozwiązanie jest działającym produktem.

Mając to na uwadze zastanówmy się czy podejście zwinne pomogłoby rozwiązać sytuację z pierwszej części artykułu.

1. Change Request w połowie września 2019 – elastyczność do wdrażania zmian w projekcie, to jeden z elementów agile. Testy integracyjne i akceptacyjne nie są opóźnione z racji włączenia ich w sprinty.
2. Opóźnienie modułu szkoleń – stosując się do najlepszych praktyk agile budujemy system w sposób zintegrowany – dzięki temu możemy ograniczyć liczbę funkcjonalności, a wszystkie już zaimplementowane są możliwe do przetestowania.
3. Wpływ innego projektu wewnętrznego – podobnie jak w pierwszym punkcie, po ocenie wpływu zmiany na projekt, zmieniamy priorytetyzację produktów pracy, aby dostosować się do nowych wytycznych. 
    

Co jest niezbędne, by dobrze przeprowadzić testy?

Wracając do naszego systemu HR. Kluczowe, w przypadku testów tego typu systemu, są dobrze przygotowane dane testowe. Zapewnienie odpowiedniej ilości rekordów, by sprawdzić czy pracownicy wszystkich szczebli otrzymają prawidłowe wypłaty i dodatki do pensji, lub przygotowanie hierarchii pracowniczej, pozwalającej na realizację procesów biznesowych, może być pracochłonne.

W przypadku podejścia kaskadowego - zewnętrzny zespół testerów i testy akceptacyjne wykonywane przez osoby niezaangażowane w przygotowanie implementacji, może utrudnić ich wykonywanie, np. przez brak zrozumienia, jak dany system działa, czy trudności w rozróżnieniu defektu od źle przygotowanych danych testowych.
W metodzie zwinnej jest jeden zespół do całej implementacji – osoby testujące, analitycy biznesowi i programiści pracują blisko ze sobą zarówno nad przygotowaniem danych, jak i pełnym zrozumieniem procesów biznesowych, które nasze wdrożenie ma rozwiązać.

W powyższych przypadkach widać, że elastyczność przy wdrażaniu zmian i możliwość szybkiej reakcji na nieprzewidziane zdarzenia jest po stronie podejścia zwinnego. Dodatkowo można zaobserwować, że przy agile temat „czy uda nam się przetestować” schodzi na boczny tor i przeradza się w pytanie „czy uda nam się dostarczyć działający produkt”. Dzięki zintegrowaniu testów ze sprintami znika pojęcie zespołu testowego, a wszyscy są zespołem developerskim. Aktywności Quality Assurance stają się oczywistym narzędziem, pomocnym przy tworzeniu produktu, a nie kolejnym check pointem do odhaczenia.

Różnice pomiędzy testami w modelu kaskadowym a zwinnym:

Jedną z aktywności w trakcie testowania jest oczywiście zgłaszanie znalezionych defektów w systemie. Wraz ze wzrostem złożoności systemu rośnie czas i koszt rozwiązania takich błędów. Jeśli dodamy też niezależność zespołu testowego, sporo defektów może się rozbijać się o legendarne tłumaczenie: „przecież to jest zaimplementowane zgodnie ze specyfikacją”. Etap testów może być zbyt późnym momentem na wdrożenie ułatwiających użytkowanie zmian. Z drugiej strony – niezależność może czasami powodować brak zrozumienia naszego systemu przez zespół testerów. Problem ten mitygujemy w metodykach zwinnych poprzez wczesne włączenie testów przy budowaniu naszego produktu – redukujemy zarówno czas zaimplementowania poprawek, pracujemy razem nad jak najbardziej sprawnym systemem i dajemy sobie więcej elastyczności na wdrażanie zmian.
 

Kiedy jakość naszego produktu jest wyższa?

Odpowiedź na pytanie postawione w tytule nie jest jednoznaczna. Jeśli nasz projekt prowadzony jest modelem kaskadowym, nie ma w nim większych zmian i wszystko idzie zgodnie z planem, to nie powinniśmy zauważyć większej różnicy w jakości naszego produktu względem projektu prowadzonego zwinnie.

Jeśli jednak nasze plany zostaną z jakichś powodów zmienione, to podejście agile daje nam dużo większą elastyczność i możliwość bardzo wczesnego włączenia aktywności testowych w proces wytwarzania naszego produktu. Dodając do tego inne aktywności wynikające z modelu zwinnego, jak na przykład Continuous Integration, czyli regularne budowanie zintegrowanego produktu wraz z przeprowadzaniem automatycznych testów w trakcie tej czynności, ograniczamy możliwość prześlizgnięcia się defektów do dalszych etapów przygotowania projektu.

Podejście zwinne ma niewątpliwe zalety nad metodykami kaskadowymi, jednak wymaga też całkowitej zmiany sposobu organizacji pracy. Dlatego przed podjęciem decyzji o prowadzeniu projektu metodami zwinnymi, trzeba rozważyć wiele aspektów organizacyjnych w modelu pracy – jak ocena dojrzałości organizacji i zespołu projektowego, analiza typów oraz charakterystyk projektów. Taka analiza powinna być pierwszym krokiem przed podjęciem decyzji o pracy w modelu zwinnym.