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

Punkty widzenia

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

Testy jednostkowe i funkcjonalne w procesie tworzenia produktów cyfrowych

Zwinne organizacje | Blog o Agile

Głównym celem testów w procesach tworzenia produktów cyfrowych jest walidacja oraz weryfikacja wytworzonego oprogramowania. Wraz z coraz częstszym wykorzystywaniem metodyk zwinnych i zmianą podejścia do wytwarzania oprogramowania rola testów także ewoluowała. Kiedy zatem jest odpowiedni moment, by je przeprowadzić i jak wpływają na jakość naszych produktów?

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.

Korporacja ABC do obsługi swoich pracowników używa niezmiennie tego samego systemu od 8 lat. System posiada poniższe funkcjonalności:

  1. Obsługa procesu rekrutacji
  2. Obsługa naliczania pensji
  3. Obsługa planowania i rozliczania urlopów
  4. Obsługa systemu szkoleń wewnętrznych

Załóżmy, że z nowym rokiem mają wejść duże zmiany w prawie pracy, które wpłyną na dwie pierwsze funkcjonalności. Przy obecnym stanie systemu wprowadzanie jakichkolwiek zmian jest czasochłonne i kosztowne. Mając to na uwadze, zarząd firmy ABC podjął decyzję o wdrożeniu nowego systemu, który zastąpi dotychczasowy. Zgodnie z harmonogramem prace wdrożeniowe zaczęły się 1 kwietnia i zakończą się 31 grudnia 2019.

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.

Subskrybuj "CIO Insights"

Otrzymuj powiadomienia e-mail o nowych wydaniach tego newslettera

Zarejestruj się

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:

Kategoria
Model kaskadowy Model zwinny
Organizacja zespołu Niezależny zespół testowy Osoby testujące system częścią zespołu developerskiego
Okres testów Po zakończeniu implementacji przez zespół developerski Walidacja i weryfikacja w trakcie implementacji
Zakres testów Zespół testerski otrzymuje w pełni funkcjonalny, ukończony system Produkt dostarczany przyrostowo - zakres testów rośnie wraz ze złożonością projektu
Odpowiedzialność za jakość oprogramowania Wynik testów końcowych determinuje decyzję o wprowadzeniu systemu do użytku Zespół developerski jest w pełni odpowiedzialny, za jakość systemu
Wpływ testów na kształt projektu Ograniczony - w głównej mierze poprzez przegląd specyfikacji wymagań oraz zgłaszane sugestie w ostatniej fazie projektu Bliska kooperacja pomiędzy osobami testującymi a implementującymi, pozwalająca na dostosowanie produktu do oczekiwań użytkowników

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.

Autor:

Adrian Rogowski,
Ekspert w zespole doradztwa technologicznego, Deloitte

Czytaj blog Agile
„Zwinne organizacje”

Nie przegap najnowszych wpisów

Czy ta strona była pomocna?