Show must go on! Co zrobić gdy tester jest na urlopie?

Wiem, że kiedy czytacie ten artykuł, jest już najprawdopodobniej środek jesieni, a sezon urlopowy dla wielu staje się mglistym wspomnieniem. Nawet teraz, gdy go piszę, ten najchętniej wybierany na odpoczynek czas chyli się ku końcowi. Choć źródłem inspiracji była dla mnie faktyczna sytuacja, w której zespół został bez testera na pokładzie, kiedy ten zasłużenie odpoczywał, to jednak to, o czym zamierzam napisać, ma bardziej uniwersalne zastosowanie niż mi się wcześniej wydawało. Bo, widzicie, pierwotnie chciałam napisać o tym, co powinien zrobić inżynier odpowiedzialny za jakość nim uda się na urlop. A przecież to nie jedyna sytuacja, w której możemy stanąć w obliczu tego, że jakość pozostaje bez opieki. I dziś sama się o tym przekonałam ze zdwojoną siłą: niespodziewanie spadła na mój zespół informacja, że opuszcza nas jeden z lepszych inżynierów jakości, z jakim przyszło mi kiedykolwiek pracować. Nie pozostaje mi więc innego, niż włączyć „Show must go on” i z tą piosenką w tle zastanowić się, jak przygotować zespół i projekt na to, że kapitan w każdej chwili może opuścić statek.

Test autobusu

Zanim jednak przejdę do faktycznych i naprawdę możliwych do zrealizowania porad, to chciałabym się z Wami podzielić pewną anegdotą. Pewnego dnia, gdy byłam jeszcze na studiach zaocznych, w przerwie między zajęciami rozmawiałam z kolegami na tematy urlopowe. Jeden z nich powiedział, że właśnie wybiera się na dłuższe wakacje, ponieważ jego pracodawca postanowił poddać go „testowi autobusu”. Zaintrygowało nas to, więc poprosiliśmy o rozwinięcie. 

– Bo wiecie – zaczął kolega – należę do grupy pracowników uważanych za strategicznych. Chodzi o to, że oni sprawdzają, co by się stało, jeśli pewnego dnia wpadłbym pod autobus i nagle nie byłoby ze mną kontaktu przez miesiąc.
Do tego kolega wyjaśnił, że dostał miesiąc płatnego urlopu i absolutny zakaz korzystania ze służbowych urządzeń czy nawet odbierania telefonów od pracodawcy, a całość była częścią jakiegoś większego korporacyjnego audytu.

Tak, domyślam się, co Wam może teraz siedzieć w głowach: trochę straszno, trochę śmieszno. Ale ten test mógł rzeczywiście pomóc firmie zidentyfikować w kontrolowanych warunkach problemy, które potencjalnie wystąpią, jeśli pewnego dnia jeden z kluczowych pracowników nie stawi się do pracy. Moim zdaniem to całkiem ciekawe podejście do zarządzania kryzysowego i choć sama nie użyłabym tak drastycznie brzmiącej nazwy, to nie skreślałabym samej idei.

 Mam jednak świadomość, że takie rozwiązanie jest raczej poza zasięgiem statystycznego użytkownika Jiry i jest w gestii osób w wyższych strukturach firmy, odpowiedzialnych za globalne planowanie. Skupmy się więc na tym, co możemy zrobić niemalże natychmiast. Wszystkie porady bazują na moim doświadczeniu i obserwacjach, które opierają się głównie o współpracę w zespołach scrumowych mieszanych (składających się z jednego do dwóch testerów oraz trzech-czterech programistów różnych technologii). Większość z nich będzie jednak uniwersalna dla innego rodzaju zespołów. 

Upewnij się, że zespół ma dostęp do wymaganych narzędzi

Choć ten element może wydawać się oczywisty, to w moim doświadczeniu wielokrotnie spotkałam się z tym, że zespół poległ właśnie w tym miejscu. Pewnie działają tu trochę prawa Murphy’ego (zakładanie, że rzeczy pójdą tak źle, jak to możliwe), a trochę fakt, że często nie zdajemy sobie sprawy z istotności jakiegoś narzędzia do czasu, gdy nie jest ono akurat potrzebne. Wiele narzędzi wykorzystywanych przez testerów jest na licencji przypisanej do konkretnego użytkownika, a pracodawca płaci za każdorazowe jej przypisanie. W związku z tym niejednokrotnie spotkałam się z tym, że w celu cięcia kosztów przypisywanie licencji ogranicza się do minimum, co w praktyce oznacza, że do rozwiązań testerskich z automatu przypisani są tylko… testerzy. A ponieważ testerzy są też na co dzień jedynymi użytkownikami testerskich rozwiązań, to nie są świadomi braku ich dostępności dla kolegów z zespołu, którzy testami się nie zajmują. Podobnie, jak ci drudzy, bo nie korzystając z programu, ciężko zauważyć brak jego dostępności.

Nie tak dawno sama byłam świadkinią takiej sytuacji: tester udający się na urlop nie miał świadomości, że jest jedyną osobą w zespole, która posiada uprawnienia do korzystania z narzędzia do zarządzania przypadkami testowymi. Jego nieobecność przypadła na release (upublicznienie danej wersji programu lub jego części), który w firmie, w której pracuję, musi zostać poprzedzonym wykonaniem testów zgodnie ze scenariuszami ze wspomnianego narzędzia oraz uzupełnieniem raportu tamże. Zespół pozbawiony listy przypadków testowych nie był w stanie samodzielnie zweryfikować kandydata do releasu, był uzależniony od pomocy innych i/lub zmuszony do oczekiwania na nadanie dostępu. I choć sytuacja sama w sobie może wydawać się niegroźna, to jednak mogła doprowadzić do opóźnienia wydania, a tym samym – do strat.

Nie uważam, żeby było koniecznie, aby w zespole każdy miał dostęp do wszystkich narzędzi wykorzystywanych w projekcie lub procesach z nim powiązanych. Warto jednak zadbać o to, by z rozwiązań mogła korzystać więcej niż jedna osoba, jeśli zajdzie taka konieczność. 

Zapoznaj zespół z procesem

W teorii testowanie jest elementem całego procesu tworzenia oprogramowania i jako ciągłość powinno być tak samo oczywiste, jak wszystkie inne etapy. W praktyce często rządzi się ono swoimi własnymi prawami, niekoniecznie zrozumiałymi dla osób niezaangażowanych w ten proces. Niejednokrotnie spotkałam się z tym, że programiści w ogóle nie są zaangażowani w testowanie (w tym czasie realizują po prostu kolejne zadania dotyczące rozwoju oprogramowania), a tym samym nie do końca wiedzą, co i jak należy zrobić.

Zespół powinien być świadom zadań, które wykonuje tester. Jeśli jest to dodanie komentarza w Jirze pod przetestowanym zadaniem – powinien o tym wiedzieć. Jeśli proces zakłada, że te testy automatyczne, które nie przechodzą na zielono (ponieważ znalazły błąd), powinny zostać zignorowane i oznaczone tagiem z numerem buga – powinien o tym wiedzieć. Jeśli przed potwierdzeniem zakończenia testów konieczne jest napisanie raportu podsumowującego – również zespół powinien o tym wiedzieć. 

Procesy bywają zawiłe i nie zawsze oczywiste. W moim przypadku częścią procesu jest również obserwacja konkretnego kanału na firmowym komunikatorze. Przegapienie informacji o tym, w jakiej fazie deploymentu (proces związany z instalacją, testowaniem i implementacją) jesteśmy, może być brzemienne w skutkach. Nasz proces powinien uwzględniać również te nieoczywiste przypadki.

 

Wyznacz odpowiedzialnego

Jedna z podstawowych zasad udzielania pomocy przy wypadkach mówi o tym, żeby wskazywać osoby odpowiedzialne za poszczególne zadania. Jest tak dlatego, że powiedzenie słów „niech ktoś”, jak w popularnym memie, prowadzi do rozmycia odpowiedzialności i w konsekwencji do sytuacji, w której nikt z tych „ktosiów” nie poczuwa się do tego, by wykonać daną czynność.

Testowanie – choć ważne – jest dalece mniej krytyczne niż ratowanie czyjegoś życia. Niemniej mechanizm jest ten sam: istnieje ryzyko, że jeżeli nie wskażemy konkretnej osoby, która odpowiada za nasze zadania, to pozostaną one niezrealizowane. W przypadku planowanego urlopu czy zwolnienia się z firmy łatwo uzgodnić „sukcesję” na jednym z ostatnich spotkań. Ale w przypadku zdarzeń losowych sytuacja może się okazać już nie taka prosta. Dlatego uważam, że zastępowalność na wszelki wypadek powinna być częścią procesu i w każdym ze swoich zespołów dążyłam do tego, by mieć na stałe wyznaczonego zastępcę. 

Wskaż, gdzie szukać pomocy 

To chyba moja ulubiona porada, którą niczym przekupka na targu uwielbiam wciskać każdemu, z kim pracuję. Moja mama zwykła mawiać, że „koniec języka za przewodnika”, ale oczywiście w bardziej przyziemnych sytuacjach, jak na przykład wtedy, kiedy zgubiłyśmy się w niemieckim mieście, nie znając języka niemieckiego. Jednak nauczyłam się wówczas czegoś, czego pewnie nie mogłam nauczyć się w żaden inny sposób: warto rozmawiać. A z czasem nauczyłam się też, że kluczem do sukcesu jest rozmawiać z właściwymi osobami. Dlatego gdziekolwiek pracuję, staram się zidentyfikować osoby, które mają dużą wiedzę z danego obszaru, a przy tym cechują się otwartością na wsparcie innych. Świadomość tego, kto jest takim firmowym bankiem wiedzy, może wyciągnąć nas z niejednych tarapatów. Dlatego przede wszystkim polecam najpierw zbudować sobie taki osobisty „think-tank”, nieformalny, nienazwany zespół. Ale nie poprzestawajmy na tym. Jeśli wiemy, kto w czym może pomóc, to i tą wiedzą się podzielmy. Jeśli przyjdzie nam zostawić zespół – na jakiś czas lub na zawsze – nie pozostanie on bez dostępu do wiedzy, która w tym wypadku często jest typowo domenowa (typowa dla tej tylko jednej firmy i niemożliwa do znalezienia w internecie).

Angażuj zespół w proces testowania

Nic tak nie uczy, jak własne doświadczenie. I choć dla większości osób, z którymi pracowałam, oczywistym było, że za jakość oprogramowania powinien odpowiadać cały zespół nad nim pracujący, to jednak z mojej obserwacji wynika, że nie zawsze teoria idzie w parze z praktyką. Poza tym odpowiedzialność to jedno, a faktyczne wykonywanie zadań jest odrębnym tematem. 

Zespół powinien wiedzieć, czym i po co zajmuje się tester. Być może nie zawsze członkowie zespołu będą mieli możliwość, by fizycznie testować, zwykle odrobina wolnego czasu zostanie wykorzystana na dalszy rozwój oprogramowania. Dlatego  warto szczegółowo omawiać swoje zadania, na przykład na codziennych spotkaniach. Można też praktykować coś, co nazywam „pair testingiem” (w analogii do pair programmingu). Ja do tego wykorzystywałam ewentualne znalezione usterki – jeśli na takową natrafiłam, to wraz z programistą przechodziłam całą ścieżkę, a później wspólnie debugowaliśmy. Dzięki temu on obserwował, jak wygląda testowanie, a ja lepiej poznawałam metody analizowania problemów – obopólna korzyść!

Dokumentacja nie gryzie

Nie zdziwiłabym się, jeśli ktoś z czytelników – po przeczytaniu nagłówka – pokusiłby się o rzucenie we mnie nieśmiertelnym punktem Agile Manifesto: „Działające oprogramowanie od szczegółowej dokumentacji”. Nie ze mną te numery! Mam skromne, ale pełne przygód doświadczenie na stanowisku Scrum Mastera i już spieszę z ripostą. Manifest Agile to nie tylko te cztery osławione punkty. To także przypisy pod nimi:

„Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej”.

Tak więc przytoczony wcześniej punkt manifestu wcale nie oznacza, że zadaniem osób, które pracują w Scrumie jest zupełne zignorowanie dokumentacji. Chodzi tylko o to, aby dokumentacja nie przysłaniała nam tego, co najistotniejsze – działającego rozwiązania. Formalności mamy za sobą, mogę więc przejść do clue: piszcie dokumentację. O wiele częściej zdarzało mi się cierpieć z powodu braku dokumentacji niż jej nadmiaru.

Choć dokumentację uważam za fundament „ciągłości pokoleniowej” w pracy zawodowej, to zostawiłam ten punkt na koniec. A to dlatego, że dokumentacja to nie tylko to, co opisuje nasz program – pokuszę się o stwierdzenie, że to chyba nawet w najmniejszym stopniu to (głęboko wierzę, że wszyscy czytający uważają, że nie ma nic bardziej cool niż samodokumentujący się kod). Dokumentacja to również spis i opis wszystkiego, o czym mówiłam wyżej: procesów, węzłów kontaktowych, wymaganych uprawnień, osób odpowiedzialnych. Możecie nie zdążyć opowiedzieć zespołowi wszystkiego, o czym wspomniałam w tym artykule. Ale możecie to spisać. Spisać i w myśl zasady ciągłego doskonalenia pilnować, aby było zawsze aktualne.

I to wszystko?

Tak jest. Tylko tyle. Albo aż tyle – choć wydawać się może, że wszystko, o czym pisałam, jest oczywiste, to wielokrotnie się przekonałam, że wcale takie nie jest. W dodatku nawet powyższe nie gwarantuje, że zespół jak po maśle przejdzie przez sytuację, w której zostanie bez osoby odpowiedzialnej za testowanie. Bo nawet najlepsza znajomość procesu nie da w nim biegłości, a dostępność narzędzi nie jest równoznaczna z umiejętnością korzystania z nich. 

Zdaję sobie też sprawę, że wiele z tego, co napisałam, jest uniwersalne i sprawdzi się także na innych stanowiskach czy w różnych technologiach – z powodzeniem może z nich korzystać także Scrum Master czy programista. Jednak jako specjalistka od jakości zawsze uważałam, że moja odpowiedzialność to nie tylko jakość oprogramowania, ale również jakość procesu – wszak dobry proces daje większe szanse na dobre oprogramowanie. Jestem też realistką i wiem, że firmy zatrudniają mniej testerów niż programistów, a to sprawia, że z dużo większym prawdopodobieństwem zespół stanie w obliczu wypełnienia luki po tym pierwszym.

Wszystkie porady bazują na moim własnym doświadczeniu. Być może nie uwzględniają one sytuacji, na które ja zwyczajnie w swojej karierze nie natrafiłam. Dlatego też zawsze najważniejszym elementem jest komunikacja w zespole. Zachęcam Was do tego, aby poświęcić odrobinę czasu, na przykład na Retrospektywie, do tego, aby zastanowić się, jak wygląda Wasz proces i co zrobić, aby przygotować się na ewentualny brak testera (czy też dowolnego innego członka lub członkini zespołu).