top of page

Zespół programistyczny bez testera? Czy to ma sens?

Zaktualizowano: 20 lis 2023


Fakt: budowanie oprogramowania to gra zespołowa. Nie da się zbudować nic znaczącego w pojedynkę. Nie oznacza to jednak, że samotne wilki, 10x developers nie istnieją – pewnie istnieją, chociaż ja chyba nigdy takiego nie spotkałem. Istnieją czy nie – nie mają szans z dobrze naoliwionym zespołem. Nie na długim dystansie. A budowanie softu to maraton.

W skład zespołu programistycznego może wchodzić wiele osób spełniających całą gamę różnych ról. Począwszy od najbardziej oczywistych, czyli programistów i testerów, poprzez grafików, UX designerów, po analityków biznesowych i scrum masterów. Niezbędnym minimum są programiści. Wiadomo, że bez nich nie da się zbudować żadnego oprogramowania – ktoś ten kod przecież musi napisać. Natomiast jeżeli chodzi o pozostałe osoby – zdania mogą być podzielone.


Zespół bez testera

Czy zespół może funkcjonować bez testera? Może. Sam pracowałem w takich zespołach i jakoś żyliśmy, dowoziliśmy kolejne funkcje, a robota szła do przodu. Czy miało to sens? Moim zdaniem nie do końca i postaram się opowiedzieć, dlaczego.

Podstawowym problemem zespołu pozbawionego testera jest to, że nie da się uniknąć słabszej jakości wytwarzanego przez nich produktu. Programista nigdy nie będzie w stanie tak samo dobrze przetestować oprogramowania jak tester – z kilku powodów.

Pierwszy z nich jest bardzo prozaiczny – bo mu się po prostu nie chce tego robić. Nie wiem czy znam chociaż jednego programistę, który powiedziałby tak: „ja to w wolnym czasie lubię sobie potestować, najbardziej jara mnie przeklikiwanie różnych edge-casów w kodzie swoim i moich kolegów! Dlatego bardzo się cieszę, że połowę czasu w pracy będę programował, a drugą połowę testował! I solennie obiecuję, że będę się trzymał tych proporcji!”. Na bank tak będzie... Nie wierzę, że praca w takim trybie jest możliwa do utrzymania w dłuższej perspektywie czasu. Skończy się to zapewne tak, że programiści będą testować po łebkach byle tylko odbębnić testy i móc wrócić do programowania. Będą przymykać oczy na niedociągnięcia albo w ogóle ich nie zauważą. Nie poświęcą czasu, żeby przemyśleć czy dany sposób rozwiązania problemu ma sens. Ale nawet jakby się starali ze wszystkich sił to przechodzimy do problemu drugiego, który im to uniemożliwi.

Problem drugi – programista nie może skutecznie testować kodu (zwłaszcza swojego) ponieważ wpada w pewne ramy myślowe, które sprawiają, że analizuje go zawsze zgodnie z kierunkiem jego implementacji. Skuteczne testowanie wymaga spojrzenia na problem z odległej perspektywy, co jest trudne, kiedy chwilę temu pracowało się nad jego rozwiązaniem. Niełatwo jest ocenić długość rzeki, dostrzec jej rozgałęzienia i meandry, kiedy właśnie tą rzeką płyniemy wpław, albo dopiero co wyszliśmy na brzeg po zmaganiach z jej nurtem. Bardzo często, gdy testowałem swój kod w myślach po prostu przechodziłem kolejne etapy algorytmu który chwilę temu napisałem - podświadomie nie zbaczając zbyt często z tej drogi. To nie jest przepis na skuteczne szukanie bugów. Ale nawet gdybym potrafił zupełnie oderwać się od poprzedniej perspektywy programisty i wskoczyć w buty niezależnego, zewnętrznego obserwatora, a potem zupełnie bez emocji dostrzec wszystkie te usterki, których jeszcze minutę temu ślepo nie widziałem starając się przecież ze wszystkich sił mój kod napisać jak najlepiej – nawet gdybym potrafił to zrobić i potrafił robić to codziennie bez znużenia – nawet wtedy istnieje trzeci, ostateczny problem, który sprawia, że nie ma to najmniejszego sensu.

Problemem trzecim jest ekonomia takiego sposobu wytwarzania oprogramowania. Niech każdy kto nie rozumie o co mi chodzi zajrzy na dowolny portal z ogłoszeniami o pracę i zobaczy, jak kształtują się widełki programistów, a jak wyglądają widełki testerów. Jedynym sensownym wykorzystaniem czasu programisty jest programowanie – najlepiej w długich blokach czasowych. Żeby mógł się skupić, wejść w mityczne ‘flow’ i napisać tyle kodu, ile jest w stanie. Nie chcemy go odrywać od tej czynności, bo to bardzo drogo nas kosztuje. Tester jest tańszy, a do tego lepiej testuje.


A może by tak zatrudnić testera?


Omówiliśmy sobie słabe punkty pracy zespołów pozbawionych testerów, zastanówmy się zatem jakie korzyści wynikają z faktu posiadania przynajmniej jednego z nich w swojej drużynie.

Pierwsza korzyść – programiści mogą skupić się na swojej pracy. Ciężko mi nawet opisać jak fundamentalne ma to znaczenie dla efektywności pracy takiego zespołu. Gdy patrzę na moją pracę, jestem w stanie pokazać okresy, kiedy przez tydzień dowoziłem kod, który statystycznie zająłby mi miesiąc do zbudowania lub odwrotnie – przez tydzień nie zbudowałem absolutnie nic wartościowego, a nawet narobiłem szkód, które potem musiałem naprawiać. Gdy próbuję doszukać się czynników potrafiących tak dramatycznie wpłynąć na jakość pracy programisty, jednym z nich – praktycznie u samego szczytu listy – jest ilość rozpraszaczy które docierają do nas w ciągu dnia, a potem wiszą nam ciągle z tyłu głowy. Przykładem takiego rozpraszacza jest np. prośba od kolegi: „Hej Damianie, mógłbyś przetestować mój kodzik? Daj znać, czy wszystko działa, jak tak to pracuję dalej”. Nawet nie wiecie jak bardzo coś takiego potrafi wybić z rytmu pracy. Plus jeszcze świadomość, że ktoś inny czeka aż to zrobię, bo bez tego nie może ruszyć dalej z robotą. Dramat.

Druga korzyść – tester po prostu testuje lepiej niż programista czy product-owner, czy ktokolwiek inny, kto próbuje chybcikiem wskoczyć w jego buty. Skok w jakości dowożonego oprogramowania jest widoczny gołym okiem. Metryką, która najlepiej to obrazuje, jest ilość błędów znalezionych dopiero na produkcji przed i po zatrudnieniu testera. Im wcześniej znajdziemy błąd tym taniej kosztuje nas jego naprawienie – a błędów na produkcji nie chcemy mieć wcale.

Trzecia korzyść – odkąd ja osobiście pracuję z solidnym, godnym zaufania testerem po prostu lepiej śpię. Nie obawiam się aż tak bardzo, że któreś moje zmiany popsują system, bo po prostu przeoczyliśmy jakiś oczywisty, krytyczny błąd. Cały zespół pracuje lepiej. Jesteśmy gotowi podejmować bardziej brawurowe akcje i przebudowywać większe fragmenty systemu na raz – bo wiemy, że ktoś czuwa i ubezpiecza nasze tyły. Możemy się rozpędzić zamiast mierzyć każdy krok jakbyśmy szli przez pole minowe. Oczywiście nie znaczy to, że min już tam więcej nie ma – one dalej tam są, tylko że nie wybuchną nam prosto w twarz, bo sprawny tester zdąży je rozbroić zanim staną się dla nas groźne. Efekt ten jest bardzo trudno zmierzyć i przeliczyć na konkretne zyski z perspektywy firmy – ale on tam jest i w moim przekonaniu jest bardzo silny. Im lepszy tester, im sprawniej potrafi współpracować z programistami tym efekt ten jest większy.

Czwarta korzyść – tester w naturalny sposób staje się osobą, która najlepiej zna system. Typowy zespół programistyczny składa się zazwyczaj z kilku programistów i jednego testera. Programiści najczęściej pracują w pewnych typowych dla siebie obszarach tego system - jeden pracuje tutaj, inny gdzieś indziej. Czasami się wymieniają, ale nie jest to zbyt efektywne, bo żeby zacząć pracować najpierw muszą poznać ten ‘obcy kod’, a jak każde dziecko wie - czytanie kodu to 80% czasu a pisanie tylko 20%. Co więcej, różni programiści znają się na różnych technologiach – mamy frontedowców, którzy umieją robić UI, mamy backendowców którzy umieją budować API i mamy fullstacków, którzy nie umieją nic zrobić. Natomiast tester wszystkie te obszary po wszystkich tych programistach testuje. A gdy testuje to samoistnie przyswaja sobie jak cały ten system działa. Nikt w zespole nie ma tak szerokiej perspektywy i wiedzy o systemie jak tester. No i co z tego? Bardzo wiele! Ciężko jest rozwijać system, o którym nie do końca wiemy, jak działa – dlatego też taki tester staje się ważnym uczestnikiem wszelkich debat, gdy planujemy co możemy zbudować dalej i jak to zbudować, żeby nie naruszyć pozostałych funkcji już istniejących w systemie. Taki tester staje się też dobrym pierwszym kontaktem, żeby udzielać odpowiedzi innym osobom spoza zespołu na temat funkcji systemu – przez co ekranuje dodatkowo swoich programistów od zewnętrznych zakłóceń. Tak jak w punkcie pierwszym – mogą się skupić na swojej robocie.


Podsumowanie

W moim przekonaniu tester to nieodzowny składnik zespołu programistycznego, który jest warunkiem koniecznym wytwarzania oprogramowania o wysokiej jakości. Sam nigdy bym nie chciał pracować bez solidnego testera u mojego boku – to po prostu nie ma sensu. Uważam, że trzyosobowy zespół zbudowany z dwóch programistów i testera może roznieść w pył zespół zbudowany z samych programistów.



327 wyświetleń0 komentarzy

Ostatnie posty

Zobacz wszystkie

Comments


bottom of page