To jest 179. odcinek podcastu Porozmawiajmy o IT, w którym z moimi gośćmi rozmawiam o ścieżkach kariery w testingu oprogramowania. Sponsorem tego odcinka jest Capgemini Polska. Przypominam, że w poprzednim odcinku rozmawiałem o roli urządzeń UTM w bezpieczeństwie cyfrowym. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/179. 

 

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. Od niedawna można wystawiać oceny podcastom w Spotify. Będzie mi bardzo miło, jeśli w ten sposób odwdzięczysz się za treści, które dla Ciebie tworzę. Dziękuję.

Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. Wspierając mnie przez Patronite, dzieląc się tym odcinkiem w swoich kręgach lub feedbackiem na jego temat ze mną, pomagasz w realizacji tej misji. Ja natomiast bardzo dziękuję moim obecnym patronom. A teraz życzę Ci już miłego słuchania!

 

Odpalamy!

 

Cześć!

Dzisiaj moimi gośćmi są Rafał Tramowski, Managing Test Consultant, związany z testingiem od 12 lat. Aktualnie w Capgemini Polska skupia się na działaniach rekrutacyjnych i brandingowych związanych z poszerzeniem krakowskiego oddziału Financial Services. Prywatnie fan piłki nożnej, dobrych książek i podróży. Oraz Paweł Banaszczyk, Senior Test Consultant, w testingu od prawie dwóch dekad, od ponad 10 w rolach menedżersko-liderskich. W Capgemini odpowiedzialny za prowadzenie projektów w zespołach rozproszonych, tworzenie strategii testowych, coaching, lider community testerskiego, dbający o rozwój pracownika i usprawnienia ogólnie pojętych procesów biznesowych. W wolnym czasie fotografuje i żegluje.

Rafał, Paweł, bardzo mi miło gościć Was w podcaście.

 

Rafał Tramowski: Cześć!

 

Paweł Banaszczyk: Cześć!

 

Myślę, że z tego przedstawienia jasno wynika, że panowie zawodowo zajmują się testowaniem oprogramowania. Nasza rozmowa będzie związana ze ścieżkami kariery w tej branży. Opowiemy szerzej, jakie są możliwości, oraz zapoznamy się z kilkoma projektami, w których Rafał i Paweł uczestniczyli, aby zobaczyć, jak w praktyce takie ścieżki kariery związane z testowaniem oprogramowania mogą przebiegać.

Ale zanim do tego przejdziemy, to w moim podcaście mam taką tradycję, pytam gości, czy słuchają podcastów, jeśli tak, to jakich najczęściej, więc Rafał, Paweł, jak to u Was wygląda?

 

RT: Ja muszę z ręką na sercu powiedzieć, że nie słucham, bo nie mam na to ostatnio czasu ze względu na prywatne obowiązki.

 

PB: Ja podcastów słucham, ale niezwiązanych stricte z testowaniem, bardziej z rozwojem zawodowym. Kręcę się gdzieś pomiędzy Miłoszem Brzezińskim czy Simonem Sinekiem, sięgam też po ich publikacje.

 

To są bardzo fajne rekomendacje, dzięki za to.

Chciałbym najpierw dowiedzieć się, jak wyglądał ten rozwój kariery związanej z testowaniem aplikacji w Waszym przypadku. Myślę, że to nam pozwoli później lepiej zrozumieć, jakie są możliwości. Dlaczego postawiliście właśnie na ten obszar IT?

 

PB: Zacząłem pracę jako tester ok. 20 lat temu od bardzo podstawowej pracy, polegającej na klikaniu po ekranie i szukaniu czerwonych komunikatów z błędami. Dlaczego ten kierunek? Już wtedy IT i komputeryzacja były bardzo przyszłościowymi kierunkami dla rozwoju młodego człowieka i dawały możliwość ciągłej nauki i rozwoju w coraz to ciekawszych technologiach. I już tak zostałem.

 

RT: U mnie to wyglądało tak, że jestem chyba z natury osobą, która lubi szukać takiego rozwiązania, które jest idealne i działające tak, jak byśmy sobie tego życzyli. I sytuacja środowiskowa dookoła mnie dała mi taką możliwość ok. 12–13 lat temu, gdy byłem zaangażowany w testy końcowe użytkowników, pracując na infolinii domu maklerskiego. I tak mi się to spodobało i przypasowało do mojego życiowego podejścia do wyszukiwania czegoś, co nie działa, i starania się zrobić to tak, żeby było działające zgodnie z moimi oczekiwaniami, że zostałem już w tym i cały czas w tym kierunku się rozwijałem. I w tym momencie jestem tu, gdzie jestem.

 

Mówimy dzisiaj o ścieżkach związanych z testowaniem oprogramowania, ale wiadomo, że samo testowanie, jak i całe IT, bardzo się zmienia, powstają jakieś specjalizacje, stąd moje pytanie związane z tym, czy domena, w której ten produkt działa, rodzaj firmy, to, jaki jest charakter aplikacji, czy ona jest webowa, mobilna, desktopowa itd. – czy to wszystko w jakiś sposób determinuje ścieżkę kariery testera oprogramowania?

Bo tutaj można się doszukiwać takiego uzasadnienia, że faktycznie, spędzając czas w danej domenie, w danym rodzaju aplikacji, stajemy się specjalistami w tym kierunku. Czy też może jest wręcz przeciwnie? Może te umiejętności testerskie są uniwersalne i niezależnie od tego, jaka aplikacja, jaka firma, jaka domena, tam zawsze te ścieżki kariery mogą wyglądać podobnie? Jestem ciekawy Waszego zdania.

 

PB: Na pewno rodzaj aplikacji bardzo się zmieniły. Ja zaczynałem pracę na aplikacjach desktopowych, które musiały być ręcznie instalowane na każdym komputerze. Obecnie takie aplikacje są bardzo rzadko spotykane. Zazwyczaj są to aplikacje webowe, do których możemy dostać się z każdego miejsca podłączonego do internetu. 

Równocześnie mamy do tego jakieś aplikacje mobilne, które umożliwiają nam korzystanie z owych aplikacji poprzez telefony, smartfony, tablety itd. To wszystko decyduje o tym, że tester musi być multidyscyplinarny, musi znać się i na aplikacjach webowych, i na mobilnych, do tego backend, znajomość serwerów, na tym, jak te wiadomości są przesyłane itd. Ja to nazywam tester ninja, który musi znać bardzo wiele obszarów, żeby zrozumieć, jak to działa, jak to można zepsuć i jak to przetestować.

 

RT: Ja ze swojej strony mogę powiedzieć, że odpowiedź na to pytanie jest zależna, nie mniej wskazująca na to, że tak, w pewien sposób domena, firma, produkt lub rodzaj aplikacji wpływają w pewien sposób na ścieżkę kariery i potem na ew. wybór kolejnych kroków. Bo tak, jak Paweł powiedział, z jednej strony trzeba być takim ninja, a z drugiej strony szerokość i rozpiętość technologiczna, z którą aktualnie mamy do czynienia, jest tak ogromna, że mimo bycia w jednej domenie nawet przez całe swoje życie możemy skupiać się tylko i wyłącznie na jednym obszarze, a co za tym idzie, ten jeden obszar może być również wykorzystywany w innych domenach, aplikacjach i produktach.

Więc z jednej strony na pewno na domena, produkt czy aplikacja determinują ścieżkę rozwoju kariery z naturalnych powodów, po prostu pracujemy w jednej technologii bądź w jednym obszarze technologicznym, ale też nie jest do końca powiedziane, że zawęża tylko i wyłącznie potem kolejne kroki kariery do danej domeny i danego obszaru.

 

Ja ze swojej strony mogę powiedzieć, że odpowiedź na to pytanie jest zależna, nie mniej wskazująca na to, że tak, w pewien sposób domena, firma, produkt lub rodzaj aplikacji wpływają w pewien sposób na ścieżkę kariery i potem na ew. wybór kolejnych kroków. Bo tak, jak Paweł powiedział, z jednej strony trzeba być takim ninja, a z drugiej strony szerokość i rozpiętość technologiczna, z którą aktualnie mamy do czynienia, jest tak ogromna, że mimo bycia w jednej domenie nawet przez całe swoje życie możemy skupiać się tylko i wyłącznie na jednym obszarze, a co za tym idzie, ten jeden obszar może być również wykorzystywany w innych domenach, aplikacjach i produktach.

 

Mówimy o technologiach, o produkcie, o typach firm, a teraz chciałbym Was zapytać o nieco bardziej jaskrawy podział ról testerskich na testerów manualnych i automatycznych. Oczywiście przyjęło się, że jest to najczęściej stosowany podział, ale doskonale wiemy, że to nie wyczerpuje tematu, ponieważ w obecnych firmach ról związanych z testowaniem jest znacznie więcej.

Skąd to wynika, że bardzo często mówi się o tym podziale manualny / automatyczny, ale może pomija się trochę te inne, równie istotne role?

 

RT: Ja ze swojej strony mogę powiedzieć, jak to wygląda, bazując na ostatnich trendach na całym rynku IT, bo owszem, podział na manuala i automatyka jest z nami już od bardzo dawna, ale tak jak powiedziałeś, sam automatyk może być postrzegany przez różne pryzmaty, poczynając od technologii języka, w którym ta automatyzacja następuje, ale też właśnie to, o czym powiedziałem na początku, czyli trendy, które są na rynku i pójście wielu organizacji, firm w kierunku zespołów Scrumowych, Agile’owych też rzutuje na profile testerskie.

I według ostatnich badań, z którymi miałem okazję się zapoznać, wynika, że w tym momencie kierunek profilu testerskiego będzie oscylował w okolicach DevTestOpsa, który będzie posiadał zarówno dobrą wiedzę techniczną i domenową, jeśli chodzi o testy, czyli taką związaną stricte z obszarem testów oprogramowania, jak i również wiedzę domenową, bo gdzieś ten tester w tych zespołach Scrumowych jest postrzegany jako najlepszy kandydat do bycia pośrodku między częścią IT deweloperską a tym produktem końcowym, z którym klient ostatecznie działa na co dzień.

Więc myślę, że duży wpływ na ten podział ról, testerskich (przynajmniej z mojej perspektywy) ma to, jakie są aktualnie trendy na rynku IT, w jaki sposób są kształtowane i w jaki sposób są stawiane wymagania wobec firm, które się zajmują szeroko pojętym IT.

 

PB: Ja mogę też dodać, że coraz bardziej wymagamy od testerów takiej interdyscyplinarności. Czyli po części to, co Rafał powiedział o tym Test DevOpsie, czyli taki człowiek, który nie tylko nam przetestuje, ale sprawdzi nam środowisko, zdeployuje coś i jeszcze odpali nam skrypty, które tam z jakiegoś powodu się nie odpaliły o poranku, a na koniec sprintu usiądzie przed klientem i to wszystko po ludzku pokaże.

To naprawdę nie jest powszechne wśród deweloperów. Testerzy rzeczywiście dość fajnie się w tym odnajdują i jako dowód mogę przekazać taką informację, że ostatnio do mojego community zgłosiła się dziewczyna, która właśnie walczyła z tym stresem, z tym problemem, bo zespół ją wybrał, żeby ona pokazała przed klientem coś, i ona nie była na to przygotowana i musiała się wewnętrznie z tym zmierzyć i będzie u nas na community o tym opowiadała, ale to jest temat, który pojawia się bardzo często w jakichś różnych korytarzowych rozmowach, że ten tester jest łącznikiem pomiędzy IT i biznesem i potrafi zrozumieć, co chce biznes i co robi IT, i to ładnie wszystko opakować, i jeszcze sobie znaleźć taki sposób, żeby to wszystko przetestować w akuratny sposób.

Natomiast w samych testach też oczywiście jest dużo nisz, nie możemy zrobić sobie tylko podziału na manualne i automatyczne. Mamy testerów, którzy zajmują się testami wydajnościowymi, security, testy UI, automatyzacja w jednym czy drugim frameworku, to jest co chwilę coś nowego, co chwilę inny framework projektowy i ten tester cały czas się z tym mierzy i dzięki temu, że ma taki [nz 12:45 ?] odkrywczy, że te produkty potrafią być wspaniale testowane.

 

Myślę sobie, że dokładają się jeszcze do tego różne role związane z zarządzaniem takimi zespołami. To jest kolejny zestaw kompetencji. I tak, jak, Paweł, opowiadałeś o tym, że coraz częściej wymaga się od testerów, żeby nosili różne kapelusze, żeby sprawowali różne role, to jest to faktycznie trudne zadanie pod względem rekrutacyjnym.

I tak sobie myślę, że to pytanie chciałbym skierować do Rafała, który powiedział na początku, że chyba od zawsze wiedział, że rola testera oprogramowania to jego cel i misja w życiu. Jakie predyspozycje powinna mieć osoba aplikująca na takie role? Czy w ogóle takie predyspozycje są weryfikowane, wymagane? Czy można się tego wszystkiego po prostu nauczyć?

 

RT: Nie ma jednego szablonu predyspozycji do ról testerskich, bo tak jak przed chwilą powiedzieliśmy, tych ról testerskich jest coraz więcej, zakładam, że one jeszcze będą się w przyszłości poszerzać. Nie mniej, z mojego doświadczenia, zarówno takiego rekrutacyjnego, jak i własnego, pracując w roli testera, uważam, że jaki podstawowy zestaw umiejętności i takiego podejścia do pracy w IT jest jak najbardziej mile widziany, i to on w większości przypadków determinuje, czy ktoś zostaje zatrudniony na to stanowisko, czy nie.

W szczególności w przypadkach, kiedy są to osoby, które dopiero np. kończą studia i chcą rozpocząć pracę w IT albo osoby, które chcą się przebranżowić. Na pewno jest to umiejętność krytycznego myślenia, która pozwala testerowi podejść do swojej pracy rzetelnie. Na pewno też cierpliwość, bo praca testera to nie jest w większości przypadków praca, która daje możliwość bezproblemowego przejścia przez większość rzeczy, które się wykonuje w ciągu standardowego dnia pracy i cierpliwość jest tutaj wielką cnotą. Na pewno umiejętność logicznego myślenia. Ale nie tylko to.

Uważam tak, jak Paweł przed chwilą zaznaczył, że obecnie tester to też taki frontman, jeżeli chodzi o dany projekt i takie predyspozycje typowo soft skillowe są też bardzo ważne u testera. Musi to być na pewno osoba, która potrafi pracować w zespole, nie może to być indywidualista, który nie chce współpracować z innymi. Musi umieć porozumieć się ze stroną techniczną projektu, jak i biznesem. 

Więc tak na szybko odpowiadając na to pytanie, to taki podstawowy zespół umiejętności i cech niezwiązanych stricte z technicznym aspektem tej roli. Oczywiście możemy tutaj dodawać dosyć często wymieniane cechy, jak np. bycie skupionym na detalach i jeszcze parę innych rzeczy, ale takie logiczne myślenie, cierpliwość, krytyczna postawa wobec zastanych warunków plus umiejętności miękkie, które pozwalają na dobrą komunikację, umiejętność prezentowania prac swoich, jak i zespołu są na pewno czymś, co można uznać za taki podstawowy zestaw cech, które tester powinien posiadać. 

I nie wszystkich tych cech moim zdaniem da się nauczyć. Cierpliwość czy logiczne myślenie można w pewien sposób wypracować, ale uważam, że krytyczne spojrzenie na zastaną rzeczywistość nie jest możliwe do wypracowania. Pewne rzeczy chyba naturalnie w pewien sposób można przygotować i lepiej pozycjonować w procesie rekrutacyjnym.

 

Uważam tak, jak Paweł przed chwilą zaznaczył, że obecnie tester to też taki frontman, jeżeli chodzi o dany projekt i takie predyspozycje typowo soft skillowe są też bardzo ważne u testera. Musi to być na pewno osoba, która potrafi pracować w zespole, nie może to być indywidualista, który nie chce współpracować z innymi. Musi umieć porozumieć się ze stroną techniczną projektu, jak i biznesem. 

 

 

Gdy opowiadałeś o umiejętnościach miękkich, to przyszło mi do głowy słowo empatia, które pewnie też przydaje się, żeby zrozumieć stan zastany, niekoniecznie starać się wszystko krytykować od pierwszego dnia.

 

RT: Tak, to jest racja. I powiem szczerze, że to jest coś, czego faktycznie można się nauczyć. Wiem, że ja, bazując na swojej ścieżce kariery i początkach w pracy jako tester, miałem utopijne podejście do tego, krytykowałem w taki sposób, by dążyć do tego, aby coś działało idealnie, ale lata doświadczenia nauczyły mnie, że stan idealny nie jest możliwy do osiągnięcia. Zarówno w pracy, w roli testera, jak i w życiu. I pewne rzeczy trzeba potraktować właśnie z empatią, mieć też pewien bufor dystansu do zastanego świata, poziomu jakości i w jakiś sposób działać tak, aby ta praca dawała jak najwięcej jakości finalnemu produktowi oraz jak najwięcej radości osobie, która ją wykonuje.

 

Zabrzmiało troszkę filozoficznie. Nie twierdzę, że to źle, ale niestety muszę nas trochę sprowadzić na ziemię kolejnym pytaniem. Do tej pory mówiliśmy o różnych możliwościach i mnogości ról, które możemy sobie wybierać, projektując ścieżkę kariery, natomiast wiadomo, że zawsze jest jakaś specyfika firmy, projektu, gdzie określone role działają tak, a nie inaczej, ścieżki kariery wyglądają w określony sposób. 

Więc chciałbym Was teraz zapytać konkretnie o Capgemini, o profile testerskie, o ścieżki kariery, żeby lepiej zrozumieć, jakie możliwości czekają na przyszłych kandydatów.

 

PB: Ogólnie mamy podział na dwie ścieżki kariery. Jedna to jest tester automatyzujący, druga to jest tester manualny. I w obu przypadkach zaczynamy od takich podstaw, gdzie osoba z zerowym doświadczeniem, ale z potencjałem, z energią i chęcią rozwijania się trafia pod opiekę troszkę bardziej doświadczonych osób, niekoniecznie z wieloletnim doświadczeniem, ale osób, które siedzą już trochę dłużej w projekcie, rozumieją zagadnienia z danego projektu i które mogą wprowadzić młodszego kolegę w narzędzia czy procesy. 

Te procesy działają z grubsza tak samo lub podobnie, można zastosować w wielu projektach podobne rozwiązania. Wiadomo – specyfika będzie różna. I z czasem taki Junior Tester ma coraz bardziej samodzielne i bardziej złożone zadania, rozwija się, ponosi większą odpowiedzialność, np. za jakiś obszar w danej funkcjonalności w konkretnym projekcie. Czasem jest to pół roku, czasami rok, czasami dwa, ma na tyle szeroką wiedzę biznesową, że jest w stanie już na bardzo wczesnym etapie pewne rzeczy wyłapać ze współpracy np. z biznes analitykiem czy z deweloperem, dlaczego dane rozwiązanie będzie nam działało lub nie. 

Jeżeli mówimy o ścieżce manualnej, to następnym naturalnym krokiem jest, że gdy przychodzi kolejna osoba junioralna, ten poprzedni junior jest już odpowiedzialny za nią i rozwija się nie tylko w kwestii domenowej wiedzy biznesowej, ale także rozwija się lidersko – ma jednego, dwóch testerów i tworzy z nimi zespół, rozdziela zadania i koordynuje je, a zadaniami analityczno-egzekucyjnymi zajmują się młodsi koledzy i koleżanki. I to jest ta ścieżka manualna. 

Później ta skala rośnie. Lider, koordynator, menedżer, również skala projektów czy cały program, który test koordynator, test menedżer może rozwinąć. I mamy takie projekty, które rosną jak na drożdżach. To są bardzo często współprace z klientami na przestrzeni wielu lat i potrzeba kogoś, kto zaczynał od zera do bohatera i wie wszystko, co powinien, ew. wie, kto wie – bo oczywiście nie możemy też wymagać, żeby wiedział wszystko.

Jeżeli chodzi o ścieżkę automatyczną, to wygląda podobnie, tzn. zaczynamy od prostych zadań automatycznych, dopisywanie skryptów automatycznych do jakiegoś istniejącego frameworka, z czasem to się może rozwinąć do dobudowywania jakiejś funkcjonalności w tym frameworku. Teraz np. mam projekt, w którym stawialiśmy wszystko od zera, mam człowieka, który zupełnie samodzielnie, będąc nowym w projekcie, ale już z paroletnim doświadczeniem w Capie, wszystko ładnie zbudował od zera. I to jest, działa i jest na tyle uniwersalnie zbudowane, że klient może to za chwilę zastosować też w innych obszarach swojej działalności.

I później dla takiej technicznej osoby to jest już bardziej kierunek nie menedżerski, ale to jest taki architekt, który w przypadkach budowania ofert dla klientów jest proszony na konsultacje, jaki framework zastosować, ilu potrzebujemy ludzi, jak powinien wyglądać setup środowisk itd. I to jest ta ścieżka techniczna dla automatyzatora. 

 

RT: Jedyne, co bym dodał, to że w Capgemini mamy też możliwość przeskakiwania między tymi ścieżkami. Czyli jeżeli ktoś zaczyna jako manualny tester i ma dużą chęć do rozwoju i do uczenia się, i stwierdzi, że ten kierunek to jest to, co chciałby robić w przyszłości, to nic go nie blokuje przed tym, żeby przejść na ścieżkę automatyczną. Tak samo osoba z dużym doświadczeniem technicznym, która chciałaby być bardziej zarządzającym konsultantem testowania, osobą, która strategicznie decyduje o pewnych projektach, programach, ogólnie działalności testerskiej, również może przenieść tę nogę jedną i drugą przez miedzę i zostać menedżerem testów z backgroundem technicznym.

 

Chciałbym jeszcze zapytać o jedną rzecz, jeśli chodzi o ścieżki kariery w tym duchu podziału na testera manualnego i automatyzującego, bo automatyzacja już od kilku lat jest takim generalnym trendem w IT, rośnie liczba różnych narzędzi, puli do testowania. Czy w takim świecie, w którym chcemy jak najwięcej automatyzować, ta rola testera manualnego, która kiedyś była uważana za jedną z łatwiejszych furtek do IT, nadal jest atrakcyjna z punktu widzenia rozwoju? Nadal jest potrzebna w firmach? Jak Wy to widzicie?

 

RT: Ja uważam, że tak, jest potrzebna. I że mimo tego, że trendy i rozwój testowania idzie w kierunku automatyzacji praktycznie wszystkiego, co możliwe, to jednak tester manualny jest nadal profilem, który jest potrzebny i jeszcze na pewno przez parę dobrych lat będzie. 

Mówię to, bo trzeba brać pod uwagę, że chęć automatyzowania wszystkiego to jedno, a możliwość zautomatyzowania wszystkiego to jest druga rzecz. I często organizacje jako firmy nie są też gotowe do tego, żeby zautomatyzować całość swoich projektów, w związku z tym potrzebują profili manualnych, które będą wykonywały testy też manualnie – to jedna rzecz. A druga rzecz, że osoby, które zaczynają karierę jako testerzy manualni, mogą później zostać testerami automatyzującymi albo pójść w ścieżkę zarządzającą i być osobami planującymi strategicznie procesy testowe w projektach.

Czy jest to jedna z łatwiejszych furtek do IT? Aktualnie nie powiedziałbym. Wydaje mi się, że wymagania rynku są tak duże w tym momencie jeżeli chodzi o profile testerskie, że nie nazwałbym tego jedną z łatwiejszych furtek do wejścia do świata IT. Nie jest ona wg mnie najtrudniejsza, niemniej jednak bazując na moim doświadczeniu, nie uważam, żeby to była łatka, którą nadał można by przypiąć do profili testerskich w świecie IT.

 

Mówię to, bo trzeba brać pod uwagę, że chęć automatyzowania wszystkiego to jedno, a możliwość zautomatyzowania wszystkiego to jest druga rzecz. I często organizacje jako firmy nie są też gotowe do tego, żeby zautomatyzować całość swoich projektów, w związku z tym potrzebują profili manualnych, które będą wykonywały testy też manualnie – to jedna rzecz. A druga rzecz, że osoby, które zaczynają karierę jako testerzy manualni, mogą później zostać testerami automatyzującymi albo pójść w ścieżkę zarządzającą i być osobami planującymi strategicznie procesy testowe w projektach.

 

 

Myślę sobie, że podjęliśmy się bardzo ambitnego zadania powiedzenia o ścieżkach kariery w testowaniu oprogramowania, pewnie nie jest to generalnie możliwe, bo tych ścieżek jest tyle, co projektów i firm, bo wiadomo – obszar odpowiedzialności testera to jakość. A to może być bardzo szerokie pojęcie, złożone z wielu różnych elementów. 

Chciałbym więc skupić się może na jakimś jednym projekcie, który by pokazał mnogość tych stref wpływu testera oprogramowania, gdzie one są najbardziej widoczne, na co wpływają. Wiem, że Ty, Paweł, uczestniczyłeś w takim projekcie, gdzie brałeś już w nim udział na etapie oferowania klientowi – co, muszę przyznać, nie jest dość oczywiste w przypadku testera oprogramowania. Opowiesz o tym troszkę więcej?

 

PB: Oczywiście. Tak, jak powiedziałeś, na pewnym etapie pracy zostałem poproszony o przygotowanie oferty do tworzonego programu. To jest program, który miał być przez naszą firmę Capgemini dostarczany dla klienta i m.in. testing też miał tam być częścią tego rozwiązania. 

Klient już sobie wstępnie ułożył, jak to ma wyglądać, że potrzebuje czterech testerów, usiadłem nad dokumentacją, która była bardzo wysokiego poziomu, bo były to prezentacje biznesowo-sprzedażowe, i na jej podstawie próbowałem coś ułożyć. Zobaczyłem pewne informacje o technologiach, w których nie miałem doświadczenia, ale mamy bardzo duży dział, 500 osób, więc znalazłem bez problemu osobę, która pomogła mi w konsultacjach (pozdrawiam Konrada), i po paru takich sesjach z nim i z klientem, przedstawiłem ofertę na to, jak ja to widzę. 

I ta oferta była o tyle ciekawa, że tam rzeczywiście pokrywaliśmy testy na wielu poziomach, bo na poziomie backendowym, czyli potrzebowałem testerów, którzy będą mi testować API, potrzebowałem testerów, którzy będą mi testować bazę danych, którzy będą mi testować frontend do aplikacji zakupiony przez klienta i do tego jeszcze 2–3 Test Leadów, takich, którzy będą ogarniać te poszczególne zespoły. Czyli z pierwotnej liczby 4 osób, zaproponowałem 10, których tak naprawdę wg moich wyliczeń potrzebowałem, klient pozadawał parę pytań, przemyślał i powiedział: Okej. I z automatu oczywiście, Paweł, będziesz tego wszystkiego pilnował. Oczywiście się zgodziłem, bo skoro wymyśliłem, to teraz muszę dowieźć. I tak to teraz wygląda. 

To jest też ciekawa historia od tej strony, że połowa tych ludzi to były tzw. A1, czyli osoby zupełnie junioralne, zatrudnione u nas z bardzo minimalnym doświadczeniem. Wykorzystaliśmy jeszcze chwilę, zanim rozpoczęliśmy projekt i zrobiliśmy sobie taki wewnętrzny skill up, czyli podnoszenie kwalifikacji. To było połączenie uczenia się z dostępnych materiałów online na różnych platformach szkoleniowych i szkoleń prowadzonych wewnątrz organizacji przez naszych kolegów, którzy regularnie dostarczają w dziale testów szkolenia. I ci testerzy zostali rozdysponowani po zespołach deweloperskich jako część tzw. zespołów Scrumowych i normalnie, day to day funkcjonują jako osoby w Scrumie i mają przypisywane normalne zadania jako testerzy Scrumowi.

I patrząc z perspektywy czasu, to jest kosmos, co oni przez ostatnie X miesięcy osiągnęli, czego się nauczyli od zera. Pięknie widać ich zaangażowanie, i to, jak się stają ekspertami, a przy okazji to jest dość szerokie spektrum, kilka przestrzeni, bazy danych backend i frontend, do tego mamy jeszcze security i performance, więc naprawdę szeroki wachlarz ról, które obsługujemy dla klienta.

 

Dużo powiedziałeś o rozwoju w trakcie projektu, który był kluczowy do tego, żeby zdobywać kompetencje, zazwyczaj jest też tak, że samego projektu uczymy się w trakcie realizacji, poznajemy domenę, specyfikę. Czy jesteś w stanie powiedzieć trochę o tym inżynierskim aspekcie, jak podeszliście jako dział testerski do realizacji tego projektu?

 

RT: W tym projekcie m.in. byliśmy odpowiedzialni za zbudowanie frameworku do testowania backendowego rozwiązania, czyli musieliśmy włożyć taki nasz nowy moduł w istniejące interfejsy, i tym zajął się kolega, który robił na poziomie średnio zaawansowanego testera podobne rzeczy w innym projekcie. I zaproponowałem mu tę rolę, że będzie test leadem w tym obszarze backendowym, dostanie 2–3 junior testerów i będzie odpowiedzialny za to, żeby zbudować od zera to rozwiązanie. 

I ku mojemu zadowoleniu on się podjął tego zadania. Oczywiście wszystko we współpracy z deweloperami i z architekturą systemu, która była tam zaproponowana. Ale dzięki temu on mógł sobie zbudować kompetencje z jednej strony liderskie jako technik, z drugiej strony techniczne, bo zbudował sobie od zera ten framework i jest odpowiedzialny za jego utrzymanie i rozbudowę w następnych miesiącach.

 

Myślę sobie, że bardzo fajną możliwością, o której Rafał wcześniej wspomniał, jest awans poziomy, czyli możliwość objęcia ról w nieco innej ścieżce niż ta, o której zaczynaliśmy. Jestem ciekaw Waszego zdania, czy wg Was takie ścieżki kariery, które rozpoczynają się w tym punkcie testowania, a później przechodzą w role techniczne lub biznesowe, czy dla takich ścieżek kariery to wcześniejsze doświadczenie testerskie ma jakieś swoje odzwierciedlenie w tym, jak te ścieżki kariery dalej wyglądają? 

 

RT: Zdecydowanie tak. Wcześniej zdobyte doświadczenie testerskie, zarówno w ścieżkach technicznych, jak i analityka biznesowego, Project Managera czy jeszcze w paru innych rolach jest jak najbardziej tylko oczekiwanym dodatkiem, jeżeli chodzi o rozwój kariery zawodowej. Bycie testerem daje nam doskonałą możliwość, aby poznać proces wytwarzania oprogramowania od wielu stron. Nie tylko od strony technicznej, ale też od strony biznesowej, zarządzania projektem. 

Więc te wszystkie doświadczenia przez X lat w roli testera, analityka testów, automatyka testów czy jeszcze innej roli po prostu związanej z testami w późniejszych latach i po zmianie tej ścieżki na, czy to techniczną, czy bardziej zarządzającą, są doskonałą bazą do tego, aby lepiej wykonywać swoje zadania. Czy to w roli dewelopera, czy analityka biznesowego, czy w jeszcze innych obszarach. 

Więc zdecydowanie doświadczenie testerskie się przydaje i jest też ogromną wartością dodaną dla późniejszych projektów, w których dana osoba pracuje. I nie tylko dla projektów, bo dla ludzi również. Taka osoba będzie w stanie wspierać nowych ludzi czy ludzi z mniejszym doświadczeniem szerzej niż tylko w jednej wąskiej dziedzinie, bo będzie miała doświadczenie w pracy w różnych obszarach cyklu wytwarzania oprogramowania. To jest moja odpowiedź na to pytanie. Czyli jak najbardziej tak.

 

PB: Ja bym chciał dodać dwie rzeczy. Po pierwsze, oprócz tego, że testerzy mogą zmienić sobie ścieżkę na automatyczną, to chciałem zaznaczyć, że to nie jest jedyna ścieżka. Tych ścieżek naprawdę jest dużo, nawet w manualnym obszarze. Mamy te Security, Performance, Data Management, analizę biznesową. To są obszary i role, które są bardzo potrzebne. I nie da się wszystkiego zautomatyzować, bo pewne rzeczy i tak trzeba zrobić manualnie. Trzeba usiąść i wykonać dobrą, rzemieślniczą, analityczną robotę. I to robi tester manualny. 

Druga rzecz, o której chciałem powiedzieć, to chciałbym przestrzec przed hurtowym migrowaniem na automatyków. Spotkałem się parę razy już z takimi pomysłami, że po roku ktoś przejdzie z manuala na automatyka. To jest jakiś pomysł na siebie, natomiast nie zawsze to jest coś, do czego człowiek ma predyspozycje. I to się może udać, ale jest okupione dużym nakładem energii, czasu, siły. 

I zapewniam, że w samym testingu jest kilka innych obszarów, do których dana osoba będzie się lepiej nadawała. Jesteśmy teraz na etapie rozmów rocznych i widzę np. bardzo wysokie oceny człowieka ze skilli miękkich, 2–3 poziomy powyżej średniej krajowej, ale on się upiera, że idzie na automatyka. A z technicznych ma średnie krajowe. I tak mówię: Chłopie, świat do Ciebie mówi, to idź w ogóle w stronę liderską, odłóż tę automatyzacją na bok. Fajnie, że chcesz się uczyć, naucz się na takim poziomie, żebyś wiedział, co do Ciebie mówi zespół, że jak oni Ci mówią, że piszą właśnie nowe klasy, to żebyś wiedział, o co chodzi, a nie kiwał głową bez zrozumienia, ale zajmij się liderską ścieżką, bo widać, że to jest coś, co Ci w sercu gra, i że ludzie za Tobą idą. 

Więc trzeba też być czujnym na to, co się dzieje w okolicy, a oprócz tych ścieżek testerskich są różne role Scrum Mastera, Product Ownera, Project Managera z czasem, jak ktoś ma takie zapędy, więc kierunków jest dużo.

 

Więc zdecydowanie doświadczenie testerskie się przydaje i jest też ogromną wartością dodaną dla późniejszych projektów, w których dana osoba pracuje. I nie tylko dla projektów, bo dla ludzi również. Taka osoba będzie w stanie wspierać nowych ludzi czy ludzi z mniejszym doświadczeniem szerzej niż tylko w jednej wąskiej dziedzinie, bo będzie miała doświadczenie w pracy w różnych obszarach cyklu wytwarzania oprogramowania. 

 

No tak, wykorzystywanie swoich mocnych stron – myślę, że to jest tutaj słowo klucz. Na koniec chciałbym Was jeszcze zapytać o rozwój, bo mówimy o ścieżkach kariery, a ścieżka to, jakby nie było, taka ciągła droga. Jak ważne wg Was jest to, aby tester oprogramowania rozwijał się nie tylko w tym swoim fachu, w narzędziach, metodologiach, podejściach itd., ale też, żeby poznawał domenę projektu, żeby nabywał umiejętności związane z chmurą, z oprogramowaniem, z jakimiś innymi trendami technologicznymi? Jak takie podejście wpasowuje się w ścieżki kariery testera oprogramowania wg Was?

 

RT: Jest bardzo ważne. Już dzisiaj parę razy w trakcie naszej rozmowy mówiliśmy o tej wiedzy domenowej i o tym, że ten tester jest gdzieś pośrodku tego wszystkiego. I poszerzanie wiedzy domenowej czy bycie nawet Subject Matter Expertem w danej branży jest bardzo ważne i będzie jeszcze ważniejsze w przyszłości, bazując na wynikach pewnych ostatnich ankiet i raportach, które się pojawiały w internecie.

To jest jedna rzecz. A druga rzecz: umiejętności związane z chmurą czy programowaniem, czy ogólnie z nowymi trendami technologicznymi, gdzie też gdzieś w tym momencie wydaje się, że Blockchain i Web 3.0 zaczynają się robić wschodzącym trendem. To jest też coś, w czym testerzy będą musieli podszkalać swoje umiejętności i być na bieżąco z trendami rynkowymi. 

Wiąże się to z tym, że wszystko w tym momencie, czego oczekują projekty, klienci, wiąże się z tym, że przede wszystkim to klient i użytkownik końcowy ma być zadowolony z tego, co dostanie mu dostarczone, że ma to działać szybko, sprawnie i bez większych problemów. Nowe technologie, nowe trendy technologiczne prowadzą i chcą prowadzić do tego, żeby to finalne odczucie końcowego użytkownika było jak najlepsze. 

I wszystko to zamyka się w takim podejściu, że wszyscy testerzy jako szeroka grupa muszą podążać za tym, co się dzieje na rynku i dodatkowo jeszcze do tego wszystkiego zgłębiać wiedzę domenową w obszarze, w którym aktualnie pracują bądź chcą się rozwijać, czy to jest coś związane z obszarem bankowości, finansów, ochroną zdrowia, automotive czy cokolwiek innego, nie można w dzisiejszych czasach w pracy testera zamykać się tylko i wyłącznie na to, co mamy teraz, ale jak najbardziej trzeba myśleć o tym, co będzie w przyszłości, a co za tym idzie, żeby też się dopasować do tego, co ta przyszłość nam przyniesie. Oczywiście nie jesteśmy w stanie tego przewidzieć, niemniej jakieś kroki można zawsze podejmować, żeby w razie czego być przygotowanym.

 

Paweł?

 

PB: Dodam tylko pokrótce, że tester to nie jest osoba, która powinna powiedzieć: Ja już umiem wszystko. Musi być cały czas gotowa do tego, żeby się rozwijać i uczyć. I jest to też coś, na co ja zwracam uwagę podczas rekrutacji. Że to nie jest tak, że mój task jest zablokowany, to siedzę i nic nie robię, tylko wykorzystuję ten czas do czegoś. Albo pomagam w zespole, albo się rozwijam. Bo ten rozwój jest konieczny. Świat się zmienia, pędzi, IT i tester musi w jakimś stopniu za tym wszystkim nadążać.

 

I to była bardzo dobra puenta. Rafał Tramowski i Paweł Banaszczyk byli moimi gośćmi. Rozmawialiśmy o ścieżkach kariery w testingu oprogramowania. Bardzo Wam dziękuję za rozmowę.

 

RT: Dzięki wielkie!

 

PB: Dzięki!

 

Zanim się rozłączymy, powiedzcie jeszcze, gdzie Was można znaleźć w internecie, w jaki sposób można się skontaktować albo gdzie chcielibyśmy odesłać słuchaczy.

 

PB: Mój profil jest na LinkedIn oraz na rozmowach rekrutacyjnych do Capgemini.

 

RT: U mnie podobnie. Tak że w razie czego zapraszamy do kontaktu.

 

Wszystkie linki będą oczywiście w notatce do odcinka. Z mojej strony to na dzisiaj tyle. Dziękuję bardzo, do usłyszenia.

 

Cześć!

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Po więcej wartościowych treści zapraszam Cię do wcześniejszych odcinków. A już teraz, zgodnie z tym, co czujesz, wystaw ocenę, recenzję lub komentarz w aplikacji, której słuchasz lub w social mediach. 

Zawsze możesz się ze mną skontaktować pod adresem krzysztof@porozmawiajmyoit.pl lub przez media społecznościowe. 

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o ścieżkach kariery w testingu oprogramowania. Zapraszam do kolejnego odcinka już wkrótce.

Cześć!