Testuj i automatyzuj

Dla wielu ten temat wydawać może się dość oczywisty, jednakże, jak sam wielokrotnie miałem okazję się przekonać, rzeczywistość wcale nie jest tak różowa. Dalibóg, nie spodziewałbym się, że wciąż jest w tej materii tak wiele do zrobienia, do zdziałania. A naprawdę wystarczy zrobić tak niewiele, aby wyjść z marazmu, stagnacji, pokonać waterfallową grawitację i wystrzelić na orbitę zwinności. A następnie z góry spojrzeć na Olimp i spożywając ambrozję, oglądać sukces swej organizacji. Zapędziłem się? Może trochę…

Znacie? To posłuchajcie! Dobrze zbudowany – i charakterologicznie, i kompetencyjnie – zespół deweloperski, składający się ze zmotywowanych, zdolnych, pełnych pasji ludzi. Ale – coś nie działa. Na koniec sprintu dominującym statusem jest “prawie skończone”, nie za wiele można pokazać na przeglądzie, ale brakuje naprawdę niewiele, zostały przysłowiowe szlify. Niezadowolenie całej grupy skupia się na cichym człowieku, który czerwony jak cegła, spocony jak pies, z podkrążonymi oczami przeklikuje się przez kolejne funkcjonalności i wpisuje do JIRY kolejne zgłoszenia, bo wystarczy zmodyfikować ID w adresie i już jest tam, gdzie nie powinien, sięgając tam, gdzie wzrok nie sięga. Ten człowiek, siedzący tak, że jego ekran widzi każdy wchodzący do pokoju, nie za wiele miał do roboty przez pierwsze siedem dni dwutygodniowego sprintu. Od ósmego wyrabia jednak stachanowskie normy, aby zdążyć ze swoją pracą, aby wspomóc zespół. Ale za bardzo nikt tego nie docenia. Tak, tego członka zespołu deweloperskiego cechują silne kompetencje testerskie. I taka też jego główna rola w zespole – testować, testować, testować.

Tester w zespołach Scrumowych. Właśnie! Nie – tester. Deweloper o kompetencjach testerskich. To naprawdę ważne, wręcz cholernie ważne. Do diaska, to nie tylko semantyka!

Pokrótce zaznaczmy, że posiadanie takiej osoby w zespole, też nie jest wcale taką oczywistością, normą, standardem. Wciąż wiele jest organizacji, firm, które człowieka o takich kompetencjach uważają za stratę/koszt (niepotrzebne skreślić), bo przecież programista jest w stanie sam poklikać to, co zrobił. Ba, wszak programiści powszechnie słyną z niezwykłej dokładności w testowaniu.

Mimo wszystko takim organizacjom sukcesu nie wróżę, choć w pewnych przypadkach lub do pewnego momentu, do pewnej skali działania, to wszystko tak może działać. Ale zostawmy to na kiedy indziej. Teraz załóżmy, że mamy zespół Scrumowy, i że trafia do niego – oprócz programistów – także i tester, dotychczas pracujący w odrębnym zespole QA.

Na początku często jest problem. Częstokroć początkujący pytają “co ma robić tester przez pierwszą połowę sprintu, jak nie ma co testować?”. Śmieszne? Może i tak. Ja śmieję się w duchu, bo sam, raczkując, prowadziłem takie rozważania. Siedziałem, myślałem, szukałem – co oni mają robić zanim coś trafi do testów, jak zająć ich czas. Tak, wszakże pochodząc z wyższej kasty IT – architektów i programistów – przez myśl mi nie przeszło pomyśleć żeby zejść do pariasów. Olśniło mnie trzeciego dnia – dlaczego nie pójść i nie zapytać – jak w tym nowym trybie pracy możecie pomóc zespołowi, jak widzicie swoją rolę? Pomysły posypały się jak z rękawa.

I nagle okazało się, że jeden człowiek świetnie pisze i może wesprzeć programistów piszących elukubracje, pardon, dokumentację, która nagle nabiera rumieńców. Drugi może dokonywać drobnych poprawek w kodzie, związanych chociażby z komunikatami wyświetlanymi użytkownikowi. Albo wspierać Product Ownera w tworzeniu wymagań, wykorzystując swoją szeroką wiedzę o systemie. Ogólnie, okazało się, że jest co robić i to jak! Ba, nagle sprint zaczął wydawać się tak krótki… Tak! Testerzy to cholernie zdolni, i cholernie niedoceniani ludzie! Bardzo potrzebni w zespołach Scrumowych.

Druga odsłona medalu. Wróćmy do przywołanego na początku zespołu. Gdzie leży tam problem? Ano w tym, że wszystko trzeba testować manualnie – każdą funkcjonalność trzeba po prostu “przeklikać”. Sprawdzić na różnych środowiskach (urządzeniach, przeglądarkach), sprawdzić wszystkie akcje dostępne z poziomu interfejsu użytkownika, sprawdzić zgodność realizacji wymagania z kryteriami akceptacji, ale i pomyśleć, co tu może nie zadziałać, jak niestandardowo może się zachować użytkownik, gdzie tkwią jakieś niebezpieczeństwa, czy nie ma jakichś dziur, czy nie ma to wpływu na inne miejsca systemu.

Ale w sumie to pół biedy. Bo jak już wszystko jest wyklikane, to trzeba wykonać tak zwany “regres”, czyli sprawdzić czy wprowadzone zmiany nie wpłynęły nam negatywnie na działający system. No dobra, na jego najważniejsze funkcjonalności. Czy da się coś kupić, czy da się opłacić, a pieniądze lądują tam gdzie trzeba, po prostu – czy działają podstawowe funkcjonalności, na których zarabiamy. No to jedziemy, i tak wymaganie, po wymaganiu. sprint po sprincie. W kółko to samo. Niczym motorniczy od 20 lat obsługujący tę samą trasę. Nic tylko współczuć – doprawdy, szkoda tak zdolnych ludzi jak testerzy na taką robotę!

O ile jako tako to działało w waterfallu (w tej rzadkiej sytuacji, gdy testerzy pracowali zgodnie z harmonogramem, a nie mieli 2 dni na wykonanie dwutygodniowego planu testów), to w Scrumie, agile’u robi się problem. Bo to wszystko trwa, potrzebny jest na to czas. A z reguły jeszcze wymagania nie są jakoś mocno podzielone, specjalnie małe, w związku z czym jako gotowe do testów pojawiają się gdzieś w drugiej połowie sprintu. Ruszają testy, pojawiają się błędy, czekamy na poprawki, potem znowu testy, potem regres (coraz dłuższy wraz z rozwojem systemu) potem znowu poprawki, a potem… no już nie ma czasu, bo koniec sprintu. I zamiast potencjalnego do wdrożenia produktu, potencjalnie możemy… No, niewiele. Jakoś też łatwo umyka, że mamy mini-waterfalla w sprincie z osobną fazą testów…

I w końcu zdajemy sobie sprawę – daleko tak nie zajedziemy, to nie ma sensu. O dziwo, zamiast sięgnąć po oczywiste rozwiązania, próbuje się zrzucać winę na proces, rzekomo nie pasujący do firmy lub na deweloperów wytwarzających kod kiepskiej jakości i nie potrafiących go należycie testować i zweryfikować na poziomie Code Review. Albo powstają Scrumowe potworki typu “celem sprintu jest regres”, wypowiedzi Product Ownera typu “w następnym sprincie testy, testy i jeszcze raz testy”, albo testowanie rozwiązań ze sprintu x w sprincie x + 1.

Tymczasem rozwiązanie jest oczywiste – na ile to możliwe – powinniśmy testy automatyzować, minimalizując konieczność manualnych przeklików. Szczególnie w kontekście nużących, ciągłych regresów. Łatwo powiedzieć? Tak! Trudno wykonać? Tak! Da się? Da! Ale nie od razu. Wymaga dużej ilości pracy, szczególnie jeśli system jest stary, ze sporym długiem technologicznym. Ale powoli. Krok, po kroku.

Usiądźcie z osobami, które w zespole najwięcej czasu spędzają przy testach i porozmawiajcie. Na czym tracą najwięcej czasu, co najłatwiej zautomatyzować. Spiszcie wymagania do backloga, spriorytetyzujcie, porozmawiajcie z Product Ownerem. I działajcie.

Jeżeli brakuje wiedzy – wyślijcie ludzi na szkolenia. To zwróci się w dwójnasób!

Nie zapominajcie też o tych, którzy głównie kodują i o testach jednostkowych! I tu zróbcie podobnie. Stopniowo rozszerzajcie też „Definition of Done” i ulepszajcie swój warsztat techniczny.

Nie ma szans na uzyskanie z profitów pracy w Scrumie bez kompetencji testerskich w zespole. I bez wykorzystania ich, zaprzęgnięcia w pełni do naprawdę poważnej pracy, zapewniając automatyzację tego, co się da.

#zespół Scrumowy