Cześć Adam. Czy mógłbyś się przedstawić i opowiedzieć, czym na co dzień się zajmujesz?
Cześć Tobie, cześć wszystkim. Ja od 10 lat zajmuję się testami, z czego dziewięć, około dziewięciu zarządzam tymi testami i w różnych środowiskach, w różnych branżach ubezpieczeniach, bankowości, tzw. manufacturingu i w kilku różnych. Zarządzałem różnymi zespołami, czyli takimi powiedzmy od 5 w projekcie do 15 w projekcie i dużym zespołem prawie 80 osób już w większej konsultingowej firmie. Mieliśmy tam około 15 projektów, wielu klientów i tam robiłem trochę inne rzeczy tam trochę testowałem, dużą uwagę przykładałem do rekrutacji i poza tym wykładałem na uczelni przez kilka lat na takim kierunku, który stworzył mój były szef zresztą. tam mieliśmy podyplomówkę, na której wykładaliśmy też testy oprogramowania, a następnie po kilku latach zdecydowaliśmy, że chcemy na trochę inny poziom wyższy wejść i z trzema kolegami założyliśmy firmę, która się nazywa 4_testers, czyli kurs, który się nazywa 4_testers. Teraz już sami tych testerów szkolimy. I właśnie się zaczęła pierwsza edycja.
OK, super, czyli cały czas można się zapisywać?
Teraz już nie, ale prawdopodobnie niedługo odpalimy możliwość zapisu na kolejną edycję, która prawdopodobnie ruszy w nowym roku.
OK, super. Oczywiście zachęcamy do zapisów. Wspomniałeś, że zajmujesz się testowaniem już od ponad 10 lat, więc czy uważasz, że od tego czasu dużo się zmieniło w Twoim zawodzie? Czy ten próg wejścia w ogóle do branży jest teraz niższy czy wyższy?
Zmieniło się bardzo dużo. Zmieniło się głównie to, że jak ja zaczynałem, ten zawód testera w ogóle nie był znany i można było pracę dostać raczej po znajomości. Ja też dostałem pracę po znajomości, po znajomości, trochę dużo powiedziane, bardziej robiłem inne rzeczy i po prostu jeden z kolegów z którym studiowałem, już pracował wtedy w branży, niekoniecznie testerskiej, ale generalnie w IT. Zobaczył, że robię fajne rzeczy i zapytał mnie czy nie chciałbym tego robić. Zgodziłem się, tylko, że ja się na IT nie znam, a nie musisz – nauczymy cię. No i mnie nauczyli. To było ok. Wtedy w ogóle się zetknąłem pierwszy raz z tym zawodem i po co to jest. I z osobami, które to robią i większość z nich była tam też trochę z przypadku, bardziej po znajomości. To nie był znany zawód. A w tym momencie to mamy sytuację, gdzie bardzo dużo osób chciałoby do tego zawodu po prostu wejść. Są kuszeni super zarobkami i takimi warunkami pracy, które też są w IT bardzo, bardzo korzystne w porównaniu do innych branży. I to jest fajne, to jest fajne. Natomiast jednocześnie moim zdaniem ta podaż ludzi rośnie szybciej niż popyt, przynajmniej teraz i rekruterzy mogą wybierać w tych osobach, które są świetne. No i tu się zaczynają schody, bo jak ja zaczynałem, to praktycznie nie potrafiłem żadnych technicznych rzeczy. Miałem nazwijmy tam jakieś umiejętności miękkie, które sprawiły, że dostałem to zaproszenie do tego zawodu. Natomiast na tym etapie, jeżeli możemy przebierać, to wybieramy te osoby, które są najlepsze, które najlepiej są przygotowane do startu. Mają tę wiedzę trochę związaną z testami, ale też mają trochę technicznej wiedzy z różnych obszarów, a jednocześnie spełniają pewne warunki, jeśli chodzi o nazwijmy to charakter czy podejście do pracy, czy generalnie taki mindset po prostu. Tak więc te warunki się zmieniły drastycznie, no i teraz już tak łatwo nie jest, teraz już tak łatwo nie jest. Teraz trzeba naprawdę zrobić kawał roboty, żeby mieć siłę przebicia w tych rekrutacjach, no bo na jedno stanowisko mamy czasem 50 ofert pracy, jeżeli chodzi o juniorów, a czasem 150-200 w zależności od tego, jak wypromowana jest ta konkretna oferta. Tak to wygląda.
Okej, okej. No właśnie, czyli mówiąc trochę o tym, o tym mindsecie, o tych umiejętnościach technicznych, myślę, że możemy przejść do tego kolejnego pytania, bo podczas webinaru co decyduje o zatrudnieniu początkującego testera, wspominałeś właśnie o tym, że firmy szukają osób z takimi umiejętnościami jak podstawy testów, wszechstronność, język angielski, elastyczność. Więc czy mógłbyś powiedzieć coś więcej o tych predyspozycjach i umiejętnościach twardych i miękkich, które właśnie trzeba mieć do pracy jako tester?
Pewnie, jeśli chodzi o miękkie rzeczy, to ja nazywam to po prostu komunikacją, bo musimy zdawać sobie sprawę z tego, że w pracy testera mamy pewien czas, który poświęcamy na techniczne rzeczy, na testowanie, zgłaszanie defektów, czytanie scenariuszy czy pisanie scenariuszy, czytanie wymagań itd. Ale mamy też cały szereg cały, jakieś tam konkretne obszary czasu, które poświęcamy na po prostu komunikację. Musimy pogadać z analitykiem, wiedzieć, jak to ma działać, ewentualnie z Product Ownerem, pogadać z programistą, wyjaśnić, coś, mamy różne spotkania. I pojawiają się też pewne konflikty. I taka osoba, która jest testerem, musi umieć skomunikować często kilka tych osób i dojść do tego, jak coś ma działać. Czy to realizuje realną potrzebę naszego klienta, jak to może być zrobione, jak jest robione teraz, może można to jakoś zmienić, może możemy to usprawnić itd. Więc cała ta otoczka jest bardzo istotna, jeśli chodzi o pracę testera, więc ta komunikacja jest niezbędna. Kolejną rzeczą jest to, że taka osoba powinna lubić rozwiązywać problemy, bo te problemy się realnie pojawiają. No i mamy testerów, którzy mówią to po prostu nie działa i już, ale testerów, którzy mówią to nie działa i przyczyną jest to, to i to, bo poświęciłem pół godziny i poszukałem i poszperałem czy w logach, czy w dokumentacji no i znalazłem odpowiedzi po prostu pewne. I teraz widzę, że nie działa to i to, i dzięki temu programista nie musi tego czasu już poświęcić np. albo mówisz, że coś działa trochę inaczej niż załóżmy dokument z wymaganiami. No ale ta osoba też jednocześnie sama pójdzie do Product Ownera, wyjaśni, jak to ma działać, pogada z analitykiem i później po takiej dyskusji, składając rzeczy angażujące programistę dojdzie do tego, jak to powinno działać we współpracy z innymi osobami.
Kolejną rzeczą jest taka, ja to nazywam taką ciekawością świata, czyli rozwiązuje problemy to raz, ale też zadaje bardzo dużo pytań. Dlaczego tak robimy? Dlaczego ten produkt ma w ten sposób działać, a nie w inny? Kto będzie z tego korzystał? Jak będzie z tego korzystał? Czy możemy zobaczyć jak z tego korzysta? Tutaj możemy zadawać pytania o wszystko, o produkt, o projekt, o procesy jakie robimy, o to czy możemy coś zrobić lepiej, inaczej. To jest taka wrodzona ciekawość po prostu. I uważam, że w pracy testera jest superważna. Widzę, że osoby, które zadają bardzo dużo pytań po prostu rozwijają się szybciej, lepiej sobie radzą. Więc to są takie rzeczy miękkie, które uważam, że są istotne. I też dodałbym tutaj jeszcze taką trochę pro aktywność, trochę wytrwałość. Czyli, że jeżeli są problemy to ok – Ja mogę wziąć coś na siebie i to rozwiązać, coś znaleźć, coś wyjaśnić. To się bardzo ceni. To się bardzo ceni w tej branży. I taka wytrwałość, bo rozwiązywanie tych problemów czy branie na siebie tych różnych potencjalnych rzeczy do zrobienia, niekoniecznie związanych z testami, jest kosztowne, jeśli chodzi o energię, jeśli chodzi o czas. I niewiele osób to robi. Niewiele osób to robi, a jednak osoby, które to robią, które się tam zgłaszają, że coś znajdę, rozwiążą, zaproponują. Czy to, jeśli chodzi o jakieś techniczne rzeczy, czy o procesy – są po prostu wartościowe. I z takimi osobami my chcemy pracować. Ja chcę z takimi osobami pracować. Managerowie chcą pracować i klient też chce z takimi osobami pracować. Więc to jest superważne. A jeśli chodzi o techniczne rzeczy, no to tu mamy taki stały zestaw: podstawy testów, czyli żeby ta osoba w ogóle rozumiała, jak te testy się robi. Jakie są typy/poziomy testów, jak zobaczyć defekty, jakie scenariusze tego typu rzeczy i ogólnie metody testowania, tak? Druga rzecz to jest praca z bazami danych, czyli sam SQL, który jest najczęściej używany. Podstawy programowania nie tylko po to, żeby w przyszłości pisać sobie automaty, ale też po to, żeby rozumieć, jak po prostu funkcjonuje te kodowanie, żeby łatwiej się rozmawiało z programistami. I żeby mieć trochę wiedzy o tej samej branży IT, o to jak to po prostu działa. Więc te podstawy programowania, moim zdaniem już na tym etapie fajnie, żeby każdy umiał, kto wchodzi do branży. Do tego dochodzą jakieś testy API, testy aplikacji mobilnych, mamy tutaj zarządzanie testami, czy jakieś technologie internetowe. Jest trochę tych rzeczy, natomiast myślę, że w kilka miesięcy, w pół roku przy takim intensywnym kursie jest to do zrobienia, żeby się tych podstaw realnie nauczyć.
OK. No i właśnie tutaj trochę odpowiedziałeś na to moje kolejne pytanie, bo zastanawiałam się, że wiele osób zainteresowanych wejściem do branży, rozpoczęciem tej przygody z testowaniem zastanawia się właśnie, czy tester oprogramowania musi umieć programować. Z tego co mówisz, to dobrze, żeby znał te podstawy. Pytanie czy jest jakiś może konkretny język programowania, który akurat uważasz, że od niego właśnie warto zacząć?
Ja bardzo techniczny nie jestem, więc jestem dość powściągliwy w odpowiedzi na to pytanie. Natomiast bazując na doświadczeniach, które mam i też doświadczeniach z uczelni, wydaje mi się, że jednym z lepszych języków jest po prostu Python, bo on jest prosty, jest możliwe dość mocno wszechstronny i po prostu fajnie się w nim zaczyna. I wtedy łatwiej zrozumieć też, jak te testy mają funkcjonować. Potem zmiana języka jest dość może nie jest prosta, ale jest już łatwiejsza. Gdy rozumiem cały mechanizm, jak to wszystko funkcjonuje, to muszę się po prostu nauczyć tego, jak inny język działa. Natomiast to nie jest tak, że ten język jest super, a reszta jest zła. Jest kilka innych języków, w których też w tym momencie dużo osób zaczyna jak Java czy JavaScript czy nawet C#. I to trochę nie ma znaczenia. Jedyna różnica to powiedziałbym próg wejścia, najpóźniej możliwość kontynuowania tej nauki pod kątem automatyzacji. Bo jeśli mówimy o testerach, to tutaj generalnie uczymy się tego programowania między innymi po to, żeby później z tego korzystać. Przy automatyzacji samych testów.
Ok. No i będąc przy tej nauce: Co doradziłbyś osobom, które chciałyby rozpocząć swoją karierę w obszarze testów? Od czego powinny zacząć? I przede wszystkim też skąd czerpać wiedzę? Bo zakładam, że tych informacji w Internecie przede wszystkim jest mnóstwo, ale które są takie najbardziej wiarygodne?
Tak, tak, cały Internet w zasadzie, duża część Internetu, teraz mówi o testowaniu, jesteśmy wszyscy kuszeni w ogóle wejściem do branży IT, a jest też taki mit, że najłatwiej wejść do branży przez testowanie, bo nie trzeba nic umieć, tylko wchodzę i testuję. To może kiedyś tak było, teraz już tak nie jest.
Ja generalnie przestrzegam przed łatwymi rozwiązaniami w stylu: przeczytać dwie książki i mogę wejść albo zrobić w 2-3-4 tygodniowy kurs i próbować do tej branży wejść, bo takich ludzi jest już bardzo dużo i wydaje mi się, że nie znajdują tej pracy tak szybko jak by chcieli, w ten sposób. To co ja polecam to podjąć decyzję i się jej trzymać i podjąć ją na zasadzie ok, poświęcam teraz pół roku albo rok. Realnie uczę się tych wszystkich rzeczy. Zaczynam sobie od testów i później kontynuuję z różnymi technicznymi rzeczami. Buduje sobie CV. Najlepiej, żebym zrobił jakiś projekt w międzyczasie. Na ile jest to możliwe. No i wtedy z tym bagażem łatwiej jest szukać tej pracy. Ale ważne jest to, żeby robić to z ludźmi, którzy tę drogę już przeszli i którzy są zaawansowani w tym nauczaniu, bo teraz też sporo firm powstaje, czy na uczelniach powstają kursy testowania. Natomiast ja polecam pracę z osobami, które robią to od lat, które przećwiczyły już ten materiał wielokrotnie i które same testują po prostu. I w tej branży są od wielu lat. Osoby, które można posłuchać na konferencjach, osoby, które można zobaczyć na YouTube albo po prostu na webinarach. To jest ważne, żeby uczyć się od kogoś, kto realnie, po pierwsze ma potwierdzoną wiedzę, a po drugie ma te umiejętności nauczania, to też jest superważne.
No i tutaj można iść dwie strony. W sensie można sobie zbudować taki kurs, nazwijmy to pełny, własnymi siłami i próbować kursów na Udemy czy w różny i inny sposób. A można pójść na studia podyplomowe, można przyjść do nas na kurs, można pójść na jakiś inny kurs i dłuższy testowania, które zawiera w sobie te wszystkie elementy, o których mówiliśmy. To jest superważne. A najlepiej, żeby na końcu jeszcze te osoby, które prowadzą ten kurs, wytłumaczyły i pomogły z budowaniem CV na Linkedina. No bo też jest często tak, że ktoś ma tę wiedzę, ktoś ma te umiejętności, ten nazwijmy to, charakter do tego, żeby tym testerem być, ale nie jest w stanie się przebić, bo nie potrafi zbudować tego CV, nie robimy tego na co dzień, w sensie zazwyczaj te CV się buduje raz na kilka lat. Natomiast jest niesłychanie ważne, żeby później umieć się też sprzedać. Także przestrzegam przed krótkimi, łatwymi rozwiązaniami. Tutaj trzeba podjąć decyzję już poważną, wydać trochę pieniędzy, najlepiej moim zdaniem i zrobić to z ludźmi, którzy się na tym znają i którzy tę wiedzę nam ułożą w odpowiedni sposób i też nam przekażą w odpowiedni sposób, bo to jest istotne. To nam po prostu ułatwi tę drogę wejścia.
OK, jasne. A czy mógłbyś powiedzieć trochę więcej o tym, jak to wygląda u Was w 4_testers?
U nas w 4_testers wygląda to tak, że może powiem w ogóle kto tworzy 4_testers. No bo nas jest czterech, jest ja, jest Darek Drezno, jest Adam Pucko, jest Adrian Gonciarz i my we czwórkę. Każdy z nas czy jest test managerem czy był test managerem. Adrian robi automatyzację zaawansowaną. Darek miał nadal ma w zasadzie firmę, która zajmuje się też testami i testami dostępności. My wszyscy się znamy od lat i współpracowaliśmy ze sobą i zdecydowaliśmy, że po kilku latach na tej uczelni chcemy zrobić coś razem. Ale pracujemy też z osobami, które również znamy i które również częściowo wykładały na uczelni. Jest to 5 kolejnych wykładowców, do których mamy duże zaufanie i którzy współtworzą z nami ten kurs. Tak więc jest 9 osób i każdy z nas ma inny kawałek kursu. Jedna osoba uczy podstaw programowania, kolejne automatyzacji API, kolejne automatyzacji UI, a ktoś inny tworzy jakby ten kurs na początku, jeśli chodzi o podstawy programowania, ja się zajmuję miękkimi umiejętnościami zarządzaniem, szukaniem pracy. Mamy to podzielone na parę etapów. Kurs trwa 20 tygodni i jest wieczorowy z tego względu, że mamy takie doświadczenia po uczelni, że jednak spotkanie się co dwa tygodnie na dwa pełne dni to jest za duża dawka materiału, to raz, a dwa nie mamy tego takiego stałego kontaktu.
I po trzecie – lubimy odpoczywać wszyscy w weekendy, więc to też jest jeden z argumentów. Więc zdecydowaliśmy, że będziemy robić dwa razy w tygodniu spotkania po 2,5 godziny, więc dajemy ten materiał w mniejszych dawkach. Natomiast jesteśmy też w stanie szybciej weryfikować to, co się dzieje, dawać szybciej feedback, a w piątki mamy jeszcze do tego konsultacje dodatkowe dla chętnych i tam rozwiązujemy różne wątpliwości. Odpowiadamy na pytania, ale też na te pytania odpowiadamy w trakcie na platformie, którą mamy. Więc jesteśmy w stałym kontakcie z tymi ludźmi. Nie jest tak, że raz na dwa tygodnie się widzimy, tylko tutaj, na bieżąco mamy ten kontakt prawie codziennie i 20 tygodni kursu i po 20 tygodniach osoba jest przygotowana, przygotowana merytorycznie, technicznie i również, jeśli chodzi o zbudowane CV, LinkedIna, więc jest po prostu gotowa, żeby wejść na rynek i gotowa, żeby szukać pracy na tym rynku.
Brzmi super.
Jest super 😊
Przechodząc trochę głębiej do pracy testera chciałabym się Ciebie zapytać czym różni się praca testera manualnego od testera automatycznego lub automatyzującego? Która nazwa jest poprawna?
To ja szybko wyjaśnię. Poprawnie mówimy tester automatyzujący, bo automatyczny sugerowałby, że jesteśmy robotami i coś się dzieje. Robi to człowiek, więc jest to tester automatyzujący, czyli automatyzuje swoją pracę. Natomiast przez swoją pracę rozumiem część swojej pracy. Są oczywiście różne konfiguracje w konkretnych firmach. Czasem mamy osoby, które robią i testy manualne i testy automatyczne. No i to wygląda po prostu tak, że ta osoba jest po prostu testerem, zbiera informacje, pisze scenariusze, sama testuje manualnie, a później sobie automatyzuje część pracy. A mamy też takie konfiguracje, gdzie np. mamy zespół testerów manualnych czy w ogóle mówienie testerów manualnych jest błędem. Po prostu testerów. Mamy po prostu testerów i mamy też zespół testerów, którzy automatyzują. I wtedy oni dostają konkretne scenariusze zautomatyzowania i siedzą i po prostu piszą kod. Tak utrzymują ta automatyzacje i już.
Natomiast i jedni, i drudzy to są testerzy automatyzujący. Nie ważne czy ja tylko automatyzuje, czy zbieram wymagania i piszę scenariusze, rozmawiam ze wszystkimi dookoła i automatyzuje, to mówimy tu o testerach automatyzujących, więc jedyna różnica polega na tym, że tester, który nie automatyzuje wykonuje scenariusze manualnie, czyli po prostu sobie je czyta i wykonuje manualnie te wszystkie operacje, a drugi pisze sobie kod, który wykonuje te akcje samoczynnie. Tak to wygląda.
Ok, ok. A czy powtarzane przez wielu słowa, że aby rozwijać się w zawodzie testera trzeba prędzej czy później przejść na automatyzację – czy to jest prawda, czy to mit?
Ja się z tym nie zgadzam. Znam osoby, które siedzą już w tym zawodzie kilka, kilkanaście lat i nigdy nie automatyzowały. I są super wartościowymi pracownikami. To są właśnie te osoby, które po pierwsze wezmą na siebie kilka dodatkowych zadań. Umówmy się testowanie nie jest tylko robieniem testów. Czasem trzeba coś zrobić ze środowiskiem, wyjaśnić coś, pogadać, zmienić proces, pogadać z klientem, zrobić prezentację. Jest dużo rzeczy, które w tym testowaniu się odbywa, są taką otoczką tego testowania. Ale trzeba to robić. No i tacy senior testerzy są też super potrzebni, bo oni mają wiedzę jak zaprojektować te scenariusze, mają wiedzę jak kogoś wyszkolić, mają wiedzę jak stworzyć proces, jak rozmawiać z klientem i mają super wiedzę o samym prowadzeniu tych testów. Więc taka osoba jest naprawdę niezbędna, szczególnie w dużych projektach. Jeśli chodzi o automatyzację to też mamy projekty gdzie ona jest niezbędna i po prostu się zwraca. Jeśli chodzi o kwestie finansowe, jakościowe i też czasowe. Mamy czasem projekty, w których nie opłaca się jej robić albo opłaca się ją robić na bardzo podstawowym poziomie i już. Więc ja jestem osobiście zdania, że to nie jest naturalna droga. Żeby robić automatyzację. Też trzeba mieć pewien mindset, żeby to robić i lubić po prostu siedzieć w tym kodzie, a można się rozwijać na wiele różnych innych sposobów. W samym testowaniu można się rozwijać jeśli chodzi o zarządzanie testami. Jeśli chodzi o projektowanie testów, możemy iść w ogóle w stronę testów bezpieczeństwa, możemy iść w ogóle w inne sfery IT, może zostać Scrum Masterem, możemy iść w analizę, możemy iść po prostu w programowanie. Tych dróg jest bardzo wiele i automatyzacja jest jedną z nich. Jest, jest bardzo popularna teraz, no bo mówi się o super fajnych zarobkach. Natomiast ja uważam, że nie jest to najlepsza droga. Jest to droga dobra dla tych, którzy rzeczywiście czują siedzenie w kodzie i którzy to lubią. I tutaj też przestrzegam, bo dużo osób zaczyna drogę z automatyzacją od tego, że wchodzę do projektu, uczę się Selenium, robię copy-paste. Jak się pojawia jakikolwiek poważniejszy problem no to już potrzebuję seniora. Ja osobiście uważam, że lepiej jest zacząć od programowania, następnie uczyć się dalej, dalej i dalej, poświęcić tego czasu więcej i dopiero wchodzić w tę automatyzację, bo wtedy też wchodzimy z pewną podstawą, która sprawi, że łatwiej nam będzie się później w tym rozwijać.
Na jednym z Waszych webinarów właśnie, które zorganizowaliście w 4_testers, podzieliłeś się taką mind-mapą z kierunkami rozwoju i pojawiły się tam takie stanowiska jak właśnie Scrum Master, Product Owner, Developer, DevOps. I chciałam się podpytać co sądzisz o takim podejściu? Czy w takim razie zawód testera jest pewnego rodzaju etapem w karierze, czy raczej jest to kwestia indywidualna i testerem można być przez całe życie? Tak jak wspomniałeś, że masz tego znajomego, który jest tym testerem manualnym i nie ma zamiaru jakby ruszać tych testów automatycznych. Więc pytanie jakie jest Twoje podejście?
Myślę, że to zależy od człowieka. Znam testerów, którzy przebranżowili się na analityków, na programistów. Znam programistów, którzy przebranżowili się na testerów. automatyzujących. Tych ścieżek jest dużo. Ja generalnie tak osobiście polecam po prostu zmieniać sobie to co się robi. To może być zmiana projektu w ramach testowania, żeby się czegoś nauczyć. To może być zmiana firmy, ale to może być też zmiana roli. Mogę przez trochę być testerem, mogę spróbować sił w byciu Scrum Masterem, a potem wrócić na przykład i spróbować zarządzać. Moim zdaniem to jest super fajne. Jest też taki tzw. T-shaped model, który mówi o tym, że każdy człowiek ma ileś tam różnych kompetencji. Mogę być trochę testerem, a tu mogę być Product Ownerem, tu mogę mieć doświadczenie w programowaniu i robić trochę automatyzacji. Takie osoby, które są w stanie też się uczyć tych innych rzeczy są potrzebne, bo zazwyczaj jak wchodzimy do projektu to ok, mamy jakiś swój zestaw umiejętności, z którym wchodzę, ale często jest też tak, że muszę go rozwinąć. Po pierwsze te narzędzia, których mi brakuje, ale czasem w projektach jest potrzebna taka rola trochę z boku na 1/5, 1/4 etatu i wtedy mogę się również zaangażować i to robić. To jest też rzecz, którą również polecam, jak jestem w konkretnej firmie i są możliwości zrobienia czegoś ekstra.
Ja polecam to robić. Po pierwsze trochę nas rozwinie pod kątem życia firmy, czyli zrobię test, ale przy okazji też wezmę udział w jakimś webinarze albo w jakimś spotkaniu dla klienta, albo czymś po prostu fajnym i zobaczę trochę szerszą perspektywę niż same testy albo mój projekt. Ale też dzięki temu zbuduję trochę nowych relacji, które może prędzej czy później gdzieś tam w tej karierze pomogą. Więc to jest też droga, którą ja proponuję.
Omówiliśmy sobie trochę już te etapy związane z nauką, etapy związane z rozwojem kariery. Przenieśmy się teraz do tej rozmowy rekrutacyjnej. No i jakich przykładowych pytań w trakcie rozmowy o pracę może spodziewać się tester?
Tutaj tak szczerze wolałbym nie odpowiadać, ponieważ nie chciałbym tworzyć takich, nazwijmy to pytań, które zawsze padają. Natomiast zdecydowanie mogą to być pytania nazwijmy to wysokopoziomowe i niskopoziomowe. Czyli jak byś przetestował bankomat, biletomat lub jakieś urządzenie? Może to być pytanie o jakiś konkretny fragment, jakiś arkusz albo jak zrobić konkretne testy na konkretnym przykładzie. To co ja generalnie bardzo lubię robić w trakcie rekrutacji to dawać realne problemy do rozwiązania, czyli np. daje bardzo proste wymagania, jedna strona tekstu i mówię OK, zaprojektuj mi testy na to. Ja generalnie proponuję taki model, że daje kilka zadań lub pytań lub jedno i drugie. Do zapisania sobie, masz pół godziny – 40 minut. Przemyśl to sobie, zaproponuj rozwiązania i potem o tym rozmawiamy. I to jest moim zdaniem fajne z tego powodu, że wtedy widzę, jak człowiek myśli. Wtedy też ten człowiek na spokojnie zadaje różne pytania. I to też jest super wartościowe, bo widzę o co pyta, co jest dla mnie ważne. Widzę, w jaki sposób próbuje ten problem rozwiązać. No i na końcu rozmawiamy o samym problemie, o tym, jak rozwiązanie powinno wyglądać. To jest droga, którą ja proponuję.
Na temat konkretnych pytań wolałbym nie wypowiadać, bo po pierwsze każdy ma trochę inny styl. Każdy z tych managerów czy test managerów, czy po prostu osób rekrutujących. No i tu mogą być pytania wszelakie.
Gdzie siebie widzisz za 5 lat? Nie żartuję oczywiście. To jest takie pytanie, którego wiadomo, że nie zadajemy, bo ono jest zabawne. Natomiast często jest zadawane.
Ja je lubię tak szczerze.
Tak? To może porozmawiajmy na ten temat?
Może nie za 5 lat, ale np.za rok, za trzy.W takiej perspektywie bardziejjak planujesz swój rozwój? Tak?Co byś chciał, chciała i co lubisz, czego nie lubisz?Takie pytania lubię. Pokazują perspektywę człowieka.Ja trochę z różnych etapów też patrzę na te rekrutacje.Częściowo prowadziłem je indywidualnie, kiedy byłem tym pierwszym i ostatnimpunktem kontaktu, a też miałem w ostatniej pracyprzyjemność, że był zespół senior testerów i managerów, którzy rekrutowali,a ja prowadziłem tylko już tą ostatnią rozmowę, gdzie zależało mi bardziej napoznaniu człowieka tak personalnie i właśnie sprawdzeniu czyjeśli chodzi o charakterto pasuje też do naszego zespołu i do tej firmy, bo każda firma ma trochęinną kulturę i to też jest ważne, żeby takiego człowieka dopasować.
Czy jest jakaś rada, której udzieliłbyś rekruterom lub hiring managerom, którzy właśnie obecnie rekrutują testerów? Czy jest może coś, na co szczególnie powinni zwrócić uwagę?
To co moim zdaniem jest ważne – ja pracowałem też z różnymi rekruterami i firmami rekrutacyjnymi. To komunikacja między hiring managerem a samym rekruterem i to dwie strony. Żeby to działało. Z jednej strony, żeby trochę przeszkolić tego rekrutera na temat naszej firmy, na temat naszych projektów i technologii, co my po prostu robimy, żeby taki rekruter był w stanie też opowiedzieć tej nowej osobie, co tu realnie się dzieje. No bo to jest po prostu fajne, na zasadzie, że jeżeli już na tym etapie to się rzadko zdarza, bo najczęściej jest tak, że rozmawiam z rekruterem i szczegóły o projekcie, to na kolejnym etapie, a moim zdaniem super wartością jest to, że już rekruter potrafi opowiedzieć coś o projekcie albo o projektach, jeżeli takie są, o technologiach i o samym zespole. Ile jest osób, co robią, jak się dzielą, gdzie są, ile robi automatyzację, w czym itd. Są fajne rzeczy po prostu. Więc ja polecam + dodatkowo to co ja zawsze lubiłem robić to takie krótkie szkolenie na zasadzie jak oglądać CV testera.
I tutaj już mówimy o tym, żeby ten rekruter rozumiał same testy, czyli żeby rozróżniał typy i poziomy testów, żeby wiedział co w tym CV jest wartościowe, co niekoniecznie, a o co np. warto dopytać? A z drugiej strony ta rozmowa z hiring managerem jest też niezbędna, żebyśmy rozumieli, kogo my tak naprawdę potrzebujemy. Bo czasem jest tak, że napiszemy sobie te wymagania, potem się okaże, że część z nich jest niepotrzebna, a część z nich nie jest niezbędna, tylko zbędna i ostatecznie odrzucamy część ludzi, których nie powinniśmy odrzucać. Więc ta komunikacja między tymi dwoma osobami albo i więcej moim zdaniem jest kluczowa. Ja zawsze lubiłem to robić i zawsze widziałem, że rekruterzy są zadowoleni z tego powodu. Dla nich też to była wartość, także czegoś się dowiedzieli nowego i żeby byli później w stanie lepiej wyłapywać różne słówka, czy na LinkedInie szukać po innych słowach kluczowych. To była wartość dla obu stron. Dla mnie zawsze istotne było to, że była ta komunikacja na bardzo wysokim poziomie między tymi osobami. I później, kiedy już rozmawialiśmy o kandydatach, to też to było ważne. I ważne, żeby było to, że razem definiowaliśmy np. jakie pytania już mogą paść na poziomie tej pierwszej rozmowy, tego screeningu, które nie są na tyle skomplikowane, żeby gdzieś tam skompromitować tę osobę czy rekrutera, a jednocześnie dają nam pewne odpowiedzi, o które później nie musimy pytać. I już nawet po samym screeningu, możemy sobie spojrzeć na nasz feedback po rozmowie i już widzimy, czy to ma sens, czy to nie ma sensu, żeby iść dalej. Kiedy mówimy tutaj o rekrutacjach powiedzmy 10-15 osób na miesiąc, to to robi bardzo duże znaczenie. I po prostu, jeżeli nawet szukamy jednej osoby na miesiąc albo w ogóle na 3 miesiące i chcemy kogoś wartościowego znaleźć, to żeby nie marnować czasu obu stron, jest to myślę wartościowa technika.
Myślę, że to są bardzo fajne porady, także dzięki. Chciałabym trochę wrócić właśnie do tego, jak Ty pracowałeś przez te ostatnie kilka lat. I właśnie wspominałeś też, że w jednej z firm, w której pracowałeś, prowadziłeś zespół liczący ponad 70 osób. Więc zastanawiam się, czy zdarzały się jakieś sytuacje, gdy zespół testerów nie do końca dogadywał się z pozostałymi pracownikami? Jak tak, to jak sobie wtedy radziliście?
To może ja zacznę tak, że miałem tę przyjemność, że pracowałem w firmie, która była na bardzo wysokim poziomie, jeśli chodzi i o technologie, i o komunikację, i generalnie poziom tej komunikacji. Dużą wagę przykładaliśmy do tego, żeby przy rekrutacji zwracać na to uwagę. Po prostu osoby, które nie pasują do tej kultury organizacyjnej, która była na wysokim poziomie, po prostu nie zatrudniać, nawet jak są dobre technicznie. I to było fajne. Więc takie przypadki, o których mówisz, zdarzały się wyjątkowo rzadko. One się oczywiście zdarzały, no bo jeżeli mamy tak duży zespół i mamy załóżmy 15 projektów lub 20 projektów, to jedni klienci są łatwiejsi, inni są trudniejsi. Więc już na tym poziomie może się pojawiać pewna presja. No a też często zdarzają się też sytuacje, kiedy nie dogaduje się z programistą, a każdy chce dobrze jak chce zrobić dobrze swoją robotę i on także. Więc tutaj albo ja, albo jeden z menadżerów lub test manager angażowały się wtedy w taką sytuację i rozmawiali, bo to jest wszystko na poziomie rozmowy. Dlaczego to się dzieje ze strony testera, co się dzieje, co się dzieje po drugiej stronie, no i wyjaśniamy, o co tutaj chodzi. Ale nigdy nie zdarzyła się taka sytuacja, żeby przynajmniej u mnie, w mojej karierze, żeby była jakaś naprawdę poważna eskalacja i żeby z tego powodu były jakieś poważne konsekwencje. Zazwyczaj udało się zawsze to rozwiązywać. I tak myślę, że jednak ludzie w IT w dużej mierze po prostu rozumieją, że czasem te konflikty są potrzebne, bo to sprawia, że jesteśmy bardziej produktywni. Czasem trzeba powiedzieć hej, coś mi się nie podoba albo nie podoba mi się jak coś robimy albo jak konkretnie coś robisz. Oczywiście forma tutaj ma duże znaczenie. Natomiast to jest czasem potrzebne i te konflikty się pojawiają. I to jest naturalna kolej rzeczy. Wszyscy chcemy pracować lepiej, żeby było nam po prostu przyjemniej w tej pracy. To jest nieodłączna część procesu, a od tego, żeby te kwestie rozwiązywać, to już są menadżerowie albo same osoby. A czasem wystarczy po prostu pogadać z tą osobą, zaproponować jakieś potencjalne rozwiązania i najlepiej, żeby ta konkretna osoba, ten własny problem komunikacyjny rozwiązała, zamiast angażować innych. Ale jedna i druga opcja uważam, że jest jak najbardziej ok. Po to też jesteśmy jako managerowie, żeby tutaj pomagać i wspierać. Tak to wyglądało w mojej karierze.
OK, jasne. No i na samo zakończenie chciałabym się Ciebie zapytać, jak wyobrażasz sobie przyszłość swojego zawodu? Czy pracy testera mogą zastąpić maszyny, sztuczna inteligencja?
Ja jestem bardzo daleki od myślenia co będzie dalej. Jak zaczynałem testować no to często słyszałem, że za 10 lat to już wszyscy będziemy tylko automatyzować i nie będzie testerów, którzy wykonują testy manualnie. Życie pokazuje, że tak nie jest. Trend idzie dalej. Coraz więcej automatyzujemy i coraz lepiej automatyzujemy. Natomiast wciąż w większości firm, przynajmniej w większości firm, dla których ja pracowałem lub z klientami, z którymi pracowałem, a myślę, że idzie to w dziesiątki firm. Jest taki trend, że ci testerzy, którzy wykonują testy manualnie, zazwyczaj są. W dużej mierze może. 5% projektów, które widziałem były takie, że byli tylko testerzy, którzy automatyzują, a w rzeczywistości okazywało się, że często te osoby też robią testy manualnie, bo nie ma czasu na automatyzację. Więc jestem daleki od wróżenia, tym bardziej, że obecny świat tak szybko się zmienia, że tutaj ciężko powiedzieć co się wydarzy. Myślę, że jest to możliwe, natomiast ja zawsze sobie wtedy mówię, że ktoś będzie musiał tę robotę i tak zaprogramować i zdecydować, jak one mają pracować, jak mają, jak mają tworzyć swoje algorytmy. Więc i tak ludzi będą potrzebni.
OK, czyli taki przekaz testerzy możecie spać spokojnie, tak?
Ja bym powiedział: testerzy rozwijajcie się. W różnych dziedzinach i w różne strony, ale rozwijajcie się. Bo widziałem też, że nie samych testerów, ale w ogóle ludzi z IT, którzy siedzą w jednej firmie po 10-15 lat i to często w firmach, które nie są bardzo do przodu, jeśli chodzi o technologię i po takich 10 latach nagle trzeba znaleźć pracę i się okazuje, że trochę moje umiejętności już nie pasują do rynku. I fajnie, że przez 10 lat zarabiałem dobre pieniądze i było mi wygodnie. Natomiast teraz muszę zakasać rękawy i się bardzo szybko nauczyć, żeby na te rynek z powrotem wejść i niekoniecznie za takie same dobre pieniądze. Więc powiedziałbym rozwijajcie się, w różnych aspektach i wtedy będzie dobrze.
Życzymy powodzenia w rozwoju. Bardzo dziękuję ci Adam za tą rozmowę.
Bardzo dziękuję również.
Super było pogadać i do zobaczenia!
Również dzięki wielkie i do zobaczenia.