Developerze, pozwól testerowi pisać kod!

Chyba wszyscy znamy ten stereotyp: testerzy nie lubią się z developerami, żyją jak pies z kotem itp. Przyznajmy to jednak szczerze: poza naprawdę patologicznymi projektami wcale nie jest tak źle. Z reguły żyjemy dość dobrze, bo wszyscy pracujemy, by osiągnąć wspólny cel. Tak, patrzymy na temat z różnych perspektyw, ale każda ze stron chce, by nam się udało.

Maciej Wyrodek. Tester z 8 letnim doświadczeniem. Specjalizuje się w automatyzacji, choć jego pierwszą miłością są dalej testy eksploracyjne. Pracował w wielu projektach w Polsce i zagranicą. Od dwóch lat udziela się aktywniej w community, prezentując na wielu konferencjach i meetupach. W wolnym czasie prowadzi swój blog thebrokentest.com.

Oczywiście czasem mają miejsce tarcia, bo często zdarza się, że mamy inne priorytety. A nawet, gdy takich problemów nie ma, to zawsze można spróbować ulepszyć naszą współpracę

Pozwól testerom pisać kod

Tak, wiem… Szalona idea. Przecież tester jest po to, żeby testować, a nie pisać kod. Co prawda w wielu projektach jest ktoś taki, jak Test Automation Engineer, czyli tester, który pisze kod pod testy automatyczne (często GUI). Tutaj mi chodzi oto by dopuścić testera do kodu aplikacji, niech wykonuje historyjki. Przyniesie ci to parę korzyści, o których poniżej.

1. Poprawa komunikacji

Parę lat temu zdarzyło mi się pracować w projekcie, w którym do momentu mojego przyjścia żaden tester nie miał wiedzy technicznej. Prowadziło to do absurdalnych sytuacji. Developerzy jasno dawali do zrozumienia testerom, że pewnych rzeczy nie powinni testować, bo jest to zrobione w unitach lub na przykład umawiano się, że dana funkcjonalność nie jest tykana. Niestety regularnie tamci testerzy traktowali kod jak czarną magię, próbowali wszystkiego i testowali wszystko, często nie potrafiąc uzasadnić swojej decyzji.

Gdy dołączyłem do projektu, okazało się, że częściej brałem stronę developerów, bo patrzyłem w kod i rozumiałem co mówili. A nawet jak miałem inne zdanie, to potrafiłem wyjaśnić im w czym widzę problem. Było to na tyle częste, że wylądowałem na dywaniku u dyrektora, bo przyszły do niego skargi, że trzymam z developerami.

Jasne, do tego, by być technicznym, nie trzeba umieć kodować, ale jednak jeśli tester samemu napisze kod, to pomoże mu zbudować doświadczenie i złapać z wami wspólny język. Podobne rzeczy dzieją się w wielu firmach z różnych branż. Często np. sieci marketów wysyłają pracowników do pracy na stanowiskach innych, niż te, na których pracują na co dzień, aby mogli wzajemnie zrozumieć swoje problemy.

Zobacz też

QA Testy regresji – techniki testowania z użyciem checklisty

2. Zrozumienie bolączek developerów

W niektórych firmach role są bardziej “wymienialne”, czyli masz swoją specjalizację, ale robisz wszystko. Jedną z takich firm jest Kobo. Jako tester tam też pisałem funkcjonalność gdy miałem tak zwane “wolne przebiegi”. Oddanie mojego pierwszego “ficzera” do testowania było ciekawym acz frustrującym doświadczeniem.

Widziałem, że drugi tester rozumie wymagania inaczej niż ja, że “źle” czyta instrukcję, którą mu napisałem. Często przerywał mi też pracę, bo nie wiedział, czy ma do czynienia z błędem, czy nie. Bardzo nauczyło mnie to szanować czas developerów. Po prostu zrozumiałem, że są sytuacje, kiedy tester potrafi być bardzo irytujący.

3. Szybszy development

Jeśli tester będzie wiedział jak czytać kod, to może ci pomóc w przygotowaniu unit testów. Wyszukiwanie wartości brzegowych oraz wartości, na której kod może się popsuć to specjalność testerów. Michał Buczko w jednej ze swoich prac pisał code review unit testów i doradzał developerom jakie inne unit testy należy dopisać. Opowiadał mi, że nieraz zdarzyło się, że w testach, które polecał mi dopisać, znalazł błędy.

Oczywiście czytanie kodu nie jest równe pisaniu kodu, ale mimo wszystko najprościej się tego nauczyć pisząc go. OK, ale jak to ma się do przyspieszenia developmentu? Jeśli złapiesz te rzeczy jeszcze przed oddaniem historii do testowania to nie wrócą do ciebie, gdy już będziesz głęboko w innej historii.

4. Poprawa testowania

Jako tester bardzo lubię narzędzia do Code Coverage. Tak, wymaga to zaufania, że unit testy są wartościowe. Można je nadużywać i można źle zrobić metryki, ale jeden rzut oka na to, co jest pokryte, a co nie, bardzo pomaga mi w planowaniu testów. Tak samo jeśli mam dostęp do kodu, to często decyduję się na dopisanie tych testów. Jest jedno ale: takie podejście wymaga zaufania, że unit testy są dobrze napisane. Ale to omówiliśmy w poprzednim akapicie.

Jeśli tester będzie wiedział co jest w unitach i będzie mógł dodawać tam swoje idee, to przy planowaniu swoich testów będzie wiedział czego nie musi już testować, a na czym musi się skupić.

5. Przyspieszenie naprawy błędów

Znasz te bugi? Małe pierdółki… Tester pewno stracił więcej czasu na napisanie raportu niż ty na naprawienie tego błędu – a przynajmniej w teorii. Jeśli doliczymy do tego podatek za zmianę kontekstu (co według badań trwać może między 15 a 30 minut), to czas zmarnowany na takim małym bugu idzie w godzinę. A tester spokojnie mógłby go sam naprawić. Pamiętajmy: „Working software over comprehensive documentation”.

Oczywiście warto zachować tu umiar. To, co napisałem powyżej, nie oznacza, że developerzy powinni być zwolnieni z naprawiania takich błędów. Czym innym jest jeden mały błąd, a czym innym sytuacja, w której tester wraca z całym workiem takich problemów.

Oferty pracy z

OK, a czy są jakieś minusy takiego podejścia? Niestety tak

Powyższe rozwiązanie nie jest odpowiednie dla każdego zespołu. Jeśli testerzy nie są częścią zespołu, lub pracują w innych iteracjach, to nie zadziała. Tak samo będzie w Waterfall, gdzie testowanie jest oddzielną fazą. W zespołach, gdzie jest jeden tester na 10 osób w teamie, może to być praktycznie niemożliwe. Tak samo tester piszący kod nie jest rozwiązaniem dla zespołów, które mają spore problemy we współpracy na linii developer – tester.

Z moich obserwacji wynika, że tester piszący produkcyjny kod najlepiej działa w małych i średnich zespołach agile’owych. Nie zapomnijmy też, że doba ma ograniczoną ilość godzin. Tester ma wiele innych obowiązków i może zwyczajnie nie mieć czasu na pisanie kodu. Tester musi umieć kodować. Możliwe, że będzie mu trzeba pomóc. Będzie musiał się wpierw nauczyć. I tu i firma macie miejsce do popisu – możesz zostać jego mentorem (oficjalnie lub nie). Są też takie style pracy jak mob programming, które mogą przy tym pomóc. Niekoniecznie musi się to dziać w godzinach pracy.

W projekcie, w którym pracowałem, czasem po godzinach w ramach eksperymentowania robiliśmy mob programming, gdzie pisaliśmy proste apki. Testerzy w ten sposób uczyli się programować, a developerzy eksperymentowali z nowymi podejściami i pomysłami.

Na koniec muszę zaadresować jeden brak w powyższym artykule: brak „twardych danych”, którymi mogę się podzielić. Ale kto wie, może jest w tym szansa dla ciebie? Może chcielibyście spróbować to w waszym projekcie i potem podzielić się case study?

Zdjęcie główne artykułu pochodzi z stocksnap.io.