Pair testing: jak developerzy i testerzy wspólnie dbają o jakość

Choć pair testing (testowanie w parach) zdobywa popularność na całym świecie, na naszym lokalnym podwórku wciąż jest jeszcze stosunkowo świeżą koncepcją. Jego wdrożenie przyniosło nam szereg korzyści, ale i postawiło przed nami pewne wyzwania, zwłaszcza w kontekście istniejącego, dojrzałego modelu rozwoju oprogramowania naszych klientów.

W tym tekście podzielimy się z Wami szczegółami naszych doświadczeń z pair testingiem. Sprawdźcie co mamy na myśli, mówiąc o jego istotnym i transformacyjnym wpływie na praktyki tworzenia oprogramowania.

Moja definicja pair testingu

W prostych słowach ująłbym ją tak:

Jest to praktyka, w której dwie osoby współpracują nad jednym zadaniem tak, aby kompleksowo stworzyć je i przetestować. Zazwyczaj jedna z nich jest specjalistą od quality assurance, a druga programistą, który rozumie techniczne aspekty aplikacji. Warto zaznaczyć, że nie jest to ścisła reguła, gdyż zdarzają się przypadki, w których w taką pracę zaangażowanych jest więcej osób na innych stanowiskach (np. analitycy biznesowi).

Podczas takiego wspólnego testowania, QA engineer ma możliwość zrozumienia szczegółowych aspektów technicznych aplikacji. Zyskuje dzięki temu szerszą perspektywę, poszerza swoją wiedzę dziedzinową i może lepiej zrozumieć funkcjonalność systemu.

Z drugiej strony, programista widzi aplikację oczami testera, co pomaga mu lepiej pojąć oczekiwania i wymagania jakościowe związane z jego kodem. Dodatkowo pair testing wpływa na polepszenie komunikacji, prowadzi do kultury dzielenia się wiedzą i zrozumienia między członkami zespołu, skutkując wydajniejszym przepływem pracy.

A teraz przejdźmy do konkretnego przykładu.

Jakie wyzwania napotkaliśmy w projekcie? Studium przypadku

Półtora roku temu, czyli niemal od samego początku nowego, wielkoskalowego projektu spadło na nas spore wyzwanie. Przed nami jawił się ogromny zakres pracy, który musiał zostać kompleksowo wdrożony już od wczesnego etapu projektowania, z bardzo małym marginesem na błędy. Jednocześnie cały zespół szybko się rozrastał – gdy klient był zadowolony ze współpracy, przydzielał nam jeszcze więcej zadań, co skutkowało dodawaniem nowych członków teamu, aby możliwe było wypełnienie kolejnych tasków.

W krótkim czasie od rozpoczęcia pracy mieliśmy już kilka osób zaangażowanych na różnych poziomach projektu: doświadczonych JavaScript fullstack developerów, specjalistów od DevOps, analityków biznesowych, a także niewielki zespół QA. Jak to często bywa, team składał się z osób o różnych doświadczeniach z poprzednich firm i projektów, a każda z nich miała własne preferencje dotyczące wyboru narzędzi, rozwiązań i metodologii pracy. Wymagało to od nas przyjęcia wyszukanego i eksperymentalnego podejścia do zarządzania projektami.

Musicie wiedzieć, że w Brainhubie realnie angażujemy klientów w proces rozwoju produktu. Jesteśmy z nimi w częstym kontakcie, dzięki czemu otrzymujemy od nich konkretny input i możemy proponować im lepsze rozwiązania. Ten kij ma jednak dwa końce. Z jednej strony rozwiązanie przynosi nam dużo plusów, bo klienci mogą szybko dostarczyć nam masę cennych informacji zwrotnych, a także stale weryfikować swoje wymagania.

Z drugiej strony współpraca z tym konkretnym klientem wiązała się z częstymi modyfikacjami istniejących zadań, co zwiększało złożoność projektu i istniejące w nim zależności.

Siła współpracy na linii Dev i QA

Patrząc teraz wstecz, trudno mi uwierzyć, jak spontaniczne interakcje między członkami zespołu mogą prowadzić do tak znaczących zmian w procesie. Przypadek naszego zespołu jest dość ciekawym przykładem, który moim zdaniem może wystąpić w większości podobnych projektów.

Wszystko zaczęło się niewinnie, od typowego videocalla między nowym członkiem zespołu QA a doświadczonym developerem. Nic nadzwyczajnego, prawda? Programista wyjaśniający nowemu specjaliście od jakości jak przetestować konkretną złożoną funkcjonalność backendu.

Ich interakcja stała się jednak tak intensywna, że przerodziła się w rozmowę nie tylko o samej funkcjonalności, ale i o tym, jak pisać do niej testy, kiedy to robić oraz jakich technik i narzędzi używać. Skończyło się na tym, że obaj pracowali w tym samym branchu, gdzie wspólnie w pełni zaimplementowali i przetestowali funkcjonalność za pomocą testów API i testów jednostkowych.

W tamtym czasie nie nazywaliśmy tego formalnie pair testingiem, ale cała ta sytuacja zapoczątkowała zupełnie nową dynamikę. Programiści, zdając sobie sprawę z korzyści płynących z tych wspólnych sesji, podjęli inicjatywę i zadali specjalistom od QA kilka ważnych pytań. Zajmowało ich przede wszystkim to, w jaki sposób sami mogliby ulepszyć proces testowania. Ostatecznie pojawiło się pytanie, czy QA inżynierowie zgodziliby się usiąść wspólnie na kilka godzin – tak, aby możliwe było wspólne wykonanie zadania od początku do końca.

Zaczęliśmy więc dostrzegać wzajemną potrzebę, która wykraczała poza granice tradycyjnych ról, określonych w naszych CV. W końcu rozpoczęliśmy regularną współpracę nad nowymi testami, ulepszając istniejące, utrzymując je i identyfikując nowe, niepokryte scenariusze testowe. W konsekwencji nasza coraz częstsza współpraca przerodziła się w pair testing między developerami i specjalistami od quality assurance.

Oferty pracy z

Co działa, a co niekoniecznie…

Odkąd zaczęliśmy pracować nad testami w parach, zaobserwowaliśmy mnóstwo pozytywnych zmian. Przede wszystkim zauważyliśmy, że dowozimy zadania znacznie szybciej i że efekty są znacznie bardziej jakościowe. To prawdopodobnie największy i najbardziej wartościowy efekt, jaki można osiągnąć dzięki temu podejściu. Połączenie unikalnych umiejętności testera i developera zwiększa efektywność wykonywanych przez nas tasków.

Dzięki temu nowemu podejściu wzrosła nam liczba testów i przypadków testowych. Wspólnie możemy zidentyfikować więcej potencjalnych problemów w fazie kodowania, co ostatecznie przekłada się na kompleksowość naszych testów. Bez wysiłku obsługujemy testy i dodajemy nowe na różnych poziomach: testy API, testy end-to-end, testy integracyjne, testy jednostkowe, a nawet ostatnio znaleźliśmy czas na testy wizualne.

Dodatkowo praca w modelu pair testing, która zakłada, że specjaliści od QA i developerzy współpracują nad jednym branchem w naszym monorepo, znacznie zmniejszyła liczbę konfliktów podczas merge’ów lub pull requestów. Jest tak, bo dwie osoby pracują nad jedną funkcjonalnością w tym samym momencie.

Kolejną zauważoną przez nas zaletą jest zmniejszenie liczby zgłaszanych błędów po releasie nowej wersji aplikacji. Oszczędzamy dzięki temu mnóstwo czasu, bo zamiast nerwowego naprawiania błędów na produkcji, możemy spokojnie skupić się na nowych funkcjonalnościach i nadchodzących zadaniach. Można właściwie powiedzieć, że podczas wspólnego testowania wykonujemy nawet pewną formę wczesnego code review. Często wyłapujemy błędy w kodzie drugiej osoby już na pierwszych etapach kodowania.

Dodatkowo czas potrzebny na dostarczenie nowej funkcjonalności jest zauważalnie krótszy w przypadku zadań wykonywanych w ramach pair testingu. Wcześniej programowanie i testowanie były najczęściej oddzielnymi etapami, co wydłużało cały proces dostarczania. Teraz, dzięki nowemu podejściu, te dwie fazy przeplatają się i występują jednocześnie, co skutkuje krótszym czasem implementacji i szybszym dostarczaniem funkcji.

Programowanie w parach okazało się nieocenionym narzędziem w ograniczaniu context switchingu – zjawiska, które zazwyczaj zmniejsza wydajność pracy. Dzięki temu, że programista i tester pracują wspólnie nad jednym zadaniem, nie muszą bez przerwy przerzucać uwagi z zadania na zadanie i przełączać się między różnymi kontekstami. Eliminuje to niepotrzebne przestoje, takie jak konfigurowanie środowisk lub migracje baz danych, i pozwala im skoncentrować się na jednym problemie. Naprawdę wierzę, że programowanie w parach jest skutecznym sposobem na zminimalizowanie negatywnego wpływu context switchingu.

Oczywiście, jak każda nowo wprowadzona technika, początkowo testowanie w parach może wydawać się problematyczne. Możecie zwrócić uwagę na problem marnowania zasobów – ostatecznie dwie osoby pracują jednocześnie nad tym samym zadaniem. Jednak gdy weźmiemy pod uwagę efekty stosowania tej metody, staje się jasne, że jest to po prostu inwestycja. W dłuższej perspektywie pair testing przynosi nam znacznie większe korzyści.

Instrukcja wprowadzania zmian

Chcę podzielić się z wami tym, co zmieniliśmy i jak osiągnęliśmy porozumienie w temacie wprowadzenia pair testingu do projektu. Pewnie, zmiana nie była łatwa, ale jak we wszystkim, kluczem była bezpośrednia komunikacja.

Zaczęliśmy od poinformowania wszystkich członków zespołu, zarówno technicznych, jak i nietechnicznych, o naszych planach. Wyjaśniliśmy, czym jest testowanie w parach, jakie korzyści może przynieść i jak planujemy je wdrożyć. Jako zespół pracujący głównie zdalnie, rozszerzyliśmy naszą regularną komunikację przez standardowe platformy o systematycznie organizowane videocalle. Pozwoliło nam to na prowadzenie rozmów w czasie rzeczywistym – w dobie pracy zdalnej ten aspekt jest kluczowy dla wymiany pomysłów i wyjaśniania wszelkich niejasności na “tu i teraz”.

Zauważyliśmy, że niektóre zadania były na tyle duże, że sparowanie specjalisty od QA z developerem na dłuższy czas miało sens podczas planowania sprintu lub przeglądu backlogu – ostatecznie chcieliśmy wcześniej wiedzieć o tym, kto będzie zaangażowany w dane zadanie.

Zdecydowaliśmy, że niezależnie od tego, kto został przypisany do konkretnego taska, obie osoby będą rejestrować na nie swój czas pracy. Dlaczego? Ponieważ obie osoby wkładają w nie swój wysiłek i czas. W ten sposób wszystko się zgadza i nikt nie ma brakujących godzin, a nasze narzędzie do trackowania czasu pracy wspaniale pokazuje, kto i kiedy wykonał jakie zadanie.

Na koniec chciałbym dodać, że chociaż pair testing okazał się skutecznym narzędziem, nie każde zadanie kwalifikuje się do tego trybu pracy. Nadal wykonujemy większość tasków w standardowym trybie, a testowanie w parach wykorzystujemy jako dodatek tam, gdzie możemy czerpać największe korzyści z tego typu intensywnej współpracy.

Podsumowując pair testing – warto było!

Metoda pair testingu pokazała nam, że w pogoni za jakością warto czasami podejmować nieszablonowe kroki (oczywiście, w porozumieniu z zespołem i klientem). Zachęcamy wszystkich zainteresowanych usprawnieniem swojego procesu testowego do eksperymentowania z pair testingiem. Pewnie, może to wymagać pewnych zmian w pracy zespołu, ale ostateczne rezultaty z pewnością przekonają was do tego podejścia. Nie bójcie się więc próbować, odkrywać i uczyć się nowych, stale ewoluujących technik.

Zdjęcie główne pochodzi z Envato Elements.