0

Tester i programista jako zespół, wytwarzający solidny produkt

Cześć. Dzisiaj chciałbym poruszyć temat testerów oprogramowania. Zdecydowałem się na to zagadnienie z dwóch powodów. Pierwszym jest mój poprzedni wpis, który mógł wywołać oburzenie w społeczności testerów – przynajmniej tego się obawiałem, ale na szczęście, chyba tak nie było. Drugim powodem jest to, że czasami spotykam się z pogardą dla testerów, jako że niby mieliby być „gorsi”, czego też nie rozumiem a już na pewno nie akceptuję.

Artykuł ten miał być tylko zbiorem moich przemyśleń, ale z pomocą znajomego z pracy, został wzbogacony o punkt widzenia „drugiej strony” tj. właśnie testera.

Duet Pro-Test

Zacznę czymś od siebie. Uważam, że zarówno zawód testera nie miałby sensu bez programisty „dostarczającego” mu zadań, tak samo praca programisty nie byłaby tak efektywna bez testerów, którzy to potrafią rozwalić jego kilkugodzinną/dniową pracę w kilka minut 😉.

Wiem z doświadczenia, że programista nie wykryje wszystkich błędów w kodzie kolegi (o swoim już nie wspominając). Owszem, tester również tego nie zrobi, bo zawsze się coś prześlizgnie, ale na pewno wykryje więcej niż programista. A to dlatego, że jest to osoba kwalifikująca do takiej pracy, do tego też jest potrzebne specyficzne myślenie, potrzeba wyobraźni.

Poza umiejętnościami miękkimi, osoba taka musi posiadać również wiedzę techniczną. Fakt, że nie na takim poziomie jak programista, ale sposób działania danej aplikacji, środowiska (np. systemu) czy innych peryferii aplikacji jest według mnie wymagana, aby dobrze realizować swoje zadania.

Tester manualny a automatyczny

Chcę sprostować jedną rzecz, mianowicie to, że piszę o testerze manualnym. Nie mam doświadczenia w pracy z testerami automatycznymi (sam odpowiadam za testy automatyczne), więc nie będę się w tym temacie zbytnio wypowiadał.

Wydaje mi się, że odizolowanie programisty od testów też nie jest dobre, gdyż „traci kontakt” z aplikacją, ale z drugiej strony przecież testy jednostkowe to właśnie pole programisty, a takie CodedUI można już zostawić komuś innemu.

Tak jak wspominałem, ciężko mi się tutaj ustosunkować do tematu, gdyż znam tylko jedną stronę. Może ty masz jakieś doświadczenia? Podziel się proszę w komentarzu.

Psioczenie na testerów

Przeglądając różne fora czy nawet rozmawiając z niektórymi programistami, czasami można się spotkać z pogardą dla stanowiska testera. Bo przecież ON nic nie robi, tylko klika w ten program. To ja tutaj jestem twórcą.

Nie rozumiem ani trochę takiego podejścia. Przecież to są dwa różne stanowiska pracy, które mają różne wymagania. Osoba umniejszająca testerom, zakłada, że sama dałaby radę to zrobić. Możesz być dobrym programistą, ale będziesz do dupy testerem. Po prostu, każda z tych profesji wymaga innych umiejętności.

Kiedyś w pracy mieliśmy zespoły składające się tylko z programistów. Sprawdzanie zadań polegało na wzajemnej weryfikacji zaimplementowanych funkcjonalności. Ja Tobie a Ty mnie. Jakoś się to sprawdzało (tak nam się wydawało), dopiero po czasie, jak do zespołów dołączyli testerzy, zdaliśmy sobie sprawę, że nie działało. Od czasu testerów, programy były mniej zawodne, dużo rzeczy poprawiane było jeszcze na etapie implementacji. Program stał się bardziej intuicyjny i przejrzysty. To jest profit, dołączenia testera do zespołu.

Cechy charakteru a współpraca

Ważną rolę w zespole programista-tester odgrywa charakter tych osób. Niektóre cechy charakteru będą pomagać, inne uniemożliwią udaną współpracę.

Zaczynając od programisty. Na pewno musi wykazywać się szacunkiem do osoby krytykującej jego pracę. Poza szacunkiem, musi umieć przyznać się do błędu i wyciągnąć wnioski, ewentualnie zaproponować rozwiązanie/ kompromis. Nie może być tak, że kolega cofnie nam implementacje, bo coś nie działa, a my powiemy „e tam nie znasz się, tak ma być i tyle”, albo chociaż nie podejmiemy próby wyjaśnienia, dlaczego coś działa tak i nie może działać inaczej. Przerośnięte ego choć tak częste, nie jest za dobre w tej dziedzinie 😉.

Cierpliwość jest równie wskazana, zdarzało mi się, że czasami zadanie wracało kilka razy, bo zawsze coś się nie zgadzało, człowieka może szlag trafić. Siedzi ten …, kilka mi po programie i przypierdziela się o głupoty… No, ale to właśnie na tym polega jego praca, aby wyłapywał te błędy. Nawet nie zdajesz sobie sprawy jakie scenariusze Oni wymyślają, nie ma szans, aby to obłożyć testami automatycznymi.

A co z testerem?

Osoba testująca jak dla mnie powinna wykazywać się cierpliwością, skrupulatnością i wyobraźnią. Cierpliwość- bo przyjdzie Ci powtarzać te same scenariusze po ileś razy. Skrupulatnością- aby powtarzając te scenariusze po N razy, nie przeoczyć czegoś, bo „przecież działało, to i teraz musi działać”. Wyobraźnia też będzie Ci pomagała, gdyż banalne scenariusze obłożone są przez testy automatyczne. Dodatkowo wiedza techniczna, również będzie autem, jak przykład mogę podać tutaj SQL Injection (są jeszcze frameworki, które przed tym nie chronią?), czego nie przetestujesz nie znając szczegółów takiego ataku.

Generalnie dobra relacja z osobami z zespołu jest zawsze wskazana, co przekłada się na efektywność pracy. Dobrze też móc pogadać o pierdołach niezwiązanych z pracą, to też umacnia współpracę. Żeby była jasność, nie nawołuję tutaj do tego, aby na siłę z kimś gadać. Jak tego nie lubisz, to nie rób tego. Chodzi mi bardziej, aby w kontaktach międzyludzkich nie kategoryzować osób po stanowisku i zadawać się tylko z wybranymi (słyszałem o takich przypadkach, co jest co najmniej przykre).

Ale to ON zepsuł

No i najważniejsze, w przypadku fackupa, nie można zwalać winy, bo „on to miał przetestować”, albo przecież to” on to implementował”. Gramy w jednym zespole, razem odnosimy sukcesy, ale też razem mierzymy się z porażkami. Wytykanie winnych nic nie da, odpowiedzialny jest zespół, bo tak czy inaczej coś zepsuliśmy. Owszem były testy, ale był też CodeReview, były rozmowy o nowej funkcjonalności itp. itd. Odpowiedzialny jest cały zespół.

Nie jestem osobą z rekrutacji, też nigdy nie miałem okazji dłużej z taką osobą porozmawiać, ale wydaje mi się, że poza wiedzą techniczna, również cechy, które powodują, że zespół jest zgrany, też są sprawdzane na rozmowie kwalifikacyjnej.

Jeden zespół czy dwa zespoły

Spotkałem się z dwoma różnymi sposobami współpracy programistów i testerów. W pierwszym testerzy i programiści byli tak naprawdę dwoma oddzielnymi zespołami, porozumiewającymi się jedynie za pomocą jakiegoś TFS czy innego ustrojstwa. W drugiej wersji, testerzy stanowili integralną część zespołu developerskiego.

Pierwszy model uważam za oderwany od rzeczywistości. Za dużo szczegółów ucieka, jeżeli oba zespoły mają ze sobą tylko kontakt „elektroniczny”. Osoby współpracujące w jednym zespole będą ze sobą bardziej zgrane. Będą bardziej otwarte na krytykę i wspólne dyskusje. Nie będzie tekstów typu „testerzy znowu coś odbili… a to dzbany” itp. Przy wspólnych rozmowach na kawie może wyjść również kilka ciekawych rzeczy. Tak więc, model drugi jest według mnie lepszy, chociaż nie miałem okazji pracować w modelu pierwszym, więc może wyolbrzymiam sprawę (minusy). Wiem, że są firmy, gdzie pracuje się w modelu pierwszym i zdaje to egzamin, więc może to kwestia przyzwyczajenia?

Podsumowanie

Reasumując wszystko co napisałem, uważam, że praca programisty bez testera mija się z celem. Nie można dostarczać niezawodnego oprogramowania, nie mając osoby, która zweryfikuje program od strony użytkowej. Maszyna (automaty) nie dają gwarancji dobrego działania programu. Zawsze potrzebny jest człowiek. Tester jest nieopisanym i niezastąpionym ogniwem w każdym zespole programistycznym.

Od strony testera

I na koniec, tak jak zapowiadałem, chciałbym zamieścić kilka słów od Pawła. Paweł jest moim znajomym testerem z pracy. To właśnie od niego dostaje opierdziel, że nic nie działa :D. Pominę cały wstęp, który można spotkać w standardowych wywiadach, zamieszczę jedynie 3 kluczowe pytania i odpowiedzi Pawła.

Dlaczego uważasz, że zawód testera jest potrzebny?

Zagadnienie przewałkowane wielokrotnie przy okazji rozmów kwalifikacyjnych, ale nadal istotne i potrzebne. Świadomość przyczyny i celu testowania są według mnie bardzo ważne w kontekście podejścia i nastawienia do pracy. Uważam, że zawód testera jest nie tyle potrzebny, co nawet niezbędny, a to z racji prostego faktu – absolutnie każdy proces produkcji jest obarczony ryzykiem błędu. Oczywiście w różnych branżach, takowa pomyłka może mieć różne konsekwencje, ale co do zasady, każdy producent dąży do jak najlepszej jakości swoich towarów/usług, a w tym celu kontrola jakości jest zdecydowanie konieczna.

Czy automat może zastąpić człowieka?

Podejrzewam, że w ramach produktów, nazwijmy to elementarnych, jak np. śrubka, której testowane właściwości są bardzo konkretne i całkowicie mierzalne (np. kształt, waga, wytrzymałość) automat może być wystarczającą kontrolą jakości. Jednak w przypadku towarów finalnie złożonych i wielopłaszczyznowych, konieczna już będzie weryfikacja człowieka. Kluczową przewagą ludzkiej oceny jest szereg spostrzeżeń skupiony w szeroko rozumianym pojęciu UX, czyli „User experience”. To właśnie człowiek manualnie testujący np. oprogramowanie biznesowe, jest w stanie naświetlić zagadnienia takie jak intuicyjność, przejrzystość, czy też estetykę wykonania Front-end’u. W fatalistycznej wizji świata, opartej na samonapędzającym się rozwoju sztucznej inteligencji, maszyny najpewniej zastąpią człowieka we wszystkim, ale uznajmy, że póki co testerzy ręczni mają swoją rację bytu w procesie kontroli jakości i to rację bezsprzeczną 😉

Co jest najlepszego, a co najgorszego w pracy testera?

Zacznę od najlepszego, bo to przychodzi mi do głowy od razu – poczucie realnego wpływu na końcowy kształt tworu, który mam okazję testować. Z kolei, jeśli chodzi o największy mankament, to chyba będzie nim świadomość, że gruntowne i definitywne przetestowanie danego produktu jest niemożliwe. Dodatkowo odczucie to może być potęgowane w przypadku osób, mających skłonność do traktowania zleconych im zadań wszelakich w sposób osobisty, a ja raczej do takich osób należę.

Patryk Bogdański

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.