Testowanie a Continuous Delivery – cz.1

3 marca 2018 | Zwinny tester

Wielu z Was, tak jak i ja, pracuje w metodach zwinnych: w coraz bardziej popularnym Scrumie i Kanbanie, innym pewnie nieobcy jest XP, coraz więcej firm eksperymentuje z modelem Spotify. I nie ma w tym nic dziwnego, skoro metody zwinne niemalże powszechnie uważane są za najbardziej efektywne podejście do wytwarzania oprogramowania, w wielu organizacjach osiągając poziom sposobu na życie 🙂

Aby korzyści z agile’a były jak największy konieczne jest przetestowanie oprogramowania niemal w tym samym czasie, w jakim zostało ono zbudowane. Wczesne testowanie („Shift left” lub „Early testing”) pozwala na znaczne zwiększenie jakości oprogramowania, tym samym zmniejszając jego podatność na błędy. Wraz z takim pojawiło się, i ciągle rośnie, zapotrzebowanie na procesy ciągłej integracji i ciągłego dostarczania (CI/CD) – to właśnie one umożliwiają bezproblemowe działania związane z budowaniem, testowaniem i wydaniem. Ale… czy jest tu w ogóle miejsce na testy manualne? Jeśli tak, to gdzie?

Skąd w ogóle takie pytanie? Ponieważ to pełna automatyzacja jest kluczem do implementacji CD i jest stosowana na każdym etapie cyklu życia wytwarzanego produktu. Praktykowanie CI zapewnia weryfikację i – jak sama nazwa wskazuje – integrację każdego fragmenty kodu dzięki automatycznie wykonywanym budowaniu i testom. Zapewnia to szybkie wykrywanie defektów i szybką reakcję zwrotną. Integracja i dostarczanie wykonują się automatycznie, „triggerem” jest wypchnięcie zmian do repozytorium, a reszta… „dzieje się sama”.

Choć jednak automatyzacja jest w centrum uwagi i jest bardzo istotna w przyspieszaniu i ulepszaniu procesu, to jednak istnieją takie rodzaje testów, których zautomatyzować się nie da. „Automaty” są świetnym ułatwieniem, ale jednak pozbawione są cech, które charakterystyczne są tylko dla ludzi: obserwacji, analizy i myślenia krytycznego. Oczywiście wszystko to może się zmienić wraz z rozwojem sztucznej inteligencji i samouczących się systemów. Maszyna po prostu robi co jej narzucimy, ale nie tworzy własnych scenariuszy testowych i nie przewidzi każdego zachowania użytkownika.

Niemożliwa jest więc automatyzacja testów eksploracyjnych i ad-hoc – muszą one być wykonane przez człowieka. Tym bardziej, że na etapie pisania testów automatycznych zwykle skupiamy się na najbardziej oczywistych ścieżkach, a dopiero wspomniana eksploracja pozwala nam „zaszaleć” i wczuć się w rolę użytkownika. Niemożność wczucia się w pozycję użytkownika przez automaty sprawia, że również testy użyteczności są wykonywane manualnie – niejednokrotnie zdarzało mi się, że testy automatyczne przeszły, funkcjonalność działała zgodnie z założeniami, ale była zupełnie nieintuicyjna.

Kolejny problem może wynikać z faktu, że automatyzacja potrzebuje czasu. Stworzenie dobrych „automatów” potrafi zająć mi czasem jeden czy dwa dni, podczas gdy sama funkcjonalność powstała w ciągu 2-3 godzin. Testując manualnie mogę dać szybki feedback koledze z zespołu odnośnie działania nowego fragmentu programu nie blokując tym samym czyjejś pracy, a ten swoisty dług technologiczny nadrobić już po testach manualnych lub czasem nawet już poza zakresem danego zadania. Trzeba też pamiętać, że nawet malutka zmiana w interfejsie może sprawić, że testy automatyczne stają się nieprzydatne. W sytuacji kiedy rzecz dotyczy pilnej zmiany wykonanie testów manualnie i zaciągnięcie takiego testowego długu może znacznie przyspieszyć wypchnięcie poprawek i tym samym oszczędzić sporo strat. W praktyce więc praca nad jednym zadaniem to ciągłe testowanie manualne przetykane pisaniem „automatów”.

I to by było na tyle w dzisiejszym wpisie, ale… to tak naprawdę wstęp do tryptyku. W kolejnej części napiszę o różnicach pomiędzy Continuous Integration, Continuous Delivery oraz Continuous Deployment, narzędziach jakie są w nich wykorzystywane oraz jak do tych praktyk mają się testy. W ostatniej części opiszę Wam, jak wyglądają moje doświadczenia w tym zakresie.

Najnowsze wpisy

#1 Antywzorce w testowaniu oprogramowania: Testy jednostkowe bez testów integracyjnych

Dziś porozmawiamy sobie o tym, dlaczego posiadanie testów jednostkowych z pominięciem testów integracyjnych to nie najlepsza praktyka.

CzytanQA: Urobieni. Reportaże o pracy

Nie samymi technologicznymi książkami żyje człowiek. Dziś chcę Wam polecić książkę, które zrobiła na mnie wrażenie większe, niż wiele innych przeczytanych w ostatnim czasie.

Antywzorce w testowaniu oprogramowania

Ostatnio przegrzebując Internety trafiłam na bloga Kostisa Kapelonisa gdzie znalazłam obszerny artykuł o antywzorcach w testowaniu oprogramowania. Dziś krótko na ten temat.

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!