Komputery praca

Czy każdy programista powinien umieć testować? Devdebata

Jak doświadczenie programistyczne pomaga w byciu lepszym QA?

Miłosz: Otwiera nowe możliwości – automatyzacja testów, testowanie backendu, wejście w tematy CI/CD. Umiejętność programowania pomaga usprawnić pracę – manualne regresje wypaliły niejednego testera, a dzięki automatyzacji to ryzyko zdecydowanie maleje. Mam też wrażenie, że programiści inaczej patrzą na testerów, którzy potrafią coś napisać. Dzielimy podobne problemy i trudności, co przekłada się na rozmycie twardego podziału na testerów/programistów – który w wielu firmach jest nacechowany mocno negatywnie.

Tomasz: Ja zawsze u innych QA doceniam wiedzę i doświadczenie z zakresu, który nie podpada stricte pod testowanie. Uważam, że bardzo przydatne umiejętności dobrego QA to rozumienie kodu i uczestniczenie w code review, umiejętność konfigurowania i zautomatyzowania procesów CI/CD, brak oporów przed wejściem w buty analityka biznesowego i spisanie wymagań na podstawie rozmowy lub mini-warsztatów z klientem. Warto również znać podstawy efektywnego zarządzania zespołem i umieć budować w zespole świadomość tego, czym jest jakość i jak o nią dbać. Zasadniczo dobry QA powinien wypełniać luki w zespole, które powodują, że zespół nie jest w stanie dostarczyć klientowi wysokiej jakości wartości biznesowej w sensownym czasie. O tym, czym jest “wysoka jakość” i “sensowny czas” decyduje już specyfika projektu i świadomość zespołu.

Miłosz: Podpisuję się pod tym, że dobry QA powinien wypełniać luki w zespole. W wielu projektach, w których pracowałem tak właśnie było. Dlatego tak ważne jest rozwijanie się w wielu kierunkach – nie tylko stricte testerskich/programistycznych. 

Ostatnio widzimy wzrost zainteresowania tematyką testingu. Jak myślicie, skąd się to wzięło? Czy testowanie będzie popularnym kierunkiem rozwoju w IT w najbliższych latach?

Hubert: Jeżeli mam być szczery, to wydaje mi się że zainteresowanie przez osoby niedoświadczone wynika trochę z mylnego przeświadczenia, że tester (w szczególności manualny) to najłatwiejsza droga na wejście w spopularyzowany rynek IT $$$. Czy będzie popularnym kierunkiem? Wydaje mi się że tak, bo będzie ciężko zmienić te przekonania. A z perspektywy osób, które już siedzą w branży to myślę, że stawia się większy nacisk na jakość, a co za tym idzie – na testowanie. Interesariusze widzą w tym wartość nie tylko jakościową, ale wiedzą, że znalezienie błędu wcześniej redukuje wydatki poniesione na jego wyeliminowanie. 

Miłosz: Moim zdaniem testowanie to droga z najniższym progiem wejścia (w sensie wiedzowym)  do branży IT, co wiąże się też z prawdopodobnie najliczniejszą konkurencją i dużą ilością CV wysyłanych na juniorskie stanowiska. Uważam, że jak ktoś jest dobry, to niezależnie od obranej drogi (tester, programista, analityk biznesowy, itd.) to szybko wejdzie w branżę. 

Cała branża się rozwija, więc myślę, że z testowaniem nie będzie inaczej. Na pewno cieszy rosnąca świadomość klientów dotycząca potrzeby testowania.

Tomasz: Oprócz wspomnianego niższego progu wejścia, mam wrażenie, że rola QA łatwiej pozwala przekształcić się w innym, być może dla danej osoby bardziej atrakcyjnym kierunku, jak Analityk Biznesowy, UX/UI Designer czy też programista. Dodatkowo jeszcze kilka lat temu stawki QA byłī przeważnie niższe od programistycznych, a ostatnimi czasy te różnice się wyrównały.

ZOBACZ TEŻ:  Jak wygląda rynek testerów, QA w Polsce? Devdebata

Wspomnieliście mi o ciekawych pytaniach na rekrutacjach na testerów. Możecie je przytoczyć – i przy okazji podzielić się trafnymi odpowiedziami? 

Miłosz: “Jak przetestowałbyś stół/szklankę/cokolwiek?” – różne rozmowy, podobne pytania, a najprostsza poprawna odpowiedź to – zgodnie z wymaganiami. Zdarzało się, że rekruter nie był zadowolony z takiej odpowiedzi i wtedy trzeba było bardziej kreatywnie podejść do takiego pytania, np. wymyślając cały proces testowy dla danego przedmiotu.

Tomasz: Przywołane pytanie “jak przetestowałbyś ten stół?” jest naprawdę dobre. Jeśli zaczniemy sprawdzać, czy stół jest stołem, to już wpadamy we własną pułapkę, zakładając, że ten stół ma pełnić funkcję stołu. Być może klient chciał krzesło, ale się z nami nie dogadał. Co z tego, że dostanie super stół, jeśli jego potrzebą jest krzesło? Bez zrozumienia kontekstu biznesowego i potrzeb końcowych użytkowników nie jesteśmy wstanie powiedzieć, czy dostarczamy dobre rozwiązanie.

Dobre są pytania, na które nie ma jednoznacznej odpowiedzi – kiedy zacząć testować (jak najwcześniej), kiedy skończyć testować (najlepiej nigdy, nawet na produkcji można testować, jeśli chcemy pierwsi wiedzieć, że coś nie działa), po co testować, czym jest jakość. Tutaj kandydat pokazuje, jak bardzo rozumie sens roli QA. Warto też spytać o to, jak dana osoba widzi swoją rolę w zespole, co zrobi, gdy wejdzie do projektu – to może pokazać, jak szeroka jest perspektywa danego kandydata. Inna użyteczną informacją jest to, jak dana osoba się rozwija, czego się ostatnio nauczyła – dzisiejszy rynek IT docenia dużo bardziej zdolność adaptacji i zmiany kontekstu niż wiedzę per-se, a wynika to z dynamiki jego rozwoju.

Hubert: Jak Tomek napisał o tym, że klient chciał krzesło, a dostał stół, to aż mi się przypomniał ten mem:

mem drzewa

A patrząc szerzej – na co zwraca się uwagę przy rekrutacjach na te stanowiska?

Miłosz: Warto wiedzieć o czym się mówi – uczenie się suchej teorii, bez żadnego odniesienia do praktyki jest błędem. Dla mnie zawsze ważnym czynnikiem (niestety jest to dosyć subiektywne), na który zwracałem uwagę podczas rozmów rekrutacyjnych było: Czy dobrze współpracowało by mi się z tym kandydatem? Poza wiedzą/umiejętnościami ważne jest podejście do pracy, ludzi, a także napotykanych problemów. 

Tomasz: Na rekrutacjach na QA, oprócz doświadczenia zwracam również uwagę na zaangażowanie danej osoby, na jej determinację w dojściu do sedna problemu, jak i na zdolność wybrnięcia z trudnej sytuacji (np. gdy programista mówi, że nie naprawi tego buga “bo nie”). Ważnym jest też podejście danej osoby do teamu. Jeśli na któreś trudne pytanie pada odpowiedź w stylu “zwrócę się o pomoc do innego członka zespołu” to oznacza, że osoba ta będzie współpracowała z zespołem, zamiast kręcić się w kółko nad nierozwiązanym problemem.

Jak Waszym zdaniem będzie wyglądała przyszłość tej branży?

Hubert: Przyszłość branży… hmmm myślę, że pójdziemy w stronę większej automatyzacji i skupienia się na testach bardziej szczegółowych i przypadków, które ciężko jest obsłużyć automatami. W programowaniu wielkim tegorocznym hitem jest np. Github copilot wykorzystujący AI do generowania kodu na podstawie komentarzy i tego, co napisaliśmy wcześniej. Może będziemy szli też w tę stronę? Kto to wie. 

Tomasz: Mam nadzieję, że Hubert ma rację. Fajnie by było, aby w każdym projekcie była automatyzacja testów, uporządkowany proces, duża świadomość biznesowa i zaangażowani ludzie. Między innymi rolą QA jest to, aby projekty tak wyglądały.

Hubert: Tu jeszcze tylko dodam, że QA ma się zająć dostarczaniem oprogramowania wysokiej jakości, a co za tym idzie jego zadaniem nie są tylko testy, tak jak wspomniał Tomek.

A Wy – macie może plany na dalszy rozwój ścieżki kariery?

Hubert: Oczywiście, ale bardziej z perspektywy programisty. Bo to nie jest tak, że po seniorze jest tylko emerytura, zawsze można wejść na większy poziom abstrakcji i kreować rozwiązania na wyższym poziomie. Nigdy nie można powiedzieć, że wie się już wszystko, więc jeszcze długa droga przede mną.

Tomasz: Nie mam obranej żadnej specyficznej linii rozwoju. Na pewno chcę pozostać na bieżąco z technicznymi rozwiązaniami w dziedzinie testowania i automatyzacji testów, ale chcę też pełnić rolę “konsultanta”, który będzie w stanie polepszyć jakość całego procesu dostarczania oprogramowania, jak również jakość pracy wszystkich osób zaangażowanych. Zobaczymy co przyniesie przyszłość. 

Miłosz: W tym momencie skupiam się na rozwoju w automatyzacji oraz tematyce CI/CD. A co dalej? Zobaczymy. 

baner

Zdjęcie główne pochodzi z unsplash.com.

Joanna Pasterczyk
Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
Luka w technologii Bluetooth. Jak zabezpieczyć się przed utratą danych?