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

CzytanQA: Steve Jobs

„Steve Job” autorstwa Waltera Isaacsona to dla mnie książka wyjątkowo z dwóch powodów. Po pierwsze, dostałam ją od bliskiej mi osoby. A po drugie dlatego, że to od niej zaczęło się moje zamiłowanie do biografii, reportaży i innych książek non-fiction.

CzytanQA: Labirynty Scruma

Scrumie książek napisano sporo. Dzisiejsza książka – Labirytnty Scruma – jest nieco inna, autor podchodzi do tematu od strony bardziej… problematycznej.

#3 Antywzorce w testowaniu oprogramowania: Korzystanie z niewłaściwego rodzaju testów

Wszyscy wiemy, jak z grubsza wygląda piramida testów: na dole jednostkowe, potem integracyjne, a szczytu akceptacyjne. Oznacza to po prostu tyle, że im wyżej w piramidzie, tym testów powinno być mniej… Ale mniej, to znaczy ile?

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!