Przełom grudnia i stycznia to taki czas, w którym częściej zbiera nam się na podsumowania i zmiany. Dopadło też mnie. Grudzień był dla mnie czasem planowania. Nie tylko w kontekście kursu, który tworzę i kolejnych, za które się wezmę, gdy go skończę. Chodzi też o moją pracę zawodową. Z początkiem tego miesiąca zaczęłam wdrażać w projekcie, w którym pracuję coś, o czym już dawno myślałam. Coś co ma pozytywnie wpłynąć na jakość w projekcie. I podzielę się tym z Wami, bo może Wam też da to kopa do jakichś pozytywnych zmian.

„Jak coś Cię boli, to do lekarza trzeba.”

Tak mi kiedyś w żartach odpowiedział developer na moje spontaniczne uwagi dotyczące procesów w naszym zespole. Bardzo celne, umiem docenić. Głównie chodziło mi o procesy, których usystematyzowanie może pozytywnie wpłynąć na jakość w projekcie.

Odrobina historii: mój zespół to w tym momencie 5 developerów i ja. Zostałam zatrudniona do tego zespołu do napisania testów automatycznych i od tego zaczęłam. Dopiero po jakimś czasie zrozumiałam, że nie tego potrzebuje mój zespół i że muszę przedefiniować swoją rolę.

Mimo, że uzbierało mi się w przeciągu kilku miesięcy mnóstwo takich bolączek, to dopiero odrobinę złośliwa sugestia wybrania się do lekarza, dała mi kopa do jakiegoś działania.

Moje obserwacje

Marudzić to ja umiem pierwszorzędnie, więc znalazłam tego dużo. Poniżej zawarłam te, które uważam za najważniejsze w kontekście zmian, na jakie się zdecydowaliśmy.

• Zespół nie rozumiał, co i jak jest testowane. Po prostu robiłam jakąś swoją magię, a chłopaki ufali, że robię to dobrze. 
• Nie wykorzystywaliśmy całego potencjału w trakcie weryfikacji. Najlepsze efekty dawało testowanie w parze z developerami.
• Chłopaki mają całkiem niezłą skuteczność w wyszukiwaniu problemów w kodzie u siebie nawzajem. Mają większe doświadczenie z produktem i czasami już wiedzą, gdzie szukać.
• Mój zespół ma wymienne kompetencje i jedynie testowanie jest jakby z boku. 
• Dostarczamy sporo rzeczy, produkt nie jest łatwy w testowaniu, więc często testy były wąskim gardłem.
• Duża część naszej komunikacji jest nieformalna. A że zawsze byłam trochę z boku, to część informacji mnie zwyczajnie omijała.
• Mamy spore pole do poprawy jeżeli chodzi o to, co się dzieje jeszcze przed testami.

A moje osobiste bolączki?

Przede wszystkim ilość pracy i związana z tym frustracja. Ilość testów koniecznych do wykonania zwyczajnie mnie przerastała. Potrzeba częstego przełączania się między kontekstami wpływała też negatywnie na moją zdolność do skupienia się. W efekcie zdarzało mi się nie wykryć problemów, których nie należało wpuścić na produkcję. Można by rzec, że to kwestia priorytetów, ale skonsultowałam to z kilkoma osobami. Nie tylko mi zbyt wiele rzeczy wydawało się mega ważnych, żeby mogła to ogarnąć jedna osoba w rozsądnym czasie.

Dochodzą jeszcze jakieś moje cechy charakteru. Jestem osobą, która musi się z kimś pojarać tym co robi. A chłopaki to tak naprawdę nie mieli pojęcia, co ja właściwie robię. No i lubię rywalizację, to bardzo przyspiesza mój rozwój. A będąc jedynym testerem, nie miałam się z kim ścigać i od kogo uczyć. I to nie tak, że nie umiem albo nie lubię się sama uczyć. Ale potrzebuję jakiejś inspiracji i zwyczajnie pogadać o tym, co robię z kimś, kto to rozumie.

Nowy rok, nowa ja, nowy zespół

Porozmawialiśmy między sobą i z naszym szefem i wszyscy zgodziliśmy się, że warto wprowadzić jakieś zmiany. I zaproponowałam coś, czego trochę się bałam, prawdę mówiąc. A mianowicie zaproponowałam, żebyśmy zrezygnowali z roli testera i wszyscy wzięli na siebie odpowiedzialność za testy.

I wiecie co? Byli bardzo za. Ani jednej osoby nie musiałam przekonywać.

Zgodziliśmy się, żebyśmy wszyscy wzięli na siebie część testowania. Ja wezmę na siebie część developmentu i jednocześnie będę robić za kogoś w rodzaju konsultanta od jakości. A potencjalnych korzyści z tym związanych widzę mnóstwo.

• Trochę przesuniemy odpowiedzialność za jakość. Nie mówię, że chłopaki mieli to do tej pory w nosie, bo nie mieli, ale liczę na to, że testując trochę szerzej spojrzą na swoją rolę i zadania.
• Więcej osób w testach, to więcej pomysłów jak zbudować proces, który będzie nam pasował i sprawi, że będziemy mieli większe zaufanie do naszych wdrożeń.
• Jeżeli każdy będzie coś testował, to ja nie będę musiała testować wszystkiego. Będę więc lepiej skupiona na tym, co mi do testów zostanie ale także na jakimś szerszym obrazie jak nasz proces powinien wyglądać. I będę go też teraz podglądać na trochę wcześniejszych etapach.
• Wykorzystamy cały potencjał i wiedzę chłopaków w testach.
• Powinniśmy rozwiązać problem z wąskim gardłem.
• Nie będzie już popłochu jak pojadę na urlop.
• Jeden sfrustrowany człowiek w zespole mniej 😛

A zaczynamy to wszystko od razu, bo tutaj nie ma na co czekać. Mam taką naturę, że rzucam się w działanie od razu i udziela się to innym. W związku z tym testy funkcjonalne robią wszyscy już od tego tygodnia. Testy eksploracyjne przed wdrożeniem również robimy już wspólnie, z podziałem na obszary i w formie rywalizacji. I sami to wymyślili.

To może my też zrezygnujemy z testera i yolo?

No otóż nie. W tym wpisie nie mówię Ci jak żyć, jak testy robić albo kto powinien testować w zespole. Mówię, jak można to zrobić i to też nie z każdym zespołem i produktem zadziała. Czy z moim zadziała, to się będzie jeszcze weryfikowało. 

Przede wszystkim nie wymyśliłam sobie tego sama. Ta zmiana nie dotyczy tylko mnie. Zanim rzuciłam tą bombę o zrezygnowaniu z testera, rozmawiałam spontanicznie z chłopakami co ogólnie o tym myślą. I bomba bombą ostatecznie nie była. Mój zespół był chętny i otwarty na przejęcie testów i zdają się rozumieć czemu to robimy. 

I przede wszystkim mamy dużą swobodę jeżeli chodzi o to, jak pracujemy, więc większość zmian możemy wprowadzać właściwie z dnia na dzień. 

#niedasie

Warto się odkleić od tego, co masz w papierach. To, że w papierach stoi, żeś tester automatyzujący, to nie znaczy jeszcze, że nie możesz wsadzić nosa w cały proces i czegoś zmienić. To nie znaczy, że jak Cię procesy zaczynają frustrować albo uważasz, że źle testujecie w projekcie, to trzeba od razu rzucić wypowiedzeniem. Można, wszystko można. Można też wyjechać w Bieszczady.

Ale z mojego doświadczenia wynika, że nie warto. Zmieniasz miejsce, ludzi ale problemy są z grubsza podobne i po chwili znowu zaczynamy przypominać zombie. Najpierw spróbuj popracować nad tym, co Cię w projekcie uwiera i rozmawiaj z zespołem.

Poza tym, wdrażając jakieś pozytywne zmiany pracujesz nie tylko na chwałę korpo (hyhy). Myśl o sobie. Ja to nie umiem pracować gdzieś, gdzie nie czuję, że moja robota ma jakikolwiek sens. I wierzę, że większość z nas tak ma. 

Życzę Ci w nadchodzącym roku, żeby się dało 🙂