Mateusz: Gdy w 2014 roku pracowałem w jednej z poznańskich firm zajmujących się budowaniem sklepów internetowych, testowanie aplikacji wcale nie było zbyt popularne. Większość rzeczy programista musiał sprawdzać samodzielnie. Pamiętam natomiast, że tamta firma zatrudniała wówczas na pół etatu dziewczynę, która przychodziła pomiędzy zajęciami na uczelni, aby wykonywać różnego rodzaju testy manualne tworzonych przez nas sklepów. Praca testera dzisiaj wygląda zupełnie inaczej. O pracy testera rozmawiam ze specjalistą od jakości oprogramowania. Jego historia obfituje w mnóstwo zabawnych anegdotek i różne wartościowe spostrzeżenia. Dowiesz się z niej m.in. o tym, jak zacząć pracę jako tester, jak się dalej rozwijać, gdy już jesteś testerem i czy warto robić certyfikaty, co mogą Tobie dać? Ja nazywam się Mateusz Jabłoński. Moim gościem był dzisiaj Jakub Skibiński. A Ty słuchasz podcastu? Start w IT! Startujemy!

Mateusz: Witam wszystkich. Jest z nami dzisiaj Kuba. Kuba Skibiński, który jest testerem jest QA z wieloletnim doświadczeniem i w dzisiejszej rozmowie chciałbym, żebyśmy poznali trochę ten temat, poznali jego pozycję i jego przemyślenia na temat tego, czym się zajmuje i w jaki sposób rozwija się jako właśnie jako człowiek odpowiedzialny za jakość. Witaj Kuba.

Jakub: Witaj Mateuszu. Witaj, cześć.

Mateusz: Kopę lat się nie widzieliśmy. Jest mi bardzo miło, że przyjąłeś moje zaproszenie do rozmowy i że będziesz mógł się dzisiaj ze mną podzielić troszeczkę, ze mną i z naszymi słuchaczami, troszeczkę tym swoim doświadczeniem i swoim spojrzeniem na tą branżę. Wiem, że jako tester oprogramowania pracujesz już w branży od wielu, wielu lat. Powiedz mi Kuba, czym się zajmujesz dzisiaj? Jak to wygląda w tym momencie? Czy praca testera dzisiaj zmieniła się na przestrzeni lat? Patrząc na to, jak zaczynałeś i patrząc na to, kim jesteś teraz?

Jakub: Wiesz co, wydaje mi się, że na samym początku mojej przygody z testowaniem. A to się zaczęło jakieś 13 lat temu, we wrześniu jakoś mi strzeli 13 lat, to nie miałem zielonego pojęcia o co chodzi z tym testowaniem tak naprawdę, bo pierwsza rozmowa o pracę właściwie nie dotyczyła testowania oprogramowania w ogóle. To było tak naprawdę podczas rozmowy pytanie o to, żeby znaleźć w tekście błędy. Pamiętam to jak dziś, poszedłem na rozmowę i dostałem tekst po polsku z błędami. I moim celem było znalezienie błędów w tekście. Znalazłem te błędy i dostałem pracę jako tester i o tej pracy nie miałem zielonego pojęcia, w ogóle o co w tym wszystkim chodzi. Tak naprawdę uczyłem się po omacku na samym początku.

Mateusz: Powiedz mi proszę, bo akurat zacząłeś ten temat rekrutacji Słyszałem wielokrotnie, że na rekrutacjach na testera rzucają pomysły w stylu zepsuj bankomat albo tu masz długopis, zepsuje go i przetestuj. Często się to zdarza?

Jakub: Zdarza się. Zdarza się, ale wydaje mi się, że przez ostatnie lata można powiedzieć poziom trudności rozmów rekrutacyjnych znacznie wzrósł. Ja, tak jak powiedziałem wcześniej, zaczynałem od rozmów typu znajdź błędy w tekście i to było śmiesznie proste. Teraz te rozmowy to już są naprawdę, zdecydowanie cięższe. Teraz tester musi mieć o wiele większą wiedzę, jeżeli chce w ogóle wejść w tą branżę. Czyli ta osoba, która chciałaby w ogóle rozpocząć tą całą przygodę na pewno musi liczyć się z wyższym progiem wejścia niż to było naście lat temu. Świadomość tego, czym jest testowanie, cała branża zapewnienia jakości to zupełnie się przez te lata zmieniły.

Mateusz: Hasło tester, kiedy mówimy tester, może być bardzo ogólne dla wielu, wielu osób. Wydaje mi się, że w ramach tego hasła możemy wyróżnić różne pozycje testera manualnego, automatyzującego, QA. Pewnie jeszcze kilka, kilka innych. Powiedz mi czym się różnią od siebie? Prawdopodobnie pracowałeś na każdej z tych pozycji, znając Ciebie i tak sobie myślę właśnie, że może gdybyś mógł jakoś przybliżyć, które role są dla Ciebie najciekawsze, czym się różnią i jak to wygląda z Twojej perspektywy?

Jakub: Na pewno każda rola ma swoje plusy i minusy. Ja zaczynałem od testera manualnego, czyli kogoś, kto testy wykonuje ręcznie, bez użycia jakichś narzędzi automatyzujących, czyli właściwie, kiedyś mówiło się o nas, że jesteśmy takimi klikaczami, a właściwie każdy teraz przeciętny konsument jest testerem manualnym, tzn. wykonuje pewne czynności manualnie, tak jak scrollujesz Facebooka czy powiadomienia, które Tobie wyskakują i otwierasz, sprawdzasz, wysyłasz maila, cokolwiek. Także to są takie manualne rzeczy, które robisz dosłownie ręcznie i właściwie jadąc samochodem teżwykonujesz rzeczy manualnie, naciskając pedał gazu, pedał hamulca. Czyli właściwie jeżeli mówimy o nomenklaturze takiej typowo testerskiej, jeżeli chodzi o branżę IT, to na pewno taki tester manualny, tak jak mówiłem, wykonuje raczej testy ręcznie. Coraz częściej przy użyciu też jakichś narzędzi, takich quasi automatycznych, tzn. np. dzisiejsze aplikacje to nie są już strony internetowe napisane tylko w HTMLu, tylko to są już aplikacje, to są programy, które przy każdym kliknięciu powodują, że coś gdzieś tam w tle się dzieje, jest zapisane coś do bazy danych. Tak jak dodajesz na Allegro cokolwiek, przykładowo na allegro dodajesz do koszyka, to gdzieś te zmiany również się dzieją po tej stronie, której nie widzi zwykły konsument. Więc ci testerzy muszą też skupić się na testowaniu tych rzeczy, których nie widać. Czyli reasumując tester manualny wykonuje testy ręcznie. Czyli te sprawdzenia, skupia się na funkcjonalnym testowaniu aplikacji z perspektywy użytkownika końcowego. Tak bym ładnie to z definicji powiedział. I te testy są przeprowadzane zgodnie z wcześniej przygotowanymi scenariuszami, testami. Tester musi zapisywać wyniki tych testów. Do tego oczywiście są odpowiednie programy, w których możesz wyklikać czy test przeszedł czy nie zgodnie z jakimiśwymaganiami od klienta i te testy, które ten tester wykonuje to z reguły testerzy sami piszą w oparciu o to czego klient chce. Często klient dostarcza wymagania przykładowo takiej ścieżki przejścia przez aplikację. Musisz się przykładowo zalogować, dodać coś do koszyka w aplikacji zakupowej, dokonać opłaty, wylogować. Produkt został zakupiony. Musisz to sprawdzić. Czy przykładowo tak się dzieje. Wysłać przelew to musisz wykonać odpowiednie kroki. Klienci dostarczają nam wymagania, tego, jak ta aplikacja ma działać, a my na tej podstawie piszemy testy. Ja nadal to robię, tzn. to nie jest tak, że ja już zupełnie nie zajmuję się tą warstwą, że ona jest be i w ogóle jej nie lubię. Nie, nie to do dzisiaj. Cały czas się zajmuję tym, że dostaję wymagania od klienta na podstawie tych wymagań pomagam, czasem używam jakiegoś wsparcia innych kolegów z zespołu, żeby napisać testy, które mają sprawdzić, czy te wymagania, których klient od nas zażądał i czy rzeczywiście one są spełnione. Te wymagania mogą być różnorakie, ale manualny tester sprawdza w oparciu o testy napisane czy wymagania zostały spełnione. Natomiast ten drugi tester, automatyzujący, to troszkę sobie tą sprawę ułatwia - te powtarzalne czynności, które mógłby tester manualny wykonywać dziesiątki, setki, tysiące razy. To on sobie je automatyzuje, czyli de facto pisze program, który wchodzi w interakcję przykładowo ze stroną internetową, z aplikacją na telefonie i wykonuje jakieś kroki, które normalnie oczywiście również można by było wykonać manualnie. I teraz jaki jest główny clue tego wszystkiego? Te testy mogą być wielokrotnie uruchamiane. Przykładowo. To jest trochę tak, że te testy automatyzujące się tak jak mówiłem wcześniej, to są takie programy, które są wykonywane po to, żeby znajdywać też błędy w częściach aplikacji, która została rozwinięta wcześniej. To są tzw. testy regresji. Czym są testy regresji? Generalnie, w skrócie, koszt wytworzenia testów automatycznych jest dość duży, bo to nie jest tak, że tester po prostu napisze kilka linijek kodu i to wszystko działa. Często trzeba zbudować cały można powiedzieć framework wokół najbardziej popularnych takich narzędzi jak Selenium, Playwright w tym momencie, jeszcze jest oczywiście Cypress i pewnie parę innych narzędzi, frameworków. Niektórzy mówią na to, mówimy na to frameworki, niektórzy mówią, że to są biblioteki testowe. To już w zależności od kogo, z kim będziesz rozmawiał. Natomiast trzeba napisać całą można powiedzieć architekturę pod te testy automatyczne / automatyzujące, jakkolwiek byśmy to zwali i te testy mają nam zapewnić, że to co wcześniej zostało stworzone nadal działa. Możemy setki, tysiące razy wykonywać, żeby potwierdzić, czy np. nowe zmiany, które doszły do naszego oprogramowania nie spowodowały jakichś uszkodzeń w aplikacji. Aczkolwiek problem też jest taki, że cały czas trzeba te testy utrzymywać. Czyli jeżeli coś tam zostało zmienione w tej warstwie, którą testujemy, w której wykonuje się te testy, to musimy też naprawiać te rzeczy. To nie jest tak, że jest zawsze na zielono czy jest zawsze na czerwono. Cały czas to jest też taka praca, utrzymaniowa. Trochę jak z samochodem. Musisz robić regularny przegląd, oleju i innych części, ale na pewno te testy pomagają. Przykładowo, jeżeli już masz setki testów na jednym projekcie, to mieliśmy już bardzo dużo tych testów. Manualnie to się wykonywało dwa dni, jakbyś chciał to wykonać manualnie. Natomiast automatyczne testy robiły to w niecałą godzinę. Czyli też oszczędzasz czas. Można powiedzieć, że inwestycja w testy automatyczne powoduje też to, że może nie oszczędzisz na początku pieniędzy, bo musisz zainwestować, ale potem to się zwraca, bo możesz te testy bez już ingerencji ludzkiej właściwie wykonywać. Także, ale to też nie jest gwarancja tego, że aplikacja będzie działać tak, jak byśmy chcieli. I to jest właśnie to. Jest taki fajne, takie fajne określenie: paradoks pestycydów - to jest z tej nomenklatury testerskiej. Paradoks pestycydów polega na tym, że cały czas sprawdzasz jedno miejsce tymi samymi środkami w cudzysłowie. To tak jakbyś chciał zabić stonkę ziemniaczaną tylko w jednej części twojego pola. I cały czas tam te chemikalia wylewasz. Próbujesz ją zabić i jej już tam nie ma, bo ona się przemieściła gdzieś indziej. Więc po to mamy te testy, powiedzmy automatyczne regresji, żeby sprawdzać czy się nic nie zepsuło w tej części aplikacji, w tej części naszego pola. Ale mamy też testy eksploracyjne, które mają też sprawdzić, czy coś nie zostało popsute gdzieś indziej. Czasem nawet nie potrzebujemy wymagań do tego, bo wiemy przykładowo, że w jakiejś części aplikacji coś było zmienione. I z doświadczenia już taki tester, który przerobił wiele projektów wie, że jeżeli zmienili logowanie to wylogowanie też się mogło zmienić. Jeżeli zmienimy jakąś część aplikacji to to też się mogło zmienić. Więc te testy eksploracyjne, manualne, bo manualne, bo są szybsze, polegają po prostu na tym, żeby posprawdzać, czy coś się tam jeszcze nie zepsuło. No i tutaj przychodzą jeszcze inne testy. Tu są smoke testy, tak zwane po polsku testy dymne, które mają zrobić takie szybkie sprawdzenie czy aplikacja nadal działa, czyli np. czy możesz wejść na stronę główną i inne podstrony bez ingerencji w samą logikę, w jakieś procesy, które są gdzieś na stronie i w aplikacji zaimplementowane. I pytałeś o jeszcze jedną rzecz Quality Assurance.

Mateusz: Dokładnie, QA.

Jakub: Tak, bo QA zwykło się nazywać testerów. Ale to nie jest tak do końca, bo to może być cały zespół, który jest odpowiedzialny, cały zespół lub jedna osoba, która jest odpowiedzialna za zapewnienie jakości całego procesu tworzenia oprogramowania. Bo to nie jest tylko testowanie, to też są jakieś audyty, to jest przegląd kodu, to jest analiza dokumentacji, wymagań klienta. Często tak jest, właściwie prawie zawsze, że to nie my rozmawiamy z klientem jako my testerzy czy programiści, tylko jest jakiś business analityk, który z tym klientem rozmawia. Klient mówi czego chce i te wymagania trafiają od klienta do business analityka, który je tłumaczy trochę na nasz język, żebyśmy wiedzieli, co my mamy robić. No i też się zaczyna dyskusja już na poziomie wymagań od klienta. Zaczynamy się zastanawiać nad tym, jak to będzie trudne zagadnienie i wiesz, ile pracy trzeba włożyć itd. To też jest i oczywiście też jakie potencjalne błędy mogą się pojawić i zagrożenia. Więc to też jest część tego QA, czyli Quality Assurance i generalnie to quality to tak jak mówiłem wcześniej, to są jakieś audyty, to jest przegląd kodu, to jest analiza wymagań, analiza dokumentacji, wdrażanie jakichś procedur i standardów jakościowych. Quality Assurance zajmuje się też analizą procesów wytwórczych i ich optymalizacją po to, żeby błędy w przyszłości nie pojawiały się w późniejszych fazach wytwarzania oprogramowania.

Mateusz: OK, ale czy można powiedzieć, że Quality Assurance Specialist jest jakby następnym krokiem po testerzy automatyzującym, czy to jest po prostu stanowisko, które sobie gdzieś z boku też w ramach tej domeny testowania?

Jakub: Ja bym powiedział, że to jest w ramach testowania, bo tak jak mówiłem wcześniej, to Quality Assurance to jest właśnie taki dział zapewnienia jakości, tak jak w każdej firmie produkcyjnej, np. firma produkcyjna. To jest bardzo ciekawe np. w Japonii, w Japonii, oni mają ten Lean management, koło Deminga, czyli takie ciągłe usprawnianie procesów na praktycznie każdym etapie, takie mikro usprawnianie, czyli robią jakiś jeden krok, starają się go usprawniać. To też jest jakość. Finalnym efektem naszej pracy powinno być czy to jest, czy to chodzi o oprogramowanie, czy w ogóle wytwarzanie czegokolwiek, to nawet pieczenie pizzy czy zrobienie hamburgera w McDonaldzie. Ktoś musiał przeanalizować kolejne kroki. To pewnie był cały sztab ludzi. Jedni się zajmowali inną częścią, drudzy jeszcze inną. Każda z tych osób dążyła do zoptymalizowania i poprawienia jakości danego etapu. No to tak jak było z Henrym Fordem. Henry Ford, jak zaczął produkować na masową skalę Forda T. to była produkcja taśmowa. To też w jakiś sposób zoptymalizowany każdy proces produkcji, żeby jak najszybciej to zrobić. Więc właściwie tam też był jakiś dział jakości, taki QA, może nie w takim rozumieniu tego słowa jak dzisiaj i to pewnie w każdej firmie to jest. Bankowo.

Mateusz: No. Czy w każdej to bym się pewnie...

Jakub: Ostatnio w Boeing'u były jakieś ciekawe historie, że tam troszkę zaniedbali jakość.

Mateusz: No właśnie, to która według Ciebie jest najciekawsza z tych wszystkich? I w których się najlepiej czułeś albo czujesz?

Jakub: Wydaje mi się, że chyba w tej roli automatyka.

Mateusz: Automatyka.

Jakub: Aczkolwiek nie jest to łatwe. Czasem jest ciężko, bo musisz ciągle uczyć i nadążać za tymi zmianami, które się dzieją wokół. Ale właściwie każda rola, czy to będzie programista, czy to będzie nawet tester manualny.

Mateusz: Wymaga rozwoju.

Jakub: Musisz się cały czas rozwijać. Pamiętam, że kiedyś byłem dawno temu na rozmowie dla norweskiej firmy, w której bardzo fajne pytanie dostałem. Nikt się nie pytał o to co umiem, tylko jakie narzędzia bym zaproponował do przetestowania ich aplikacji i dostałem kilka dni na to, żeby wrócić do nich. Oni mi powiedzieli, że ich aplikacja jest napisana w takim a takim języku i mam wrócić do nich za kilka dni. Umówili kolejne spotkanie i mam powiedzieć, jakbym to sprawdził i nie muszę tego znać, tylko sprawdzić, zrobić analizę. I to dla mnie też było takie wow. Tak trochę jak jesteś kierowcą. Bym powiedział: ja umiem jeździć samochodem osobowym, no ale my musimy przewieźć wiatrak na drugi koniec Polski, to jak Ty to zrobisz, to zaczniesz myśleć. Osobówka wziąłbym może większą przyczepę. Wiesz, bo myślisz w kategoriach tego, co potrafisz, a nie tego co potrzebne. Więc to też jest taka ciekawa rzecz. Lubię wyzwania trudne. Trudne wyzwania lubię. Lubię. Nie wiem.

Mateusz: Fajnie. Super. Kuba, bo w twojej karierze też znajdziemy takie smaczki jak chociażby bycie mentorem w szkole programowania czy też uczenie innych takich aspektów nie tylko testerskich z tego co wiem, ale też na przykład matematyki. Powiedz mi proszę, bo dla wielu osób testowanie to najczęściej pierwszy wybór, kiedy myślą o wejściu do branży IT. Czy myślisz, że testowanie to rzeczywiście jest najlepszy sposób, żeby dostać się do IT? Żeby zostać, żeby najpierw zostać testerem, a potem myśleć o rozwijaniu siebie w kolejnych kierunkach?

Jakub: To zależy co kto lubi, bo to nie jest tak, jak często się mówi, że to jest jakieś eldorado i w ogóle. Z drugiej strony to jest praca jak każda inna tester, ale tester musi mieć takie umiejętności przede wszystkim analitycznego myślenia, czyli zdolności do analizowania np. błędów, które napotyka w aplikacji, żeby wiedział, czy to jest błąd, czy to jest oczekiwane zachowanie, umiejętności zrozumienia wymagań klienta i jak to się przekłada na jakość aplikacji. Na pewno tester musi być dokładny i dbać o szczegóły. To też jest ważna umiejętność. Czyli to nie jest tak, że sobie kliknę tutaj, kliknę tam, tylko raczej chcesz dogłębnie poznać sposób działania aplikacji. To trochę jak z testowaniem gier. Mam znajomego, który pracował w tej branży i wydaje się, że to jest takie, ło Jezu, grasz całymi dniami. Grał w kilka znanych tytułów i zajmował się tymi tytułami, ale to nie jest tak. Setki razy czasem przechodzisz ten sam poziom i musisz wszystkie ścieżki przejść, sprawdzić, czy na pewno to jest tak jak być powinno i tutaj trochę też jest. Testując oprogramowanie musisz wymyślać, często być kreatywnym jak coś zepsuć, bo to też na tym polega. Czyli dostajesz aplikację i już zaczynasz myśleć co ja mogę zrobić, jak to zepsuć. Już mając doświadczenie wiesz, że o zobaczymy co się dzieje. Gdzieś tam na backendzie, że jak może po API coś zepsuje, może się zaloguję jakoś, a może dodam coś, może coś usunę. Zobaczmy co się dzieje. Zaczynasz być takim trochę, trochę jak dziecko zaczynasz psuć. Właśnie to jest ciekawe jak zadasz pytanie ludziom czasem na rozmowach o pracę jakby coś przetestowali. Przykładowo wspomniałeś wcześniej o długopisie. Rzadko się znajdą osoby, ale znajdują się, które mają bardzo kreatywne podejście do testowania przykładowo długopisu. To jest takie fajne pytanie jak byś przetestował długopis? I niektórzy tak nie wiedzą za bardzo o co się pytasz ich. Długopis. Każdy wie jak działa długopis, no ale Ty masz go zepsuć. Jak zepsuć, jak sprawdzić wydajność? To tak jak w oprogramowaniu czy w samochodzie. Musimy sprawdzić różne aspekty aplikacji. Długopis jest świetnym przykładem, bo długopis ma jakąś wydajność i ile tam jest w stanie kartek zapisać. Przykładowo ile liter napisać, ile linii, czy nie ma wycieków tak jak w samochodzie? Nie wiem. Tuszu, czy wiesz ile klików? Jeszcze trochę takiej małej dygresji. Jeden mój znajomy pracował dla dużej firmy samochodowej, gdzie musiał opracować licznik: ile razy zostaną otwarte drzwi, aż zawiasy się nie zepsują i oni to testowali. Było jakieś tam urządzenia, które otwierały, zamykały drzwi. Setki, tysiące, dziesiątki tysięcy razy się okazało, że powiedzmy po 150 tysiącach otwarć drzwi zawiasy już nie wytrzymują. To były drzwi przesuwne. Czyli wracając musi posiadać analityczne myślenie, posiadać tę umiejętność, być dokładnym. Oczywiście znać narzędzia, które mogą pomóc przy tym testowaniu. To tak jak każdy mechanik czy jakikolwiek inny specjalista musi mieć jakieś narzędzia, zestaw narzędzi do testowania, np. do pomocy w testowaniu backendu, czyli tej niewidzialnej części aplikacji. Może do testowania jakiegoś wizualnego czy jak sprawdzić, czy przykładowo dobre kolory są w aplikacji, bo klient chciał mieć różowy zapisany w jakimś hex konkretny róż, a Ty nie wiesz jak to sprawdzić. Musisz wiedzieć, czyli musisz znać narzędzia. To wszystko jest teraz dostępne bardziej niż kiedykolwiek. No i przede wszystkim znajomość procesów takich jak Agile, Scrum. Jakie są techniki testowania takie jak np. co to jest testowanie funkcjonalne, niefunkcjonalne, wydajnościowe, regresji i inne itd, itd. No i do tego wszystkiego potrzeba też teorii. A to wszystko jesteś w stanie wyczytać i się wszystkiego nauczyć. Jeżeli chodzi o teorię.

Mateusz: A propos tego długopisu to tak sobie pomyślałem może nie jestem testerem, ale wydaje mi się, że warto sprawdzić jak bardzo odporny jest na ślinę.

Jakub: I ogień, zamrażanie, upadki. Pamiętam, kiedyś mieliśmy w jednej firmie spotkanie z jednym z kolegów. Mieliśmy jakieś takie spotkanie testerskie i wymyślaliśmy sobie różne rzeczy, jakbyśmy coś sprawdzali. Tam chodziło chyba o monitory, jakbyście przetestowali. Możesz wszystko z tym monitorem zrobić. Dosłownie wszystko. Czyli odporność, powiedzmy na ogień, na coś. No i tak wymyślamy, wymyślamy i w końcu gdzieś padło: a może by ten monitor zamrozić? Wiesz, w jakiś tam drastycznie niskiej, taki bardzo niskiej temperaturze. A ten kolega, który nas o to pytał, on pracował też dla dużej firmy, która zajmowała się produkcją monitorów, m.in. dla jakiejś tam stacji arktycznych badawczych i mówił, że oni mieli specjalną komorę w firmie do testowania monitorów w ekstremalnie niskich temperaturach, żeby zobaczyć, co się stanie. Dostarczali to na Antarktydę czy gdzieś to przecież tam jest bardzo zimno i żeby to działało po podłączeniu do prądu, więc zamrażali monitory, wystawiali na ciepło. Tam to testowali i sprawdzali, które monitory są najlepsze w takich warunkach.

Mateusz: Z takich ciekawych historii to jeszcze przypomniało mi się jak kolega mówił, że dostali cały bankomat do pokoju. Z oszukanym pieniędzmi mieli po prostu wycięte, wycięte odpowiedniej grubości papier, który miał imitować wielkość banknotów i on był tak zaprogramowany, żeby odczytywał je odpowiednio jako odpowiednie banknoty i musieli go spróbować go zepsuć, tak jakby to użytkownik miał coś z nim zrobić i z tego co mówił to była dość ciekawe zadanie. Cały dział QA miał swójbankomat, a z innych rzeczy takich też ciekawostek a propo tego co powiedziałeś, wracając do naszego pytania. To testowanie nie zawsze musi być takie jak nam się wydaje. Takie fajne chociażby jak to testowanie gier. Jest easter egg w Wiedźminie 1, na jednym dachu budynku programiści postawili i położyli kościotrupa, żeby oznaczyć miejsce, w którym tester siedział cały dzień i obserwował otoczenie, żeby wyszukiwać błędów, błędów w otoczeniu, które się renderowało i w grze zostawili takiego kościotrupa na dachu w jednym z budynków, żeby z tego akurat miejsca było najlepiej wszystko widać. Więc to też czasami chyba tak jest, że ta praca jest żmudna po prostu na to też trzeba się przygotować.

Jakub: Tak to na pewno. Czasem wykonujesz te same czynności dziesiątki, setki razy. Szczególnie jak musisz coś sprawdzać ręcznie, to jest to na pewno uciążliwe. Z czasem to powszednieje, tzn. wiesz, jeżeli jesteś już jakiś czas na jakimś projekcie, to właściwie dużo rzeczy jest bardzo powtarzalnych. Aczkolwiek to też może być niestety przyczyna popełniania błędów, bo ludzie przestają być dokładni i wnikliwi, więc na pewno wydaje mi się, że z takiego osobistego doświadczenia zmiana projektów jest ważna, bo wtedy zaczynasz zauważać, wchodząc do nowego projektu rzeczy, których osoby, które już mają doświadczenie, nie zauważają. To na pewno jest ważne. To tak jak w każdej chyba innej pracy. Rutyna gubi.

Mateusz: Rutyna gubi. Rozmawialiśmy też. Wspomniałeś też dużo o umiejętnościach, które powinien mieć tester. Dużo mówiłeś o technicznych rzeczach. Jakie umiejętności miękkie osoba powinna posiadać, która chciałaby aspirować do zostania testerem?

Jakub: Na pewno komunikatywność i umiejętność współpracy z innymi. Bo tak naprawdę wszystkie projekty to są projekty, które składają się z grupy osób, to są zespoły, które ze sobą współpracują. To są developerzy, to jest project manager, Product Owner i tak dalej, itd. Więc. Też mam okazję współpracować z takimi bardzo zamkniętymi w sobie osobami i to czasem jest trudne, bo jeżeli taka osoba się zamyka i coś tam dewelopuje i nie wiesz do końca co ta osoba tam tworzy i w końcu gdzieś tam coś dostarcza i to nie działa i komunikujesz takiej osobie, która jest bardzo introwertyczna. To ty nie wiesz tak naprawdę jak to, czy on to bierze do siebie czy jak niektórzy to rzeczywiście biorą do siebie, że są nieomylni. Także umiejętność współpracy z ludźmi to jest bardzo ważne. Umiejętność też brania krytyki na siebie, bo nie zawsze to, jak Ty pracujesz może się wszystkim innym podobać. Umiejętność komunikacji, umiejętność komunikowania też tego, jak Tobie się pracuje. To mi się podoba. Kiedyś miałem opory. Teraz już nie mam oporów w mówieniu tego, co mi się podoba, co mi się nie podoba. Więc mówię - różnie to może być odbierane, ale raczej jest to odbierane pozytywnie, bo ja nie krytykuję osób stricte, że ten developer coś, ten programista coś źle zrobił czy menadżer źle zarządza projektem. Bo nie mówię w ten sposób, tylko mówię, że nie podoba mi się sposób w jaki przykładowo robimy to. Uważam, że powinniśmy więcej rozmawiać na ten temat. Także komunikatywność, umiejętność komunikacji, też problemów jakie masz. Pewnie też miałeś okazję pracować z ludźmi, którzy są bardzo: "aaa everything is all right", a nie jest all right. Ile razy bali się powiedzieć, że oni nie wiedzą jak coś zrobić? To jest niesamowite.

Mateusz: To typowe jest w zasadzie, nawet jak ja prowadzę czasami rekrutację, to bardzo często słychać ten motyw, gdzie zadajesz pytanie i ktoś nie wiedząc jak coś zrobić to tak naprawdę mówi: a bez sensu, po co to w ogóle robić? Albo. A przecież jakieś narzędzia ogarniają. Ja nie muszę o tym wiedzieć. Tak naprawdę ludzie nie zgłębiają domeny, bo nie chcą, bo tak naprawdę lepiej założyć, że będzie to samo działało, że samo się rozwiąże. I jak bug się pojawia, to nawet On nie jest mój. On wynika z narzędzia, a nie z tego, że ja nie zrozumiałem jak czegoś użyć.

Jakub: Czyli tak jak mówisz umiejętność brania krytyki na siebie i odpowiedzialności za swoją pracę. Bo my nie jesteśmy ideałami. Każdy z nas popełnia błędy. W nomenklaturze testera to bardzo fajnie się wszystko skleja. Każdy popełnia błędy. Umiejętność mówienia też tego, że czegoś nie umiesz, to też jest ważne, bo zawsze znajdzie się ktoś. Bardzo lubię pracować z ludźmi, którzy wiedzą więcej niż ja, czyli od których mogę się czegoś nauczyć. Bo ja wtedy zaczynam łapać tę wiedzę od innych i to jest super. Uwielbiam się uczyć od innych osób, które coś więcej wiedzą, bo zawsze zaczynasz poszerzać swoje umiejętności. I to jest na pewno ważne. Rozmawianie z innymi. Ja kiedyś się bałem mówić. Myślałem, że jeżeli powiem, że nie umiem czegoś zrobić, to będzie problem. Pamiętam, to była moja pierwsza praca jako tester automatyzujący. Dostałem pracę w firmie, w której trochę był klimat start -up'owy, czyli właściwie dużo się pracowało, coś nowego się tworzyło i w pewnym momencie ja dostałem, z dzisiejszego punktu widzenia, banalne zadanie do zrobienia, ale dla mnie to wtedy to było po prostu coś nie do przejścia. I tak się męczyłem 2 tygodnie, żeby to zrobić i w ogóle mi to nie wychodziło. W końcu kolega mnie zapytał: jak tam Ci idzie. Ja nie wiem jak to zrobić w ogóle, już się poddałem. Myślałem, że za chwilę mnie po prostu zwolnią i wyląduję na bruku, A on mi mówi Ale to słuchaj, to możesz zrobić tak i tak, bo to w sumie się robi tak i tak, bo to jest taki ogólny sposób do robienia czegoś. On mi to wytłumaczył. Ja wtedy dostałem takiego olśnienia Boże, przecież to jest tak banalne, a ja tyle czasu straciłem. I teraz zupełnie inaczej do tego podchodzę, tzn. staram się długo nie siedzieć nad zagadnieniem, tylko jeżeli naprawdę nie wiem, a wiem, że ktoś może wiedzieć lub pytam, bo nie wiem. Po prostu pytam czy ktoś miał doświadczenie z tym i się okazuje nagle, że przynajmniej jedna osoba miała już jakieś doświadczenie. Ostatnio miałem taką trudną rzecz do rozwiązania. Musiałem stworzyć jakiś lokalny serwer musiałem zbudować, bo nie miałem użytkowników do testowania, żeby ich tworzyć. I też na początku dla mnie było to naprawdę rocket science. Trochę, bo to była dosyć skomplikowana rzecz do zrobienia z naszą aplikacją, ale okazało się, że ktoś już coś podobnego robił, to już mogłem się zapytać i okazało się: o kurczę, trochę tutaj trochę wiedzy stąd wezmę, poszukam tutaj. Okazuje się, że są jakieś dokumentacje w ogóle w internecie, bo nie tylko ja miałem z tym problem. No i nagle jesteś w stanie rozwiązać problem, czyli musisz umieć też szukać i pytać. I wiem co to jest też takie rozwiązanie. Nie jesteśmy alfą i omegą. Mój tata kiedyś powtarzał, że jeżeli coś człowiek coś zbudował, to inny człowiek to musi naprawić. To akurat bardziej chodziło o takie rzeczy mechaniczne. Zawsze tam silniki, miał całą książkę jak rozłożyć silnik z dużego Fiata na części i potem go połączyć. Do dzisiaj mu to nie wyszło, bo ciągle są jakieś problemy. To ze 20 lat już ten silnik składa, ale ma dokumentację jak to zrobić. Tylko gdzieś tam pewnie czegoś nie doczytał.

Mateusz: To często tak jest, że czytamy instrukcję i potem nagle się okazuje, że pominęliśmy jakieś kluczowe zdanie.

Jakub: Klockami LEGO zapomniałeś obrócić i coś zupełnie innego wyszło.

Mateusz: Dokładnie tak. Kuba, w momencie kiedy rozmawiamy o wejściu w ogóle do branży IT, bardzo często pojawia się temat certyfikatów takich jak chociażby ISTQB. Czy warto zaprzątać sobie takimi certyfikatami głowę? Bo spotkałem się z opiniami, że bez nich jest zdecydowanie trudniej. Z drugiej strony takie certyfikaty w moim osobistym odczuciu to jest tylko i wyłącznie czysta teoria. Jak to jest naprawdę? Jak to jest z Twojej perspektywy?

Jakub: Masz rację, wszystko co powiedziałeś się zgadza. To zależy też od kraju. Bo jeżeli szukasz pracy, no może od początku. Jeżeli chodzi o certyfikat ISTQB, to wydaje mi się, że to była jedna z lepszych rzeczy, które zrobiłem. Ale dlaczego? Bodajże to była moja druga praca i tam była możliwość w tej drugiej pracy zrobienia, w cudzysłowie na koszt firmy, certyfikatu ISTQB, więc musiałeś przeczytać sylabus, czyli taką bazę wiedzy testerów dla testerów i tam są wszystkie definicje zawarte całego procesu wytwórczego oprogramowania, całe to nazewnictwo. Dlaczego tak to się nazywa? Co to znaczy? Czyli te wszystkie definicje, nazewnictwo, ta nomenklatura słownictwa testerskiego tam jest zawarta, żebyś wiedział w ogóle, o czym ci ludzie mówią. Pamiętam, że jak aplikowałam bodajże do drugiej pracy. To ja miałem rozmowę najpierw z działem HR. No i miałem doświadczenie praktyczne, ale nie miałem teoretycznego doświadczenia i pani się mnie pytała podczas tej rozmowy. Wtedy była rozmowa telefoniczna przed pójściem na rozmowę do biura. Czy ja mam doświadczenie z ISTQB? A co Pani ma na myśli? Czy zna Pan definicje: Black box testing, white box testing? Ja znam, znam. A nie miałem zielonego pojęcia o co chodzi. Jaki black box? Black Box kojarzyło z czarną skrzynką na pokładzie samolotu, ale oczywiście będąc prawda pod telefonem i rozmawiając z panią szybko zacząłem szukać Black Box. Aha, i to jest ta część tego słownictwa ISTQB. Więc zacząłem to czytać przed rozmową techniczną, żeby chociaż wiedzieć, czym to się różni. Ktoś mnie zapytał wtedy o jakiś smoke test, a ja bym myślał, że to może jakiś testy znaków dymnych. Więc ta nomenklatura na pewno słownictwa. Nawet nie musisz mieć tego certyfikatu, tym bardziej w Polsce od razu. Wystarczy, że przeczytasz sylabus, który jest dostępny online za darmo, po polsku i po angielsku. Natomiast jeżeli już szukasz pracy w firmach zagranicznych, na pewno niemieckich, to w Niemczech to zwracają uwagę na certyfikaty. Żebyś miał takie potwierdzenie, że znasz chociaż te podstawy to musisz mieć tego foundation level iSTQB to już jest na pewno dodatkowy punkt. Kiedyś też pamiętam jak miałem rozmowę z firmą z Belgii to tam też wymagali - każdy certyfikat, to robiłem ISTQB Certyfikat, potem robiłem certyfikat ITIL, który mi się do niczego tak naprawdę nie przydał, oprócz tego, że trochę tam teorii się dowiedziałem, ale to nie ja się zajmuję podpisywaniem umów i innych rzeczy. Nie jestem architektem w projekcie, ale certyfikat jest także można sobie zawsze odświeżyć wiedzę. ISTQB na pewno - ta wiedza z tego przygotowywania się do tego certyfikatu, na pewno zaprocentowała. Także nie zachęcam od razu do robienia certyfikatu, zachęcam do czytania teorii.

Mateusz: OK, teraz wejdę na taki temat trochę programistyczno - testerski, bo mam tutaj dwa takie pytania, które mnie ciekawią. Z jednej strony chciałem zapytać, bo jako tester automatyzujący sam powiedziałeś, że musisz tworzyć różnego rodzaju aplikacje, które będą w jakiś tam sposób automatyzowały te procesy po to, żeby po prostu wykonywać te testy z odpowiednią częstotliwością i powtarzalnością. Ale żeby napisać taką aplikację, musisz poznać jakieś języki programowania. W językach piszę tester?

Jakub: Ja zaczynałem od Javy. Java mi się wydawała taka ładna i czytelna. Tych języków jest na pewno więcej, zdecydowanie jest więcej. Ale ja zaczynałem od Javy i wtedy, kiedy ja zaczynałem, to tak naprawdę zaczynałem od kursu na YouTubie. Znalazłem kurs jakiegoś pana z hinduskim akcentem. Bardzo dobry kurs QA Shahin. Do dzisiaj pamiętam - QA Shahin.

Mateusz: To jest ego imię, nazwisko czy to jest nazwa kursu?

Jakub: To jest jego kanał na YouTube i on tam różne kursy robił. Natomiast tam rzeczywiście dowiedziałem się w tych dwudziestu kilku filmikach, to jest to automatyzowanie w bardzo podstawowym zakresie. Nagle okazało się, że ja myślałem, że to wystarczy znać trochę ten język programowania, a tu się okazało, że musisz znać coś takiego jak dziedziczenie. Oczywiście na samym początku. Potem musisz coraz głębiej wejść w ten język, bo w zależności od tego, co potrzebujesz, musisz do jednych rzeczy wykorzystać listy, do innych typy tablicowe, jakieś zmienne musisz przechowywać? To nagle z takiego rocket science stało się codziennością, że musiałem się uczyć po prostu programowania, czyli stałem się quasi takim programistą, bo naprawdę musiałem ten język się zagłębić. Bo nie dosyć, że znasz język, to musisz wiedzieć jeszcze czym te testy wykonywać, jak te testy zrobić. No to musisz znać jakąś bibliotekę np. JUnit. No ale jeszcze potrzebujesz jakiegoś jakiejś biblioteki, jakiegoś frameworka, który wejdzie w interakcję z Twoją aplikacją czy to będzie Appium, czy to będzie Selenium. Więc musisz też poznać to jak uruchamiać, jak otwierać. Nagle zaczynasz uczyć się od podstaw, wszystko w jednym pliku piszesz, a potem stwierdzasz, że to nie musi być w jednym pliku, bo widzisz, że są różne takie patterny, czyli takie ścieżki grupowania. Jak trzeba tworzyć takie testy w oparciu o jakieś wzorce projektowe, więc zaczynasz tego typu rzeczy łapać. Zaczynasz rozmawiać w pewnym momencie z programistami trochę jak równy z równym, bo Ty wykorzystujesz coraz więcej rzeczy z ich języka, z ich domeny. No bo musisz. Nagle się okazuje, że zaczynasz pisać testy backendu, testy API. Co było dla Ciebie wcześniej jakimś rocket science? Nagle się okazuje, że kurczę, musisz to robić, żeby sprawdzić czy ta aplikacja działa i też się tego uczyć. I to dużo rzeczy ułatwia, wiele rzeczy to ułatwia. Więc na pewno dla mnie to była Java. Potem. Już się czułem taki bardzo pewny siebie w tej Javie. W międzyczasie, tak jak już wcześniej wspomniałeś, zacząłem być mentorem w Kodilli, żeby tam pomagać osobom, które zaczynają swoją drogę. I też tym osobom polecałem na początku tego QA Shahina, żeby zobaczyli z czym to się je, czyli żeby sobie zaczęli na YouTubie, tam kilkadziesiąt filmików. Niektórzy pewnie nie obejrzeli wszystkich, ale większość pewnie tak, żeby też zobaczyć z czym to się je. No i tam też się musieli uczyć tej Javy dosyć mocno. No ale Java to nie jedyny język po drodze gdzieś tam był Python, po drodze też był JavaScript, teraz aktualnie TypeScript i też te technologie się pozmieniały, bo ja zaczynałem od frameworku typowo samo Selenium, czyli dla mnie było Selenium Webdriver - od tego zaczynałem i dla mnie Selenium to samo Selenium. Jak już umiem Selenium to ja już umiem wszystko, wszystko teraz zautomatyzuje. No ale jak bym chciał na telefonie aplikację to muszę znać Appium i jakbym chciał to coraz lepiej się w tym rozwijać. Są inne frameworki, jest np. Selenite. To też jest taki ciekawy framework. No ale potem się okazało, że po drodze jak już zacząłem w JS pisać testy to musiałem się zintegrować np. pamiętam to był Protractor. Po drodze gdzieś tam się przez chwilę uczyłem Cypress, a teraz jest Playwright, czyli kolejny gdzieś tam etap. Przez te wszystkie lata okazało się, że tych frameworków trzeba było się nauczyć sporo. Dla mnie, dla mnie pewnie ten okres przedpandemiczny też był troszkętakim szokiem, bo musiałem się z tej Javy przerzucić na inne języki, bo tego wymagało środowisko trochę, które się wokół mnie zmieniło. Nagle nie szukają z Javą testera, szukają z JS. Musisz umieć. No to się uczyłem. Z Pythonem też się uczyłem, siedziałem na kursach na Udemy. No i się okazało, że każdy język ma jakieś tam swoje smaczki, które możesz wykorzystać. Do dzisiaj pamiętam jak uczyłem się Flask'a takiej biblioteki, żeby sobie postawić lokalnie, uruchomić jakąś aplikację restową, żeby ją odpytywać np. o coś. Gdy się tego wszystkiego uczyłem sam przy pomocy jakiegoś kursu, to szukałem konkretnych rozwiązań. Szukałem np. jak napisać framework testowy w Pythonie. No i znalazłem na Udemy i uczyłem się jak to zintegrować. Potem co jeszcze, na pewno oprócz frameworków to coraz bardziej taki tester dzisiaj to jest quasi, może bym powiedział DevOps, ale trochę tak jest, że musisz umieć samemu sobie stworzyć np. pipeline testowy CICD, czyli integrację. Continuous Integration z procesem wytwarzania oprogramowania i deploymentu, czyli jak wchodzą nowe wersje, żeby gdzieś tam napisać sobie jakieś testy, które one się uruchamiają za każdym razem. Często musisz to sam zbudować. Miałem już takie sytuacje, że musiałem sobie też stawiać oddzielnie. Miałem dostęp do jakiegoś środowiska, gdzie mogłem sobie zbudować pipeline, czyli takie oddzielne procesy, gdzie te testy się gdzieś tam uruchamiają. Więc musiałem się też tego nauczyć, pisać pliki YAML itd. Także tego jest dużo. Czyli z jednej strony tester musi być koderem, czyli takim programistą, trochę DevOps, czyli specjalistą od budowania infrastruktury, trochę architektem, więc ta wiedza jest co raz bardziej im dalej w las, tym musisz być coraz bardziej samowystarczalny. I to chyba tyle. Ja nie czuje się, że wiem wszystko, bo coraz więcej nie wiem i tego się boję.

Mateusz: To jest ta krzywa uczenia się. Im dalej w las, tym więcej drzew. W takim razie to brzmi tak, jakby tester mógł niedługo zastąpić wszystkie działy po kolei i będzie mógł całą tą aplikację od zera napisać, przetestować, postawić na serwerze?

Jakub: Wiesz co...

Mateusz: Zakładam, że w wersji podstawowej jest to możliwe, aczkolwiek sam pracuję jako programista, więc wiem też, że to są na tyle szerokie działki, że nawet myśląc o tym w kategorii żartu to się wydaje to nie do ogarnięcia dla jednej osoby wszystko.

Jakub: Wydaje mi się, że kiedyś było łatwiej, bo było łatwiej. Jeżeli miałeś stronę tylko w HTML u, miałeś podstawy w JavaScript do obsługi tej strony, to wydelopowanie takiej aplikacji było banalne wręcz. Przy dzisiejszej technologii jaką dysponujemy teraz, musisz mieć oddzielne działy, oddzielnych specjalistów od właśnie: danych - przeliczanie danych, bazy danych, oddzielnych specjalistów od postawienia całej infrastruktury, jak się mają te aplikacje ze sobą komunikować, programistów frontendu, czyli tych w warstwie wizualnej, backendu, czyli tej całej logiki, która się dzieje gdzieś w tle. Także technologia wymusiła to, że zaczęliśmy się specjalizować w swoich działkach bardziej. Podejrzewam, że kiedyś jak byłem dzieckiem, to taki był webmaster, ktoś, kto potrafi robić strony, to było takie wow, że to było Jezu - umie stronę napisać w HTMLu, Pajączka się używało czy innych tam narzędzi i to robiłeś. Dla mnie ta praca to też jest trochę takie połączenie, trochę też pasji, bo bawiłem się jako dziecko z komputerami, instalowałem DOSa na Windowsie gdzieś, psułem te komputery, uczyłem się od innych kolegów na pewno też. Dużo grałem w gry, crackowałem też często gry, bo takie to były czasy. I to też z jednej strony trochę z pasji się robiło i potem ta praca, bo wiesz, że możesz pracować z jednej strony na Macbooku, na jakiejś, nie wiem, super innych komputerach, na które Cię po prostu nie było stać nawet jako dziecko. Dostajesz komputer do pracy, który jest znacznie więcej wart niż to, co masz w domu często czy miałeś w domu. To zmienia, ale to trochę też jest pasja, bo to trzeba lubić. To wypalenie zawodowe, które się gdzieś tam pojawia u niektórych osób to też wydaje mi się, że to z jednej strony czasem się chyba traci ten ogień, który masz w sobie. Żeby ten ogień podsycać, trzeba zmieniać te projekty i się uczyć nowych rzeczy. Dla niektórych to pójście, wydaje mi się, w branżę IT było koniecznością. Dla niektórych to było z pasji, dla niektórych to było właśnie zasmakowanie innego świata. Każdy się innymi pobudkami, że tak powiem, kierował.

Mateusz: Z tym zasmakowaniem innego świata to takie moje luźne przemyślenie, że czasami ten smak może być gorzki, bo jednak pomimo wszystko nadal uważam, że przez ostatnie lata marketing, który pojawił się wokół tego słynnego 15k programista czy teraz nie wiem to już ile tam k jest. W każdym razie wokół tych wszystkich mitów, które narosły wokół samej branży, to jednak ludzie, którzy wchodzą i próbują zostać programistami, często zderzają się ze ścianą po pierwsze wymagań, po drugie praca jest jednak stresująca i wymaga ogromnej wiedzy, którą trzeba posiąść i zdobyć. A z trzeciej strony tak naprawdę to nie jest jednak tak kolorowo, jak się czasami wydawałoby. Ale zmieniając trochę temat wspomniałem o drugim aspekcie związanym z programistami. Często pojawiają się legendy na rynku, że pomiędzy testerami a programistami tej przyjaźni być nie może, ponieważ Wy jako ci, którzy wyszukują te błędy, zrzucają je na nas. Wskazujecie, psujecie naszą pracę jakby. I często się pojawiają takie mity właśnie, że ta praca pomiędzy działem QA - działem testerów a programistami to jest taka trudna praca. Osobiście doświadczenia miałem różne w tej współpracy. Wydaje mi się, że najczęściej były to pozytywne doświadczenia. Z osobami najmniej doświadczonymi się pracowało najtrudniej w moim odczuciu. A ja chciałem zapytać jak tą komunikację, tą pracę pomiędzy naszymi działami usprawnić i jakie masz w ogóle doświadczenia? Czy zawsze się tak kolorowo pracowało z programistami? Czy czasami jednak musiałeś stawiać sprawę na ostrzu noża i eskalować ją gdzieś wyżej, ponieważ ten bezczelny programista nie chciał z Tobą rozmawiać i poprawić błędów mówiąc, że u mnie działa albo jakiś inny frazes.

Jakub: W większości raczej miałem doświadczenia pozytywne. To znaczy zdarzyły się oczywiście sytuacje, że do czego już nie dopuszczam, że ktoś kogo zapytałem, jednego z developerów a'propo tego co tam wydewelopowal, jak to powinno działać według niego, jak on to zrobił, jak on to zaprogramował, no to mi pokazał. Ja trochę się zasugerowałem tym co zrobił, więc nie czytając do końca wymagań przetestowałem to i zamknąłem jego zadanie, po czym po jakimś czasie odezwał się mój szef i pytał się dlaczego zamknąłem to zadanie, przecież to nie działa. A ja mówię przecież ja z nim rozmawiałem i przecież wszystko działało, a ten programista powiedział, że nie, nie rozmawiałeś ze mną. Więc nauczyłem się tego, że warto dokumentować rzeczy, pisać. Często przed rozmową jakimkolwiek, jeżeli coś znajduję i nie jestem pewien, czy to jest rzeczywiście błąd, czy coś. Czy to jest po prostu kwestia tego, że to jest jakiś feature. No to wolę napisać - słuchaj, znalazłem coś takiego. Wydaje mi się, że to może być błąd. Wtedy rozmawiamy, ale już mam jakiś dowód na to, że odezwałem się w tym temacie i już teraz nie mam takich problemów, że ktoś mówi, że ze mną nie rozmawiał. Raczej teraz jest tak, że my jesteśmy całym zespołem, to my dowozimy. To nie jestem tylko ja, że jestem: Hello, Ja jestem testerem i cała odpowiedzialność spoczywa na mnie. Czy ja znajdę wasze błędy czy nie? Raczej jest to.

Mateusz: Nasze błędy.

Jakub: Nasze.

Mateusz: To jest chyba to podejście trochę bycia w Agile, gdzie my jako zespół, a nie my i wy.

Jakub: Tak, my dostarczamy. To zespół jest rozliczany, to zespół musi znaleźć te swoje bottlenecki, czyli te wąskie gardła, gdzie coś nie zadziałało. Więc na pewno jest to praca stresująca. Wielokrotnie miałem już nieprzespane noce, że czegoś nie zrobiłem. I tak wiesz z czarnej strony jak jest czarna strona najmu, to jest też czarna strona pracy testera i pewnie w ogóle branży IT. Jak wiesz, że do klienta trzeba coś wypuścić jutro, wysłać do klienta to to ma działać i po prostu boisz się, że coś się nie uda, że czegoś nie zrobiłeś, że nie zdążyłeś, no stresujesz się, tak? No to jest to naturalny odruch organizmu. Tylko nie dajmy się zwariować, bo jakby zdrowia nie odzyskasz, jak będziesz się ciągle stresował. Łatwo powiedzieć, bo często sobie myślisz, że jednak kurcze to jest Twoja praca, za którą ktoś płaci i chcesz tą pracę na tyle dobrze wykonywać, o ile nie fantastycznie i świetnie, żeby zawsze robić to jak najlepiej. Nie zawsze to się udaje, zawsze coś się musi zadziać. Ostatnimi miesiącami widzę, że to bardzo takie prawdziwe. Rozwiążesz jeden problem, trafiasz na kolejne, Ale już nie mówię o tym jako o problemach, tylko mówię że to są wyzwania. Ktoś kiedyś powiedział, że trzeba zmienićnastawienie do rzeczy, które ciebie spotykają, bo jak powiesz, że masz dużo problemów, no to to ma bardzo negatywną konotacje. Jak powiesz, że masz dużo wyzwań, czyli to jest taki pozytywny, to muszę coś zrobić, żeby to przezwyciężyć. Więc ja bym powiedział, że mam dużo wyzwań. I wydaje mi się, że większość tych wyzwań udaje mi się je pokonać. To jest takie ciekawe, aczkolwiek dużo stresu, dużo siwych włosów się zaczęło pojawiać, bo jednak...

Mateusz: Nie widać.

Jakub: Na brodzie najwięcej widać. Ale na pewno tak jest, że człowiek się po prostu stresuje różnymi rzeczami. Czasem są to tak błahe sprawy, że nie napisałem test planu, czegoś, potem się okazuje, że nikt na to nie zwraca uwagi, bo znajdywać te błędy, albo że ja czegoś wcześniej nie wychwyciłem, co znalazło klient np. że to było tak błahe, tak trywialne, że po prostu widziałeś to setki razy i po prostu przywykłeś do tego, że tak to działa. To nie jest tak. Wracam do samego początku, że musisz być skrupulatny i cały czas starać się podchodzić do tej pracy jak do tak wiesz dokładnie, trzeba byćdokładnym.

Mateusz: Kuba, dużo mówiliśmy o tym, jak się rozwijasz. Już wspomniałeś troszeczkę o tym, że trzeba się rozwijać, że to jest dość istotne i że cały czas to robisz. Natomiast chciałem cię zapytać, jak dzisiaj się to odbywa, bo prawdopodobnie jak 13 lat temu zaczynałeś - ten proces twojego rozwoju był troszeczkę inny. Dzisiaj pewnie on wygląda, wygląda troszeczkę inaczej. Na co zwracasz uwagę w tym momencie, jeśli chodzi o jakość źródeł? Z jakich źródeł korzystasz? Czy są jakieś źródła, które mógłbyś polecić?

Jakub: Jeżeli chodzi o naukę konkretnej rzeczy, przykładowo jak się uczysz obsługiwać jakiś framework to korzystam z dokumentacji i w dokumentacji jest wszystko. Dokumentacja to jest taki podręcznik użytkownika bym powiedział. Tak się uczyłem w Pythonie jak PyTest'a się uczyłem, to korzystałem tylko z dokumentacji. Szukałem po prostu tego, co mnie interesowało, to czego ja potrzebowałem do projektu i to znajdowałem w dokumentacji. To jest jedna rzecz. Pewnie na kursach, jeżeli znalazłem. Przykładowo Dockera, uczyłem się z kursu na Udemy, to tam było... Nie pamiętam już tytułu, ale coś w stylu: From Zero to Hero. Trochę. To był taki kurs, także raczej kursy. Jeżeli już jakieś kursy to raczej wideo. Lubię patrzeć jak ktoś coś zrobi i zobaczyć czy mi wyjdzie tak samo. Próbowałem kiedyś się uczyć z książki Javy - Vademecum programisty. Nie podeszła mi zupełnie ta książka. Wolałem jednak z dokumentacji się uczyć. Jak szukałem czegoś, co szukałem tego w dokumentacji, bo tam są przykłady, które mogę od razu sobie przekopiować, uruchomić i sprawdzić. Aczkolwiek jest jedna książka, którą zawsze wszystkim polecam. To była książka Roberta Martina Czysty kod. Wydaje mi się, że nie przeczytałem całej.

Mateusz: Ok, klasyka.

Jakub: Tak, ale na pewno. Uczyłem się nazywania metod w oparciu o tę książkę. Zawsze gdzieś mam w głowie, że jak piszemy nazwy metod w kodzie, to żeby były one takie czytelne, jeżeli nie wynika to z metody. Nie wiesz co ona zwraca przykładowo, no to masz, że ta metoda zwraca wyniki obliczeń czegoś tam. Tak żebyś wiedział, bo potem zapominasz. Nawet jak sam coś piszesz to po kilku miesiącach patrząc na kod już nie wiesz co ta metoda robi. Masz metodę pobierz url "get url" i teraz nie wiesz jaki ten URL ma być nieco sam. Dla mnie to było jasne, że to jest jakieś tam.

Mateusz: Jasne w tym momencie.

Jakub: Jasne w tym momencie. Tak samo kiedyś miałem taki przykład a'propo właśnie skrupulatności dokumentowania. Pracowałem kiedyś dla jednej firmy, z którą już kończyłem współpracę i chodziło tylko o to, żeby tam pozamykać, udokumentować rzeczy, o które mnie oni poprosili. Także mnie tam powiedzmy szefostwo poprosiło, że: opisz tam co tam krok po kroku, co tam robiłeś i tak dalej, żebyśmy wiedzieli jak ktoś tutaj przyjdzie, żeby wiedział jak tam dalej postępować, żeby miał taki łatwiejszy on boarding, czyli wejście w moje buty dosłownie. No i dobrze. Zajmowaliśmy sięinstalowaniem oprogramowania u klienta po stronie serwera. Trzeba było tam ustawić hasło użytkownika. Minął chyba rok po roku kolega się do mnie odzywa. Pamiętasz jakieś hasło? Już nie pracowałem wtedy. A pamiętasz jakie hasło ustawiliśmy tam u klienta tego i tego? Nie, nikt mnie o to nie pytał, bo nigdzie tego nie zapisałem. No bo to było takie, wiesz, oczywista oczywistość na tamten moment. Obaj pewni wiedzieliśmy, że było takie, a nie inne hasło i okazało się, że to doprowadziło do jakichś większych problemów. Trzeba było to wszystko zatrzymać, od nowa postawić. Więc tak to było. Ale jeśli chodzi o naukę, to na pewno ta książka Czysty kod, bardzo dobra, mimo że nie przeczytałem całej, czytałem wybiórczo, ale to co potrzebowałem to na pewno mi pomogło w mojej pracy. Dokumentacja tego czego się chcesz uczyć, czy to będzie ten Selenium czy konkretny język. Każdy język ma swoją dokumentację, na której możesz się po prostu uczyć, przeczytać dokumentację i na pewno masz większe pojęcie o tym języku i wykorzystać, wykorzystywanie tych przykładów z dokumentacji na pewno pomaga zrozumieć, jak działa język, framework, biblioteka. To tak bym się uczył. No i też Udemy, bo jest dużo rzeczy. Często nie wiesz które. Więc szukam tych najwyżej ocenianych. Jeżeli szukam konkretnej odpowiedzi na konkretne pytanie. No i ostatnimi czasy też na pewno dopytuje Chata GPT, aczkolwiek wiele razy się zdarzyło. Raczej używam, bo jak biorę coś napiszę to wrzucam wtedy to, co napisałem, żeby ewentualnie sprawdził czy tam nie ma jakichś tam powtórzeń, czy trochę może tego wyczyścił ten kod. Często to pomaga. Miałem taką sytuację, że napisałem jakiś kod i wszędzie mam powiedzmy https, https, https. Tak, protokół https w wielu miejscach i w jednym, czego nie zauważyłem, miałem http i nie działał mi kod - wyrzucał jakiś błąd, który w ogóle nie mówił, że to jest to. Wrzuciłem ten kod do czata. On powiedział, wiesz co w linijce 40 masz http to może prowadzić do jakiś błędów. No to zmieniłem i zaczęło działać. Więc do takiej analizy kodu na pewno też mi się przydał. Parę rozwiązań pewnie też mi pomógł troszkę zrobić łatwiej. Zresztą dużo takich przykładów mam. Kolega np. ustawiał Azure, przygotowywał, konfigurował i coś nie działało, jakaś rzecz? Nie pamiętam już co. I on kurcze mówi przecież wszystko zrobiłem. Wszystko to tak jak przygotowujesz samolot do lotu, Wszystko zrobiłeś, wszystkie procedury, no przecież powinno działać. I napisał, że nie działa mu to, a on mu tam napisał listę chyba siedmiu punktów i on przeczytał tą listę i patrząc na jeden z punktów mówi Jezu, zapomniałem o tym. Takiej rzeczy którą on robił setki razy. Po prostu zapomniał to zrobić, bo to było tak naturalne.

Mateusz: Chat GPT staje się taką żółtą kaczuszką współcześnie.

Jakub: Tak, ale ja bym nie powiedział, że Chat GPT jest alfą i omegą.

Mateusz: Nie jest, on popełnia też sporo błędów. Bazuje jednak na wiedzy, którą dostał, którą miał podaną. Nie zawsze ona może być dobra. No dobrze, Kuba, właściwie kończymy powoli naszą rozmowę. Chciałem cię zapytać, bo jesteś człowiekiem wielu pasji. Człowiekiem, dla którego rozwój jest ważny z tego co widzę i z tego, co wiem. Bardzo pozytywnyn przy okazji, bo się też prywatnie znamy i wiem, że jeszcze nie widziałem Cię smutnego czy złego. Zawsze uśmiechnięty. Powiedz mi czy jest jakaś książka, która zrobiła na Tobie ogromne wrażenie, która wywarła jakiś wpływ na Ciebie? To nie musi być książka o samorozwoju. To może być totalnie beletrystyka, coś, co zmieniło Twój sposób patrzenia na życie, na świat.

Jakub: Ostatnimi czasy pewnie była to książka Davida Gogginsa - Nic mnie nie złamie. On w tej książce pisze o tym, że my rzeczywiście przyzwyczailiśmy się do takiego komfortu. Po przeczytaniu tej książki jakieś tam kilka tygodni temu obudziłem się bodajże o czwartej rano. Obudziłem się, tak leżałem w łóżku i rozmyślałem co by tu porobić. Może sobie poczytam, może wypiję kawę, poprzeglądam coś na telefonie. Stwierdziłem, że założę buty i pójdę pobiegać, bo on akurat jest znany z tego, że zawsze gdzieś staram się przełamywać ten komfort i robić rzeczy, których nie lubi robić. Mówi się czasem, że jak pobiegasz rano, to nic już gorszego w ciągu dnia nie spotka. Więc to też daje takie złamanie tego komfortu życia, bo mamy bardzo komfortowe warunki. Nie ukrywajmy. Także trochę pchanie siebie do robienia rzeczy, których nie lubimy. Stąd pewnie poszedłem w tym roku pierwszy raz morsować i doświadczyć bólu dosłownie fizycznego podczas kąpieli w środku zimy. To na pewno też zmienia podejście, uspokajasz się wtedy bardziej. Też my potrzebujemy w dzisiejszym świecie trochę takiego spokoju. Spokój jest fajny, kiedy sobie dajesz czasem wycisk, więc na pewno ta książka jest świetna pod tym względem. Na pewno bym polecił, jeżeli chcesz przeczytać historię. Trochę też from zero to hero, ale poprzez ból i cierpienie dosłownie, bo ten facet sobie ciągle zadaje ból, żeby być silniejszym, bardziej wytrzymałym, to wydaje mi się, że w takim życiu, potem takim zawodowym jesteś bardziej odporny psychicznie. Bo tak jak powiedziałeś wcześniej, że ta praca jest stresująca, to nie jest tak, że my sobie przychodzimy i klikamy, tylko to też to, co my dostarczamy, wpływa też na to, co klient otrzymuje i klient może być szczęśliwy bądź nie i prędzej czy później do nas ta karma wróci. Więc albo będzie dobra, albo zła. Więc też trzeba umieć sobie radzić z tym stresem. Wcześniej się bardziej przejmowałem niż teraz, tzn. krytyką, feedbackiem, bo po burzy zawsze przychodzi słońce, więc nawet jeżeli są takie cięższe dni projektowe, to na pewno prędzej czy później w końcu będzie lepiej. Szczególnie jak widzisz, że wszyscy np. z Twojego projektu odchodzą, bo nie dają rady, a Ty siedzisz i się zastanawiasz: Kurczę, przecież wszystko płonie wokół Ciebie, Się śmieje - jest taki fajny mem z takim psem wszystko płonie, a on pije kawę. Ja chyba czasem tak już jestem na tym etapie, że wiesz, trafi się wszystko, no wiesz? Tu nie działa, tam nie działa coś. A wszędzie jest chaos. Na luzie, no robię to, co mam robić. Wykonuje swoją pracę, a to, że wszystko się wali i trzęsie. Jest totalny armagedon. Ale to kiedyś się uspokoi.

Mateusz: Kiedyś się uspokoi. Kuba, ślicznie dziękuję za dzisiejszą rozmowę. Było mi bardzo miło i mam nadzieję, że nasi słuchacze wyciągną z tego bardzo dużo wartościowych rzeczy, bo powiedziałeś wiele fascynujących rzeczy, które do mnie trafiły, o których nie miałem zielonego pojęcia. Powiem szczerze, w niektórych przypadkach i wielu miejscach mnie zaskoczyłeś, więc też się cieszę. A wydawało mi się, że o testowaniu trochę wiem. Więc ślicznie dziękuję za rozmowę i do zobaczenia gdzieś tam w świecie, w przyszłości.

Jakub: Do zobaczenia. Cześć!