Ścieżki kariery w testingu oprogramowania

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Rafałem Tramowskim i Pawłem Banaszczykiem z Capgemini o ścieżkach kariery w testingu oprogramowania.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Ścieżki kariery w testingu oprogramowania - Porozmawiajmy o IT

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.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-179-sciezki-kariery-w-testingu-oprogramowania/