Agile,  Praca,  Zarządzanie

Czemu programiści nie chcą testować?

Taka dość typowa historia: w pewnym zespole programiści nie chcą zajmować się testami. Ba, Scrum Master, który jednocześnie jest też programistą przygotował nawet specjalną prezentację na ten temat by opowiedzieć o tym innym Scrum Masterom. Wynikało z niej, że testować ogólnie nie warto, bo programista przecież wie, że to co zrobił działa, więc to dla niego jest stratą czasu a poza tym programiści są od programowania, testów nie lubią. zresztą testy to coś pośledniejszego i oni się źle czują taką gorszą pracę wykonując. Więc nie będą.

Historię tą opowiedział mi niedawno zaprzyjaźniony Agile Coach z pytaniem dość oczywistym: co z takim przypadkiem robić? Oczywiście coś doradziłem (m.in. zasugerowałem szersze pochwalenie się na świecie kolegą Scrum Masterem – programistą, który tworzy bezbłędny kod – ktoś taki to prawdziwy skarb), miło porozmawialiśmy i być może nawet coś pomogłem. Niemniej pozostało poczucie pewnego niedosytu – miałem wrażenie, że w tej rozmowie nie doszliśmy do sedna sprawy.

Analizując przekonanie, że „programista nie powinien zajmować się testami” (względnie, że zajmowanie się nimi jest poniżej jego godności i statusu społecznego) dochodzę do wniosku, że opiera się ono przede wszystkiem na dwóch fałszywych przesłankach.

Pierwsza z nich, to przekonanie, że rolą programisty jest programowanie, a ściślej, że „rolą programisty jest tworzenie kodu”. Takie redukcjonistyczne podejście widzi osobę, która umie programować tylko w jednym wymiarze – tej właśnie jej umiejętności. Redukuje ją więc do biologicznej maszyny, która ma z punktu widzenia organizacji tą właśnie, jedną funkcję. Nie dziwota, że skoro maszyna „programista” umie tylko jedno – „tworzyć kod” – to trzeba ją odpowiednio nastawić, a więc poprzedzić ją maszyną „architekt”, która „zaprojektuje rozwiązanie” oraz dostarczyć jej półproduktu do przetwarzania, co jest zadaniem maszyny „analityk”, która go tworzy pod postacią „specyfikacji”. Po wyjściu z maszyny „programista” stawiamy maszynę „tester”, której zadaniem jest sprawdzić czy to, co zrobiła maszyna „programista” jest zgodne z tym, co wyprodukowała maszyna „analityk”. Wszystko na podobieństwo łańcucha wytwórczego w przemyśle.

Jak łatwo zauważyć wszystko jest zoptymalizowane na takie traktowanie pracownika począwszy już od etapu kształcenia (wąska specjalizacja), poprzez rekrutację (stanowiska opisane zadaniem, jakie ma być wykonywane) a kończąc na metrykach (godziny pracy tj. godziny wykorzystywania umiejętności). Dołóżmy do tego formowanie menedżerów w taki sposób, że każdy z nich niemal instynktownie czuje się zobowiązany do dbania o to, by każda maszyna (zasób) była maksymalnie zajęta – i mamy obraz dysfunkcyjnego mechanizmu, który umacnia to błędne przekonanie – a co za tym idzie jego konsekwencje.

Nie dziwne zatem, że wykształcona w tym kierunku i rozliczana z godzin programowania maszyna „programista” oburza się, gdy miałaby zajmować się czynnościami innych maszyn lub odpowiadać za ich wyniki. Nie dziwne, że osoba obsadzona w roli maszyny „programista” nie czuje się w pełni zaangażowana w produkt czy w całość pracy.

Tymczasem tak naprawdę zadaniem programistów, testerów i w ogóle wszystkich innych jest rozwiązywanie problemów użytkowników poprzez oprogramowanie, a więc dostarczanie użytkownikom nowych możliwości, które są dla nich wartościowe. Wymaga to wielu umiejętności i czynności – samo tworzenie kodu (a więc czynność przypisywana programistom) jest tylko jednym etapem tego procesu. Wśród tych umiejętności poza umiejętnością programowania mamy także umiejętności analityczne (rozumienie problemu) jak i związane z testowaniem oraz wiele innych. Wszystkie one są potrzebne i ważne, bo bez nich nie może powstać kompletny efekt pracy – a nie jest nim działające oprogramowanie, jest nim danie użytkownikowi wartościowych możliwości, których wcześniej nie miał.

Z pewnością jeśli zbierzemy zespół to różni jego członkowie mieć będą owe umiejętności rozwinięte i wyćwiczone w różnym stopniu. Jest to dobre, pod warunkiem, że będą z sobą współpracować w taki sposób by wykorzystać swoje silne strony i zminimalizować słabe, a więc możliwości zespołu były sumą ich możliwości. To zaś możliwe jest jedynie przy wspólnocie pracy (wszyscy razem tworzymy rozwiązanie dla naszego użytkownika/klienta) i odpowiedzialności za produkt. Innymi słowy „testera” równie interesuje poprawność rozwiązania co i „analityka” a programista przejmuje się nie tylko kodem, ale i tym czy ów kod działa oraz czy efekt jego działania spełnia oczekiwania klienta. Łatwiej jest stan taki osiągnąć jeśli patrzymy na zespół nie jako na zbiór odrębnych wyspecjalizowanych „maszyn” ale jako na grupę ludzi o różnych umiejętnościach, którzy wspólnie coś tworzą. Jak sądzę taki stan właśnie mieli na myśli twórcy Scruma kiedy nalegali, by wszystkich członków zespołu nazywać „developer” niezależnie od tego jaką specjalność reprezentują.

Druga fałszywa przesłanka, na której opiera się przekonanie, że „programista nie powinien zajmować się testami” to przekonanie, że „w pracy powinienem (wzgl. powinnam) zajmować się rzeczami przyjemnymi” połączone z brakiem odpowiedzialności za swoją pracę. Nastawienie takie nie jest szczególnie oryginalne, występuje nie tylko w naszej branży, przeciwnie – jest ogólną bolączką społeczną naszych czasów z ich naciskiem na „fun” i endemicznym brakiem zrozumienia dla takich pojęć jak obowiązek.

Temat to – wraz z naszym specyficznym tłem kulturowym – na osobny długi artykuł, dość powiedzieć, że konieczna jest pewna dojrzałość i odpowiedzialność, która powoduje, że wstydzimy się oddać pracę niekompletną. Oprogramowanie, które nie zostało przetestowane jest w sposób ewidentny niekompletne, zbudowane niezgodnie ze sztuką. Profesjonalny, odpowiedzialny programista powinien się tym przejmować i nie uważać, że czynności te go nie obchodzą i nie interesują. Nie powinien uważać, że to jest w porządku, że może oddać coś bo „u mnie działa” a sprawa ew. testów to już zajęcie dla kogoś innego, on jest ponad to.

Warto zauważyć, że w grach zespołowych – a Scrum to ma być „zespołowa gra w rozwój oprogramowania” (stąd nazwa) – choć są specjalności to jednak zawodnicy wychodzą poza nie jeśli jest to konieczne. Na przykład jeśli obrońca znajdzie się w sytuacji dogodnej do oddania strzału na bramkę przeciwnika to to zrobi, a nie będzie się wymawiał że on nie jest od tego specjalistą. Podobnie, napastnik nie będzie obserwował spokojnie z boku akcji drużyny przeciwnej twierdząc, że tą sprawą powinni zająć się obrońcy a jego to nie obchodzi, bo on się obronie źle czuje, pasjonuje go atak.

Ta metafora dość dobrze pokazuje o co chodzi. Nie idzie o to, że istnienie w zespole osób o specjalizacji bardziej ku testom („testerów”) nie ma sensu, przeciwnie, niemniej granica nie powinna być tak ostro zarysowana jak to ma miejsce ewidentnie w umyśle osoby, która zainspirowała ten przydługi artykuł. Innymi słowy nie powinno być podziału w zespole, powinna być współpraca, w ramach której każdy robi to co umie najlepiej – ale w miarę potrzeby także i to, co robi tylko przeciętnie, w ten sposób najlepiej jak umie wkładając swój wysiłek w pracę zespołu w danym momencie i na danym etapie. Oczywiście, jest to trudniejsze niż po prostu powiedzenie, że „ja nie będę tego robił” będące właśnie przejawem braku dojrzałości. W połączeniu z równie fałszywym przekonaniem, że celem metod Agile jest aby pracownikom – a szczególnie programistom – było miło i przyjemnie prowadzi to do wypowiedzi i postaw jak wyżej.

Co zatem należy robić? Po pierwsze usunąć mechanizmy organizacyjne, które mogą wzmacniać pierwsze przekonanie (przede wszystkim skończyć z naciskiem na to, by wszyscy byli zajęci i idiotycznym liczeniem godzin). Po drugie zdecydowanie walczyć z niedojrzałością i nieodpowiedzialnością, najlepiej już na etapie rekrutacji.

komentarze 2

  • Kuba

    Jako wspomniany „Scrum Master – programista”, czuję się wywołany do odpowiedzi na ten oryginalny artykuł i jako taki – pragnę odnieść się do kilku wyodrębnionych z tekstu punktów. Zaznaczam, że wyciągnięte przez autora wnioski w dużej mierze uważam za słuszne, jednak konkretny przykład będący podstawą wpisu – nie ma nic wspólnego z rzeczywistością.

    Opisany w artykule zespół traktować należy wyłącznie jako HIPOTETYCZNY, a nie faktyczny.

    1. „W pewnym zespole programiści nie chcą zajmować się testami”

    Został tu przeoczony bardzo istotny fakt: programiści nie chcą testować REGULARNIE.

    Spieszę z wyjaśnieniem, wykorzystując wspomniany przez autora przykład piłkarzy. I tak – jeśli okazja do strzału trafia się obrońcy, naturalną jest decyzja o posłaniu piłki do siatki. Co więcej, obrońca zobowiązany jest do pomocy kolegom z ataku. Analogiczne wsparcie obrońców przez atakujących należy do dobrych praktyk zespołowych. Problem pojawia się kiedy obrońca regularnie gra w ataku, lub atakujący w obronie, natomiast trener liczy na sprawne, płynne zmiany ról, a przy tym stuprocentową skuteczność.
    Należałoby się wówczas zastanowić skąd taka potrzeba wynika i opracować skuteczną taktykę – wszak to nie są zawody w bezcelowym bieganiu w poprzek boiska.

    2. „Wynikało z niej, że testować ogólnie nie warto, bo programista przecież wie, że to co zrobił działa”

    Wspomniany „Scrum Master – programista” nigdy nie użył tego stwierdzenia!
    Prezentacja zawierała natomiast informację, że programiści mają naturalną tendencję by „iść na skróty”. Zamiast żmudnie wykonywać kilka przypadków testowych (z powtarzającą się częścią scenariusza testowego) z poziomu aplikacji, wykorzystają swoje natywne narzędzie jakim jest kod źródłowy, upewniając się, że opracowywany przypadek zwróci oczekiwane wyniki na poziomie opisowym (kodu).
    W zespole, o którym wspomina autor nie ma ani jednego (!) członka zespołu uważającego, że testy są zbędne. Wręcz przeciwnie.

    3. „Programiści są od programowania, testów nie lubią”

    To kwestia indywidualna. Powyższe jest uogólnieniem.
    Uogólnienia są krzywdzące.

    4. „Testy to coś pośledniejszego i oni się źle czują taką gorszą pracę wykonując”

    Ponownie nie mogę się zgodzić, iż testy to praca „gorszego sortu”. We wspomnianym zespole wszyscy członkowie są świadomi jak istotnym elementem wytwarzania oprogramowania są testy.

    5. „m.in. zasugerowałem szersze pochwalenie się na świecie kolegą Scrum Masterem – programistą, który tworzy bezbłędny kod – ktoś taki to prawdziwy skarb”

    Wspomniany „Scrum Master – programista” nigdy nie twierdził, że wytwarza bezbłędny kod. Twierdzi, natomiast że zarówno kod jak i testy wytwarzane przez jego zespół, są produktami wysokiej jakości. Sprawiedliwie byłoby pochwalić się całym zespołem, a nie jego częścią w osobie „Scrum Mastera – programisty”. Samo sformułowanie zaś wyczerpuje znamiona mało subtelnej deprecjacji wartości wspomnianego „Scrum Mastera – programisty”.

    6. Pragnę odnieść się do tezy, że programista, tester, architekt, analityk to niezależne „maszyny”

    Pomijam dehumanizację zespołu i odnosząc się do tej analogii – w moim przekonaniu maszyną jest cały zespół. Jego członkowie są niejako modułami których wspólna, niezakłócona praca pozwala na wytworzenie oczekiwanego produktu. Żaden z modułów nie działa samotnie zawieszony w próżni. To organizm złożony z części, których wydajność i efekt pracy zależą bezpośrednio od tego czy są używane zgodnie z ich przeznaczeniem. Podejmując ryzyko wymiany modułów, należy zatem brać pod uwagę sprawność i parametry wytrzymałościowe zamienników.

    7. „W pracy powinienem (wzgl. powinnam) zajmować się rzeczami przyjemnymi”

    Z tą tezą w odróżnieniu od autora zgadzam się w pełnej rozciągłości. Praca zawodowa zamiast być przykrym obowiązkiem, może być zajęciem wykonywanym z pasją. Jednocześnie szanuję odmienne w tej kwestii podejście autora.

    8. „Po drugie zdecydowanie walczyć z niedojrzałością i nieodpowiedzialnością, najlepiej już na etapie rekrutacji”

    Punkt ten skłania mnie ku refleksji nad zasadnością ekonomiczną takiego działania. Z analizy średnich stawek wynagrodzenia wynika, że średnio programiści opłacani są wyżej niż testerzy. W takim ujęciu regularne powierzanie pracy testerskiej programistom pozostawiam do oceny czytelników.

    Na koniec, chciałbym podkreślić, że tytułowy zespół pracuje zgodnie z wartościami bliskimi autorowi artykułu, wykorzystując przy tym najlepszą dostępną sobie wiedzę oraz praktyki poparte doświadczeniami.

    • andy

      Miło mi, kiedy w fikcyjnym zespole złożonym z różnych, z którymi miałem do czynienia ktoś odnalazł się na tyle, że poczuł się osobiście wywołany do tablicy. Fajnie, że mój tekst wywołał reakcję i skłonił mam nadzieję do refleksji. Do tematu jeszcze będę powracał. Pozdrawiam!

      PS. Proszę rozważyć to zdanie „To organizm złożony z części, których wydajność i efekt pracy zależą bezpośrednio od tego czy są używane zgodnie z ich przeznaczeniem.” i zastanowić się przejawem czego jest mówienie o ludziach tworzących zespół, że są częściami mającymi konkretnie zdefiniowane przeznaczenie.

Komentowanie

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *