Wczesne testowanie obniża koszty

W fazie początkowej i planowania sprintu definiowane są kryteria akceptacji, tj. ustalane jest, co należy przetestować zgodnie z wymaganiami. Kryteria akceptacji stanowią podstawę dla przeprowadzanych testów. W każdym nowym sprincie kryteria i testy są odpowiednio uzupełniane. Cele testów i możliwe pomysły na testy są podsumowywane w karcie testów.

Następnie rozpoczyna się sprint i przygotowywane są wszystkie odpowiednie testy, tj. dostarczane są dane testowe i środowisko testowe, a następnie przeprowadzane są testy. Odbywa się to równolegle z rozwojem funkcji. Podczas codziennych Scrumów, blokady testowe lub przeszkody testowe są omawiane z zespołem Scrum. Błędy wykryte podczas testów są natychmiast naprawiane.

Deweloperzy tworzą testy jednostkowe i wykonują je w oparciu o test-driven development, podstawową technikę programowania ekstremalnego. Testy są konsekwentnie pisane przed komponentami, które faktycznie mają być testowane (test-first). Dzięki refaktoryzacji w odpowiednim czasie, skupiamy się na tym, co najważniejsze i nie tworzymy niepotrzebnego kodu z wyprzedzeniem. Kod i przypadki testowe są sprawdzane dopiero po pomyślnym zakończeniu lokalnych testów jednostkowych, zapewniając w ten sposób, że wszystko działa idealnie, zanim trafi do kompilacji. Cały kod jest zintegrowany z kompilacją i testowany razem. Odbywa się to kilka razy dziennie w “codziennej kompilacji”, która jest automatycznie testowana w potoku ciągłego dostarczania przed wydaniem.

Potok ciągłego dostarczania obejmuje ciągłą integrację, dostarczanie i wdrażanie i jest często określany jako potok CI/CD. Potok CI/CD jest częścią większego łańcucha narzędzi, który obejmuje zautomatyzowane testowanie i zarządzanie wersjami. Potoki ciągłego dostarczania przenoszą kod aplikacji od dewelopera do użytkownika, a automatyzacja testów jest podstawą wszystkich nowoczesnych potoków dostarczania. Po udanych testach jednostkowych deweloper sprawdza nowy/zaktualizowany kod i rozpoczyna się seria testów automatycznych. Powinny one obejmować testy integracyjne, a także testy systemowe z testami funkcjonalnymi i niefunkcjonalnymi, które sprawdzają na przykład wydajność, sieć, zewnętrzne interfejsy API, zależności i bezpieczeństwo. Zapobiega to publikowaniu niestabilnego, ryzykownego lub niezabezpieczonego kodu i udostępnianiu go użytkownikom. Zautomatyzowany proces kompilacji rozpoczyna się dopiero po pomyślnym zakończeniu tych testów. W szczególności testy niefunkcjonalne mają długi czas działania, więc nie ma sensu planować wszystkich testów dla każdej codziennej kompilacji, ale określić ich wybór. Wszystkie bardziej złożone testy można przeprowadzać na przykład co tydzień lub przed konkretnym wydaniem. To samo dotyczy testów integracji systemu, które również powinny być testowane tylko wtedy, gdy jest to konieczne – na przykład podczas podłączania nowego interfejsu do systemu.

W sprincie poprzedzającym wydanie, testy systemu odbywają się w środowisku produkcyjnym, ewentualnie z testem akceptacyjnym przeprowadzanym przez dział specjalistyczny. Gdy testy te zostaną pomyślnie zaakceptowane, produkt jest przekazywany do DevOps (Development Operations) lub ITIL (Information Technology Infrastructure Library) w celu zwolnienia do środowiska produkcyjnego. Jednostki centralne zapewniają usługi międzyzespołowe z podstawowymi zadaniami związanymi z testami, takimi jak zapewnienie środowisk testowych i danych testowych, utrzymanie narzędzi testowych lub połączenie z innymi aplikacjami.

Oczywiście istnieją również znaczące różnice w automatyzacji testów w podejściu zwinnym w porównaniu z podejściem klasycznym. W klasycznych projektach, które są zorganizowane zgodnie z modelem kaskadowym lub V, obszerna faza testowa jest zwykle wymagana tylko na końcu projektu. Z kolei w projektach zwinnych oprogramowanie musi być poddawane fazie testów i kontroli jakości po każdym sprincie.

W przeciwieństwie do wspomnianych powyżej podejść sekwencyjnych, wprowadzenie testów automatycznych jest warunkiem wstępnym udanego projektu w projektach zwinnych. W miarę jak oprogramowanie rozwija się po każdym sprincie, liczba testów i wysiłek związany z testowaniem również wzrastają. Aby zapewnić jak największe pokrycie testami oprogramowania w trakcie trwania projektu, należy od samego początku zaplanować rozwój frameworka do automatyzacji testów i potoku CI/CD. Nawet jeśli zakres testów jest mniejszy na początku projektu, a testy są ograniczone do niższych poziomów testowych dla testów komponentów i modułów, kryteria ramowe zdefiniowane z wyprzedzeniem stanowią podstawę udanego wdrożenia.

Fakt, że zwinny projekt nie jest wykonalny bez automatyzacji testów, staje się jasny najpóźniej na etapie testów systemowych. W każdym sprincie nie tylko nowe funkcje są sprawdzane w teście systemu, ale wszystkie poprzednie funkcje muszą być również brane pod uwagę jako test regresji. Podczas gdy programiści mogą nadal być w stanie przeprowadzić test modułu po każdym sprincie, ręczne testowanie systemu wykraczałoby poza zakres zwinnego projektu pod względem wysiłku, czasu i budżetu. Opracowane oprogramowanie zwiększa swoją funkcjonalność i złożoność z każdym sprintem – ale liczba i złożoność testów, zwłaszcza testów systemowych, wzrasta w tym samym stopniu. Wysiłek związany z testowaniem można znacznie zmniejszyć dzięki automatyzacji testów i działającemu potokowi CI/CD.

Pracownicy zwykle nie mają wystarczająco dużo czasu na ręczne testowanie systemu po każdym sprincie. Pod koniec zwinnego projektu bez automatyzacji testów mogą nagle i nieoczekiwanie pojawić się błędy. Dlatego tym ważniejsze w zwinnych projektach jest wdrożenie zautomatyzowanej i ustrukturyzowanej struktury testowej od samego początku, która rozwija się wraz z oprogramowaniem. Nie zapominajmy też, że im wcześniej rozpocznie się testowanie, tym wcześniej będzie można naprawić ewentualne błędy i tym niższe będą koszty całego procesu rozwoju.