Testerze, nie wkurzaj developera!

3 czerwca 2018 | Goście na blogu

Wpis gościnny

Autor: Piotr Data

Od 10 lat związany z programowaniem stron internetowych, gdzie w czasie swojej kariery zawodowej zrealizował przeszło 140 projektów. Niektóre z tych projektów prezentuje w swoim portfolio. Zdobywca wielu nagród i wyróżnień w międzynarodowych konkursach i plebiscytach.

Mój pierwszy wpis i to jeszcze w dodatku na poczytnym blogu, coś cudownego! Od razu z tego miejsca chciałbym podziękować Magdalenie za zaproszenie 🙂 . Długo się zastanawiałem o czym mógłbym napisać, w końcu to mój debiut. Nie jestem specjalistą w dziedzinie testowania oprogramowania a musiałem coś stworzyć. Ale co tutaj napisać żeby nie zawieść Magdy? Siedziałem i myślałem aż w końcu eureka! – napiszę rozprawkę. I tutaj pojawił się kolejny problem – no kurcze, ale o czym? W głowie miałem miliony pomysłów, zrobiłem szybkie losowanie i na początek postanowiłem napisać coś lekkiego. Dzisiaj zajmiemy się podziałami na nas i Was, na programistów i testerów, i zastanowimy się nad tym co powoduje, że czasami te grupy nadają na całkowicie innych częstotliwościach.

Jednak na samym wstępie pragnę się przedstawić. Mam na imię Piotr i jestem programistą (zabrzmiało to trochę jak tekst z grupy wsparcia 🙂 ). Działam w ogólnie pojętym webdevelopmencie i temu poświęcam się przez całość swojego zawodowego życia. Wiele lat przepracowałem w malutkiej firmie gdzie panowała zasada „przetestuj to sam”. Nie posiadaliśmy nikogo wykwalifikowanego z zakresu QA, pojęcie testowania było tylko mitem a każdy pracownik firmy jak tylko mógł i miał czas sprawdzał wszystko we własnym zakresie (choć nie zawsze). Przyznam szczerze, że ja sam w owym czasie nie widziałem żadnej wartości w testowaniu oprogramowania (oczywiście teraz sprawa wygląda całkowicie inaczej 🙂 ). Wówczas proces testowania sprowadzał się do puknięcia sąsiada w ramię i wydania rozkazu – „ej weź tam coś poklikaj i zobacz czy działa” – i o dziwo najczęściej działało i to wystarczało aby oddać klientowi „gotowy” produkt. I jakoś to się wszystko kręciło, projekty leciały jak na taśmie, jeden za drugim. Klienci byli zadowoleni, ja byłem zadowolony a szefowie byli mega zadowoleni aż do dnia kiedy zostałem zmuszony opuścić rzeczoną firemkę i poszukać sobie nowej pracy.

Losy rzuciły mnie do dużej, międzynarodowej korporacji, o której dowiedziałem się całkowicie przypadkiem (tutaj puszczam oczko do autorki bloga 🙂 ). Nowa praca to nowe wyzwania, nowe doświadczenia i obserwacje. Obecnie pracuję w miejscu, gdzie testowanie nie jest dodatkiem, tutaj jest podstawowym elementem procesu wytwarzania oprogramowania. Na samym początku, w pierwszy dzień nowej pracy, zostałem przeszkolony przez współpracowników. Poza tak trywialnymi rzeczami, jak podstawy Scruma czy zasady prowadzenia projektu, zaaplikowano mi potężną dawkę reguł społecznych panujących w firmie. Od początku dało się zauważyć, że niektórzy próbują tworzyć sztuczny podział na plemiona. Podczas jednej z rutynowych wycieczek po siedzibie firmy zobaczyłem salę pełną ludzi. Odbywało się tam jedno z cyklicznych spotkań naszej kadry QA. Ten tekst, który usłyszałem tamtego dnia od jednego z programistów utkwił mi w pamięci do dzisiaj: „widzisz ich? to są testerzy, najbardziej sfrustrowana grupa zawodowa w IT”. Początkowo się zdziwiłem, pierwszy dzień w pracy i od razu taka informacja? Niczym przestroga – „oooooo… na tych to uważaj!”. To było jak nadepnięcie gołą stopą na klocek Lego, z miejsca dało mi impuls do myślenia. Starałem się odnaleźć przyczynę takiego stanu rzeczy, chciałem się dowiedzieć dlaczego niektórzy programiści tak alergicznie czy wręcz agresywnie reagują na słowo „tester”.

Myślałem, że temat dotyczy tylko mojej nowej pracy ale jednak po konsultacjach z kolegami z innych firm zauważyłem, że problem dotyczy szeroko pojętej branży IT. Oto jeden z przykładów: w znanej dużej polskiej firmie nie wydano pisanego przez wiele lat oprogramowania, tworzonego na podstawie zamówienia publicznego, ponieważ okazało się, że obliczenia jakie pokazuje nie są zgodne z wymaganiami prawa UE. Tak się składa, że w owej firmie pracowało trzech moich znajomych. Podczas rozmowy przy piwie jeden z nich powiedział wprost – „to wszystko wina testerów”. To ta grupa w jego mniemaniu była winna całej sytuacji, ponieważ wg. niego „nie przetestowali wszystkiego odpowiednio”. Podczas dalszej rozmowy nie poruszaliśmy już tego tematu, ponieważ słowo „tester” działało na niego jak wyzwalacz uruchamiający potok przekleństw i agresywnych hasełek. Jego frustracja była tym bardziej uzasadniona ponieważ znaleziony problem w połączeniu z marną architekturą tworzonego rozwiązania były dla niego przepustką do spędzania upojnych nadgodzin i łataniu na szybko tego co się dało. Jak się później okazało, to właśnie testerzy wskazali uchybienia poczynione w programie. Innym razem mój znajomy stwierdził, że przez testerów spędza godziny na naprawianiu błędów ponieważ „ciągle coś znajdują”. Dla niego nie było problemem to, że błędy są, dla niego najgorsze było to, że zostały znalezione. A to tylko drobny fragment tego, czego nasłuchałem się od kolegów na temat testerów. Podczas tegorocznego TestingCup specjalista od zabezpieczeń – Dawid Bałut – podczas referatu dotyczącego idei „DevSecOps” również wspomniał o problemie podziałów w grupach deweloperskich.

Ale jaka jest tego przyczyna, przecież wszyscy pracujemy przy tworzeniu oprogramowania, każdy z nas dokłada cegiełkę aby było dobre i niezawodne. Po jakimś czasie współpracy z testerami sam zauważyłem, że jest zestaw cech i zachowań testerów, które niezwykle denerwują programistów a ostatecznie powodują powstawanie niechęci i konfliktów. Po prawie dwóch latach badań, poszukiwań, rozmów z innymi programistami oraz własnych doświadczeń stworzyłem swój prywatny, subiektywny katalog 5 dobrych rad, które wg mnie przynajmniej w jakimś stopniu powinny poprawić relacje pomiędzy zwaśnionymi stronami. Oczywiście jest to ranking świadomie jednostronny, punktujący głównie cechy testerów (choć programistom też się dostaje). W przyszłości mam zamiar stworzyć podobną listę – dotyczącą programistów. To tyle tytułem wstępu – zaczynamy:

Z programistą obchodź się jak z jajkiem

Jak najłatwiej wkurzyć każdego programistę? Pokazać mu cholernego buga! Wszyscy znamy to uczucie, kiedy siedzisz nad czymś godzinami, pieścisz, pielęgnujesz, a potem okazuje się, że to ustrojstwo nie działa tak jak powinno! Taka sytuacja jest tym bardziej irytująca, kiedy tester dorzuca swoje 3 grosze. Pamiętaj, informacja o znalezionym błędzie powinna być przekazana w odpowiedni sposób, najlepiej najbardziej delikatnie jak się tylko da. Ten biedny programista jest już dostatecznie poirytowany samym faktem znalezienia błędu, nie należy dodatkowo go denerwować niewłaściwym zachowaniem testera. Wiadomo, poszukiwanie błędów to esencja tego zawodu ale nadmierny triumfalizm i ogłaszanie wszem i wobec faktu wytropienia jakiegoś buga to przesada. Tym bardziej, jeśli błąd generuje jakieś śmieszne rezultaty. Dla kogoś z zewnątrz to jest śmieszne, ale nie dla programisty, który poświęcił na stworzenie danej funkcjonalności dziesiątki godzin pracy oraz zniszczył wątrobę hektolitrami energy drinków. Czasami byłem świadkiem, baaaaaaa, sam także tego doświadczyłem, kiedy tester lub grupa testerów zaczyna się nabijać – „teeeee, zobacz jakiego babola znalazłem, tego nie widać, a da się dalej kliknąć, hahahaha” – oczywiście całość wyartykułowana w taki sposób aby niosło się przez cały open space. Testerze, błagam, nie rób tego, bo budzisz demony!

Pod żadnym pozorem nie mów, że umiesz programować

Nie wiem czemu taka informacja działa na niektórych programistów jak płachta na byka. Bardzo duża część (ja do niej nie należę 🙂 ) plemiona developerów uważa, że testerzy nie potrafią programować. Być może jest w tym ziarno prawdy, bo pewnie wśród jednych i drugich można znaleźć jednostki mniej lub bardziej uzdolnione. Osobiście znam ludzi, którzy są programistami od wielu lat, a tworzą gorsze automaty niż niejeden początkujący tester. Taka niestety jest smutna prawda, że to bardzo niesprawiedliwy i krzywdzący stereotyp. Co więc zalecam? Najlepiej nie wchodzić w polemikę, nie wspominać w ogóle o tym temacie. Programista zawsze strzeli tekst w rodzaju: „ty nie programujesz, ty tworzysz proste skrypty, zrób coś o większej architekturze to porozmawiamy”. Co wtedy? Nie kłóć się, nie sprzeczaj, po prostu rób swoje, a gwarantuję, że poczujesz wewnętrzną radość kiedy twój automat znajdzie błędy w programie napisanym przez krnąbrnego developera. Czyli reasumując – zapominamy o tym, że potrafimy programować (tzn. nie tak całkowicie :)) ale tylko w sytuacji kiedy w okolicy znajduje się wredny programista.

Wykazuj inicjatywę

Zauważyłem, że jest pewna grupa testerów (bardzo mała), która tylko czeka żeby wszystko było podane na talerzu. Kiedy słyszę pytanie – „ej czy mógłbyś mi powiedzieć co mam tutaj przetestować?” lub „powiedz mi jak to powinno działać” – od razu widzę pole do manewru. Po pierwsze udowadniasz, że można tobą sterować, po drugie wyglądasz jak totalny amator a tym samym nie wzbudzasz szacunku. Jeśli pokazujesz programiście, że czegoś nie wiesz pamiętaj, że ta podła bestia od razu to wykorzysta (przyznam się bez bicia, sam kiedyś tak robiłem 🙁 ). Mnie udało się kilka razy przekabacić testera do tego stopnia, że odnalezione błędy okazywały się funkcjonalnościami. Jak temu przeciwdziałać? Musisz pokazać się jako silny, posiadający szeroką wiedzę fachowiec. Krótko mówiąc, nie połykaj jak pelikan wszystkiego co mówi programista. Jeśli słyszysz, że „czegoś nie da się zrobić lub nie da poprawić” to staraj się wszystko samemu zweryfikować. Zawsze możesz skonsultować się z innym developerem, np. z innego zespołu lub ostatecznie poszukać w internecie. Z drugiej strony ciągłe pytania o to „jak coś zrobić” strasznie wkurzają. Pamiętaj, że developer wybijany z ciągu myślowego jest bardziej podatny na produkowanie błędów.

Nie bądź tyranem

Ale z tą siłą to nie przesadzaj zanadto. Buduj swój autorytet wiedzą i wartością argumentów a nie rządami silnej ręki. Pamiętaj, że często ty decydujesz czy dana funkcjonalność trafi ostatecznie do produktu czy nie. Nie powtarzaj, że coś „nie działa tak jak powinno” przy każdej pierdółce. Jeśli będziesz usilnie blokować wszystko to w końcu staniesz się obiektem nienawiści. Programista to też człowiek, który często przywiązuje się do tego co tworzy. Wskazywanie, że to co zrobił jest nic niewarte (bo jeśli nie staje się częścią oprogramowania to tak w zasadzie jest) prowadzi do powstawania konfliktów. Każdy znaleziony błąd powinien być polem do konstruktywnej debaty, zawsze można znaleźć kompromis. Nie warto kruszyć kopii o drobnostki. Literówka czy inna głupota nie jest powodem do blokowania. Nie wszystkie błędy da się poprawić a niektóre z nich nie są wynikiem działania programisty. Z własnego doświadczenia mogę dodać, że dobrze jest kiedy specjalista zajmujący się jakością zna problemy i niedomagania danej platformy, na którą tworzone jest oprogramowanie. To jest szczególnie ważne w przypadku tworzenia rozwiązań na przeglądarki internetowe gdzie o coś nazywanego przez testera „bugiem” nie trudno.

Czekaj cierpliwie

Nikt nie lubi być poganiany, ty pewnie też tego nie lubisz. Oprogramowanie jak drogi ser potrzebuje czasu żeby dojrzeć. Zadawanie co jakiś czas pytania – „czy mogę już to ponownie przetestować, bo chcę zamknąć ticket?” – wcale nie posuwa roboty do przodu, wręcz przeciwnie, prowadzi do konfliktów i wzajemnych animozji. Zwłaszcza kiedy pali się produkcja, gdy zaczyna się wyścig z czasem i nerwówka. Pamiętaj – „cierpliwość jest cnotą królów”.

To tyle jeśli chodzi o moje dobre rady. Na wstępie napisałem, że w branży IT rządzą podziały. Może jest to nieusprawiedliwiony osąd, ale mam do tego pełne prawo. Dla mnie te podziały nigdy nie były istotne, zawsze darzyłem testerów szacunkiem za wykonywaną pracę. Ja sam zacząłem interesować się zagadnieniami dotyczącymi szeroko pojętej jakości. Często siedząc popołudniami w domu łapię się na tym, że chciałbym napisać jakiś automacik :), w tym roku byłem nawet uczestnikiem imprezy TestingCup, nie brałem udziału w zawodach ale sama obecność to już dla mnie wyróżnienie i pierwszy krok do zostania QA developerem. Ostatnio w ramach swojego projektu zajmuję się głównie A/B testami co sprawia mi niemałą frajdę 🙂 .

A na koniec pamiętajcie, wszyscy pchamy ten sam wózek. Dobra współpraca jest kluczem do tworzenia wspaniałego oprogramowania. Jak mawiał Franklin Delano Roosevelt – „Ludzie pracujący razem jako jedna grupa potrafią dokonać rzeczy, których osiągnięcie nie śniło się nikomu z osobna”.

A teraz zapraszam do podzielenia się waszymi doświadczeniami w komentarzach. Może spotkaliście się z podobną sytuacją jak przytoczone przeze mnie w tekście, może macie w sobie małego sadystę i lubicie denerwować programistów a może z drugiej strony jest coś co niebywale wkurza was?

Najnowsze wpisy

CzytanQA: Steve Jobs

„Steve Job” autorstwa Waltera Isaacsona to dla mnie książka wyjątkowo z dwóch powodów. Po pierwsze, dostałam ją od bliskiej mi osoby. A po drugie dlatego, że to od niej zaczęło się moje zamiłowanie do biografii, reportaży i innych książek non-fiction.

CzytanQA: Labirynty Scruma

Scrumie książek napisano sporo. Dzisiejsza książka – Labirytnty Scruma – jest nieco inna, autor podchodzi do tematu od strony bardziej… problematycznej.

#3 Antywzorce w testowaniu oprogramowania: Korzystanie z niewłaściwego rodzaju testów

Wszyscy wiemy, jak z grubsza wygląda piramida testów: na dole jednostkowe, potem integracyjne, a szczytu akceptacyjne. Oznacza to po prostu tyle, że im wyżej w piramidzie, tym testów powinno być mniej… Ale mniej, to znaczy ile?

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!