– Najważniejsze jest znalezienie w tej pracy tego, co sprawia nam przyjemność. jeżeli tym czymś jest tylko wypłata, to nie wytrzymamy długo w QA – mówi Jakub Klech, menedżer QA. Rozmawiamy z nim m.in. o tym, jak AI wpłynie na pracę testerów oraz jak w tej chwili wygląda rynek IT.
Od gotowania do testowania i zarządzania — to w dużym skrócie Twoja ścieżka kariery Co spowodowało, iż zmieniłeś branżę i dlaczego akurat na IT i testing?
IT i gotowanie zawsze były moimi dwiema głównymi pasjami. Dom zawsze był pełen komputerów i akcesoriów, a lodówka pełna dziwnych ingrediencji. Gdy byłem młody i… mniej mądry, stwierdziłem, iż pójdę pod prąd i skupię się na gastronomii. IT zdawało się przytłaczać głębią i zawiłościami tematów, a kuchnia miała być prosta i przyjemna.
Zacząłem od zera — gotowanie zupy na stołówce dla ubogich, później była garmażerka, stołówka studencka, praca przy weselach, na końcu praca w wykwintnej restauracji hotelowej. W tle przewijała się druga pasja — a to napisałem program do wyliczania kaloryczności potraw, a to tworzyłem i utrzymywałem dokumentację HACCP (zarządzanie jakością w gastronomii).
Niestety, poznałem też tę gorszą stronę gastronomii. Szefowie kuchni są znakomitymi kucharzami, ale często okazuje się, iż słabymi przełożonymi. Dodatkowo zjadliwa konkurencja pomiędzy lokalami sprawia, iż najłatwiej jest oszczędzać kosztem pracowników. Podczas pracy w ostatnim lokalu wszystkie te problemy nawarstwiły się, co zaowocowało półrocznym L4 z powodu dość głębokiej depresji. Doszedłem do wniosku, iż coś trzeba zmienić — albo ja skończę z tą pracą, albo praca skończy ze mną. Znajomi, którzy pracowali w IT, polecili mi ścieżkę testera manualnego — ponoć to szybkie, łatwe i przyjemne wejście w świat IT…
Jak podszedłeś do zadania związanego z przebranżowieniem?
W sieci nie było zbyt wielu dostępnych skondensowanych informacji czy poradników, jak zostać testerem manualnym. Zbierałem strzępki wiadomości od znajomych programistów, z grup facebookowych, stron internetowych. Nie było dostępnych szkoleń typu „Zostań testerem”, które w pigułce by przekazywały większość potrzebnych informacji kandydatom na testerów Za to posiadałem bardzo mocną motywację do zmiany branży i pół roku czasu w L4.
Co do mojej nauki, zidentyfikowałem główne obszary — ISTQB, SQL, API, SDLC, Scrum, ze szczyptą Javy. Angielski miałem już w miarę opanowany, na poziomie zardzewiałego B2. Od syllabusa ISTQB się najpierw odbiłem — nie potrafiłem powiązać suchej teorii z obrazem, jak testowanie wygląda w praktyce. Rozwiązałem ten problem, wyruszając na kilka dni do Wrocławia, gdzie odbywał się kurs i egzamin ISTQB Foundation Level (w moim mieście, Lublinie, takie rzeczy odbywały się wtedy sporadycznie). Miałem szczęście, bo pytania na egzaminie podeszły bardzo dobrze i zdałem niemal w 100%. Mogłem zbudować swoje CV i rozpocząć poszukiwania pierwszej pracy.
Po jakim czasie dostałeś pierwszą pracę w IT?
Nie było łatwo. CV wysyłane na konkretne oferty na głównych portalach praktycznie nie przyniosły odzewu. Zostałem zaproszony na kilka rozmów, jeździłem choćby do Kielc czy Warszawy — wszystko po to, aby spisać sobie pytania, oswoić się z procesem rekrutacji i douczyć z tematów, które sprawiały mi trudności. Niestety miałem pecha i pracodawcy z Lublina nie byli zainteresowani współpracą. Za to dostałem oferty właśnie z Kielc i Warszawy, ale je odrzuciłem — w Lublinie miałem już rodzinę i byłby to skok na zbyt głęboką wodę.
Czas mijał, moje zwolnienie zaczęło dobiegać do końca. Nieco spanikowany zmieniłem strategię — zacząłem rozsyłać CV po wszystkich firmach IT w okolicy. I tak zostałem zaproszony na rozmowę do firmy konsultingowej. Przemaglowali mnie, ale dzielnie walczyłem. Po dwóch tygodniach dostałem upragnioną, pozytywną odpowiedź od działu rekrutacji — zaproszenie na staż. Pierwszy dzień pracy wypadł akurat kilka dni po zakończeniu zwolnienia lekarskiego. Takie zrządzenie losu.
Kolejnym pozytywnym zbiegiem okoliczności był projekt, na który miałem zostać zatrudniony. Klient mojej nowej firmy potrzebował osoby do zarządzania procesem testowym. Aktualna liderka testów miała przejść do innego projektu i zauważyła, iż większość osób proponowanych jej na to stanowisko jest „skażona” złymi praktykami i doświadczeniami z poprzednich projektów. Dlatego też uznała, iż łatwiej wyszkoli kogoś od „zera”. Pomogło tu nieco moje wcześniejsze (jeszcze przed gastronomią) doświadczenie w zarządzaniu projektami unijnymi (ale to zupełnie inna historia ).
Aby objąć stanowisko lidera testów, musiałem gwałtownie się doszkolić — SDLC, podstawy Prince, ITIL, szlifowanie angielskiego i jeszcze kilka kolejnych zagadnień. Dostałem też tymczasowy przydział testera manualnego dla systemu typu BPM — bawiłem się wybornie, zgłaszając błędy, pisząc instrukcję i współpracując z zespołem developerskim.
Dalej poszło jak po maśle. Klient docenił jakość mojej pracy, rozszerzając zamówienie na kolejnych liderów testów i testerów. Zostałem liderem zespołu. Mój obszar ciągle się rozszerzał, tak samo jak rosła firma, w której pracowałem. Po kilku latach pracy w różnych projektach i zarządzania zespołami zostałem managerem obszaru QA. Zarządzałem zespołami w Polsce i za granicą, szkoliłem nowych testerów, budowałem obszar testów w Indiach… Wysoka motywacja zabrała mnie na naprawdę szaloną przejażdżkę.
Podczas naszej pierwszej rozmowy wspomniałeś, iż wielu znajomych, zachęconych Twoim sukcesem, przychodziło po radę, jak zostać testerem. Udało im się?
Stojąc z boku, łatwo ulec wrażeniu, iż takie przebranżowienie było dla mnie rzeczą prozaiczną i nie wymagało zbyt wiele wysiłku. Dlatego też wiele osób prosiło o wskazówki dotyczące tego, jak można wejść do IT. Pamiętając własne problemy ze znalezieniem jasnych wskazówek, stworzyłem listę rzeczy, których należy się nauczyć, aby „od zera” podejść do rekrutacji na testera manualnego — lekko ponad 20 punktów. Mając doświadczenie w weryfikacji nowych testerów, proponowałem znajomym techniczne rozmowy rekrutacyjne „na sucho”, dawałem feedback. Wtedy okazywało się, iż jednak to jednak nie jest tak prosta sprawa. Z około 10 osób, do faktycznej rekrutacji podeszła jedna.
Powód jest prosty — wchodząc w obszar „z zewnątrz”, łatwo zostać przysypanym ilością materiałów i zagadnień do przyswojenia. Nie mając doświadczenia, trudno określić, co jest ważne, a co tylko wypełniaczem. w tej chwili odsyłam kolejnych chętnych do komercyjnych szkoleń typu „Zostań testerem”. Pozwalają w ustrukturyzowany sposób posiąść wymaganą wiedzę i choćby zobaczyć, jak wygląda jej zastosowanie w praktyce.
A możesz zdradzić, dlaczego — Twoim zdaniem — Tobie się udało?
Byłem bardzo zmotywowany. Wiedziałem, iż do gastronomii nie powrócę przez najbliższe lata. W międzyczasie urodził mi się syn i musiałem jakoś utrzymać rodzinę. Wsparcie rodziny również było bardzo ważne. No i muszę przyznać, iż miałem nieco szczęścia. Ale samo szczęście nie wystarczy — muszę tu wspomnieć o dziesiątkach nadgodzin w miesiącu, jednoczesnej pracy w kilku obszarach i doszkalaniu się. Czasami naprawdę nie było łatwo, musiałem wypracować odpowiednie podejście do work-life balance, aby nie wypalić się, albo nie stać się gościem we własnym domu.
Czy QA jest wciąż dobrym punktem wejścia w IT? Czy to przez cały czas stosunkowo łatwa gałąź IT, w porównaniu choćby z programowaniem?
Musimy tu rozróżnić pojęcia „dobra” a „łatwa”. Parafrazując powiedzenie o inflacji, łatwo to już było. W okresie gdy koronawirus szalał, korporacje zwiększały wydatki na rozwiązania IT, aby ułatwić przejście na pracę zdalną i dostosować się do nowej rzeczywistości. Wtedy było stosunkowo łatwo dostać się do projektu i zyskać doświadczenie, a później już było z górki. w tej chwili rynek zwolnił i wrócił na poprzednie tory. Coraz częściej wskazuje się, iż weszliśmy w recesję na rynku IT. Klienci osiągnęli już zakładane cele w obszarach IT i kierują fundusze na inne obszary swojej działalności. Do tego rozwój AI zapoczątkował trzęsienie na rynku pracowników IT.
Ludzie, podążając za starą mantrą „zostań testerem, tak najłatwiej wejść w IT”, zasypują działy rekrutacji swoimi CV. A klienci oczekują ludzi doświadczonych, najlepiej seniorów z bogatym wachlarzem umiejętności. Aby się przebić i dostać zaproszenie na rozmowę, trzeba się wykazać czymś szczególnym — posiadać szerszą wiedzę (API, SQL, automatyzacja testów), doświadczenie w projektach crowd-testingowych itd. Dochodzi do sytuacji, iż niekiedy trzeba dłużej się przygotowywać i trudniej się przebić przez proces rekrutacji na stanowisko testera manualnego, niż na staż na pozycji junior developera. Rozmawiając ze znajomymi rekruterami, część z nich informowała mnie, iż ostatnio w ogóle nie otrzymywali zapotrzebowania na początkujących testerów. Stąd w tej chwili pracę dostaną ci najbardziej zdeterminowani.
Natomiast wracając do pojęcia „QA to dobry punkt wejścia w IT” – tu się w pełni zgadzam. Dobry tester posiada dość wysokie umiejętności miękkie — musi raportować błędy developerom (tak, aby nie generować konfliktów w zespole), komunikować się z klientami i innymi stakeholderami. Powinien znać dobrze inne procesy niż tylko testowy — developerski, analizę, wdrożenia… Powoduje to, iż testerzy zyskują dość szeroką wiedzę o innych obszarach i stanowiskach w IT.
Do tego praca testera jest żmudna, często nudna, ale wymaga umiejętności analitycznego myślenia i dużej kreatywności w znajdywaniu sposobów na weryfikację oprogramowania. Dlatego testerami najczęściej są mocno zmotywowane jednostki, którym łatwo się rozwijać w kolejnych tajnikach obszaru QA, albo się przebranżowić na inne stanowiska.
Dużo się mówi o tym, jak zdobyć pierwszą pracę. A co zrobić, by później w niej „wytrzymać”?
Jak już wspomniałem, praca testera jest często żmudna i nudna. Najważniejsze jest znalezienie w tej pracy tego, co sprawia nam przyjemność. jeżeli tym czymś jest tylko wypłata, to nie wytrzymamy długo w QA. Niektórzy są szczęśliwi, gdy mają świadomość, iż dzięki nim odbiorca końcowy otrzymał produkt pozbawiony uciążliwych defektów. Innym przyjemność sprawia wymyślanie kreatywnych sposobów na przetestowanie oprogramowania. Każdy ma swój sposób.
Do tego testerem trzeba po prostu być. Niektórzy mówią, iż z osobami z QA trudno się dogadać — to po części prawda. Miałem do czynienia z wieloma testerami, którzy ewidentnie przekładali podejście „znajdowania problemów” na wiele aspektów swojego życia. Sam muszę temu aktywnie przeciwdziałać we własnym. Do tego problemy same znajdują nas — ja np. mam niebywały talent do nieświadomego psucia rzeczy, albo napotykania się na błędy w aplikacjach czy procesach. Tu podejrzewam, iż testerzy po prostu często podświadomie idą tą mniej oczywistą ścieżką.
Jak może rozwijać się tester? Jakie kierunki rozwoju wydają się być dość naturalne na tym stanowisku?
Osoby przychodzące do testingu zwykle dzielą się na trzy grupy. Pierwsza chce zostać testerem. Druga traktuje QA jako punkt przejściowy do osiągnięcia wymarzonego stanowiska w IT. Ostatnia stwierdza, iż zobaczy „w praniu”.
Pierwsza grupa może rozwijać się w samym obszarze QA. Jest to prawdziwy „rabbit hole” – mamy możliwość rozwoju w kierunku automatyzacji testów, specjalizacji w testach różnego rodzaju (integracyjne, wydajnościowe, bazodanowe, bezpieczeństwa, etc.). Inni mogą pójść w kierunku wsparcia zespołów testerskich — analityków, liderów, managerów testów… jeżeli lubisz testować, na pewno znajdziesz coś dla siebie. Znam osoby, które prężnie działają w obszarze quality od kilkunastu lat i przez cały czas są w stanie wymienić całą listę umiejętności, które chcą posiąść, aby być jeszcze lepszymi testerami.
Druga grupa może rozwijać umiejętności, które pomogą im na docelowym stanowisku. Chcesz zostać analitykiem? Wykorzystuj sposobności, aby wspierać analityka w projekcie, współpracować z klientem, znajdować błędy w dokumentacji i pomagać je rozwiązywać. Chcesz zostać developerem? Pisz testy automatyczne, rozwijaj się w kierunku frameworków testowych, współpracuj blisko z developerami. W dalszej kolejności proponuj własne rozwiązania, zgłaszaj się do dodatkowych zadań/projektów. Moim zdaniem niewiele stanowisk daje taką elastyczność w zdobywaniu wiedzy o innych rolach w IT, jak QA.
Tym niezdecydowanym polecam być czujnym i wyrobić sobie opinię, zapoznając się z kolejnymi możliwościami rozwoju. Teraz, z perspektywy czasu mogę swoje początki w IT zaliczyć właśnie do tej grupy. Bycie elastycznym nie jest złe — choć nie jest dla wszystkich i potrafi być momentami irytujące, gdy okaże się, iż podjąłeś się czegoś, co nie do końca Ci odpowiada. Natomiast pracodawcy często cenią sobie takich pracowników — i umożliwiają szybszy rozwój, kierując w interesujące projekty, lub takie wymagające umiejętności adaptacji i dające spory zastrzyk wiedzy. Podejście to niesie też za sobą ryzyko — płynąc z rzeką, możemy szybciej trafić w interesujące miejsce, ale możemy też osiąść na mieliźnie. Czasem zmęczeni lub zdemotywowani przestaniemy wychodzić ze swojej strefy komfortu i zostaniemy w miejscu, do którego się już przyzwyczailiśmy. Łatwo wtedy „zasiedzieć” się na danym stanowisku, co może prowadzić do wypalenia.
Który kierunek rozwoju w QA jest dla kogo najlepszy? Jakie kompetencje powinny o tym decydować?
Odpowiem mantrą pewnego znanego OSINT-owca – to zależy. Od tego, czego oczekujemy od naszej kariery, co chcemy osiągnąć. Idąc dalej cytatami — trzeba sobie zadać jedno bardzo ważne pytanie: co się lubi w życiu robić. I później zacząć to robić. Miejmy też na uwadze, iż tak samo jak rynek, my też się cały czas zmieniamy. To, co mocno interesowało nas dwa lata temu, teraz może spaść na niższy priorytet. To jest moim zdaniem bardzo dobra cecha, która pozwala nam się dostosowywać do środowiska, w którym działamy. Więc pozwólmy sobie na to, nie idźmy uparcie utartymi ścieżkami.
Dla osób, które mają mocno rozwinięte umiejętności miękkie i widzą się w rolach zarządzających, polecam rozwój w kierunku lidera zespołu czy lidera testów. Osoby, które lubią analitykę — analiza biznesowa, produktowa, lub analityk testów. Sherlocków kodu — automatyzacja testów. Osoby twórcze — development, lub UX. Znam też osoby, które z QA przeszły do zarządzania projektami. Możliwości są ogromne.
Ty sam poszedłeś w zarządzanie. Skąd taki wybór?
Wcześniej wspominałem, iż sam należałem do osób, które nie wchodziły w IT z konkretną wizją swojej kariery. Popłynąłem z prądem. Nadarzyła się okazja rozwoju w kierunku zarządzania — najpierw testami, później zespołem, z czasem całym departamentem QA. Okazało się, iż jestem w tym dobry. I praca z ludźmi sprawiała mi przyjemność.
Po przykrych doświadczeniach z gastronomii miałem jasną wizję tego, jakim przełożonym chcę być. Nie „szefem”, a liderem. Wspierać ludzi. Ta ambicja wymaga ciągłego balansowania pomiędzy oczekiwaniami wyższego managementu a potrzebami ludzi i chęcią ich wsparcia. Z jednej strony chcesz dać pracownikowi sensowną podwyżkę, z drugiej jesteś rozliczany z wyników finansowych i musisz spełnić wyznaczone cele. Do tego masz świadomość, iż twoje decyzje mają wpływ na ludzi, ich rodziny. Nie zarządzasz słupkami w Excelu, czy postaciami z gier. Trzeba umieć się w tym odnaleźć i nie zwariować. Mnie się udało, chociaż niedawno podjąłem decyzję o chwilowej zmianie profilu i powrotu do pracy „operacyjnej” – aby się nie zasiedzieć.
Jak Ci się pracuje w obecnym miejscu?
Obecnie pracuję jako architekt testów w banku, w naszym departamencie wytwarzamy oprogramowanie i procesy, z którego korzystają pracownicy banku przy obsłudze klientów. Jestem odpowiedzialny za to, aby procesy wytwórcze i zarządzania jakością spełniały określone wymagania i były zgodne z dobrymi praktykami. Wdrażam narzędzia do zarządzania jakością i jej utrzymania. Same interesujące rzeczy.
Co do stosunku pracy, jestem kontraktorem — to znaczy, iż jestem zatrudniony w firmie konsultingowej specjalizującej się w dostarczaniu specjalistów dla organizacji, które nie muszą później utrzymywać wyspecjalizowanych w IT liderów i managerów, kadr itd. Firma konsultingowa, z którą mam bezpośrednio podpisany kontrakt to emagine.
Wow, masz aż dwóch pracodawców — jak to wygląda w praktyce?
Uznaję to za mały chichot historii w moim życiu, gdyż do niedawna sam zarządzałem pracownikami QA w firmie konsultingowej. Natomiast pracuje mi się bardzo dobrze — emagine wstrzeliło się idealnie w moje oczekiwania. Nie przeszkadzają w realizowaniu pracy, są praktycznie transparentni przy realizacji zadań dla klienta. Nie zarzucają zbytnią biurokracją — wypełniam prosty raport przepracowanych godzin w przejrzystej aplikacji, wysyłam fakturę, dostaję należność na konto.
Czasem jest wręcz lepiej, niż z jednym pracodawcą — mam w emagine prostą ścieżkę komunikacji, jeżeli pojawia się jakiś problem, potrzeba negocjacji z klientem na poziomie kontraktu, czy też zmiany klienta lub projektu. Pilnowane są daty zakończenia umowy, stąd wiem, iż choćby gdybym był mocno obłożony pracą — nie obudzę się nagle bez kontraktu.
Teraz pytanie z trochę innej beczki Niedawno debiutowałeś na konferencji „QA Summit”, podczas której użyłeś interesującego określenia — Fullstack QA. Rozwiniesz, proszę, co się kryje za tym hasłem?
Jest to swoisty buzzword, nieoficjalne określenie „testera od wszystkiego”. Czyli, jak to mawia mój kolega Tomasz Szyborski (z którym prowadziliśmy tę prelekcję) – murarz, tynkarz, akrobata. Nazwaliśmy tak osobę, która bez problemu zautomatyzuje testy, postawi framework testowy, zarządzi procesem testowym, napisze strategię testów, wykona testy wydajnościowe, ustali szczegóły z biznesem i na koniec wykona testy eksploracyjne, jeżeli zajdzie taka potrzeba.
Przesłanie naszej prelekcji było dwojakie — z jednej strony pokazać zainteresowanym kierunki rozwoju dla osób, które chcą poszerzyć wachlarz umiejętności w obszarze quality. Z drugiej — zaznajomić słuchaczy z oczekiwaniami rynku i przełożonych oraz jakie mamy opcje i jakie kroki możemy wykonać, gdy jesteśmy zmuszani do wejścia w rolę, w której się do końca nie widzimy.
Jak myślisz, jak będzie wyglądało zapotrzebowanie na testerów w przyszłych latach?
Uważam, iż obecna „recesja” jest kolejnym wahnięciem w koniunkturze rynku IT i jak na razie nie jest zapowiedzią ogromnego załamania zapotrzebowania na specjalistów. Wracamy po pandemii na dawne tory. Natomiast rozwój narzędzi opartych na AI zapowiada w przyszłości większe zmiany w obszarze IT. Widzę tu szansę dla QA, a nie problem. To prawda — sztuczna inteligencja potrafi wygenerować kod, grafiki, prawdopodobnie w kolejnych iteracjach będzie mogła wytwarzać całe aplikacje na podstawie dość ogólnie sporządzonych wymagań.
Jestem jednak świadomy, iż tak wytworzone oprogramowanie musi zostać przetestowane — szczególnie dogłębnie, gdy zostało przygotowane przez AI. Wyniki jej pracy są często niespójne i niedokładne, oderwane od kontekstu. Do tego występuje zjawisko halucynacji AI — gdy model twierdzi, iż wie, co robi, mimo iż nie ma zielonego pojęcia. Ktoś musi to wszystko zweryfikować. I tu widzę przyszłość dla QA.
Nie bójmy się, iż AI zabierze nam pracę — uczmy się wykorzystywać narzędzia, które zapewnia, do optymalizacji swojej pracy oraz redukcji monotonnych i nudnych zadań. Przykłady? Poprawianie wielu przypadków testowych, ich duplikacja ze zmienionymi krokami, analiza logów, tworzenie danych testowych… To, co zajmowało godziny czy dni pracy, dzisiaj może być zrobione w minuty. A my możemy się skupić na tym, co najważniejsze — znajdowaniu defektów i wspieraniu wytwarzania systemu wysokiej jakości.
Jakub Klech. Menedżer QA znający obie strony mocy – dba o jakość w projektach jako lider i architekt testów, jak i menadżer rozwijający zespoły testerskie. Zapewnia dostarczanie kompleksowych rozwiązań w zakresie utrzymania jakości dla klientów.
Zdjęcie główne pochodzi z Envato Elements.
