To jest 257. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o ścieżce kariery testera oprogramowania. 

Wszystko, co potrzebujesz, notatka, linki, transkrypcja czekają na Ciebie na porozmawiajmyoit.pl/257. 

Myślisz o zmianie pracy lub przebranżowieniu do IT? Zajrzyj na SolidJobs, gdzie znajdziesz przejrzyste oferty z informacją co do zarobków, technologii i projektów. 

Nazywam się Krzysztof Kempiński, prowadzę ten podcast oraz jestem autorem książki Marka Osobista w branży IT. Mam misję polegającą na poszerzaniu horyzontów ludzi z branży IT. Tak się składa, że możesz bardzo mi pomóc w jej realizacji poprzez wystawienie oceny w aplikacji, w której tego słuchasz, lub podzielenie się odcinkiem w social mediach. A teraz zapraszam Cię już do odcinka. 

Odpalamy! 

 

Cześć! 

Mój dzisiejszy gość w branży IT działa od 2011 roku. Aktualnie tech lead, senior quality engineer, architekt testów, konsultant, trener, mentor i twórca materiałów dla całej społeczności testerów w Polsce na jaktestować.pl. W wolnym czasie oddaję się pasjom poza IT, treningom siłowym, crossfitowi, literaturze i szeroko pojętej sztuce. Moim i Waszym gościem jest Krzysztof Kijas. 

Cześć, Krzysztof. Bardzo miło mi gościć Cię w podcaście. 

 

Cześć, mi też miło. 

 

Dzisiaj z Krzysztofem będziemy rozmawiać oczywiście o testowaniu oprogramowania, ale z nieco mniej technicznej roli, ponieważ przyjrzymy się ścieżkom kariery, możliwości rozwoju właśnie w tej branży. Spojrzymy sobie, jak od juniora do seniora możemy rozwinąć naszą karierę w testowaniu software’u. 

Myślę, że temat bardzo ciekawy nie tylko dla tych, którzy rozpoczynają właśnie swoją drogę w tej dziedzinie lub o niej myślą, ale również dla tych, którzy są juz na jakimś etapie i chcą awansować.

Zanim do tego jednak przejdziemy, to chciałbym Cię Krzysztof zapytać, tak jak każdego mojego gościa, czy słuchasz podcastów, no i jeśli masz jakieś ciekawe rekomendacje, to z pewnością dobrze byłoby je też tutaj podzielić się nimi ze słuchaczami. 

 

Jasne. Jak najbardziej słucham podcastów. Są to zarówno podcasty związane stricte z IT, jak i również ogólnie pojętym rozwojem osobistym. Jeśli miałbym parę wymienić, polecić słuchaczom, to Porozmawiajmy o IT. 

 

Dziękuję. 

 

Oczywiście, ale również Better Software Design od Mateusza Gila. A jeśli chodzi o takie ogólnorozwojowe, tutaj bardzo różnorodnie np. Chris Williamson, Modern Wisdom, Jocko Podcast, Lex Fridman, o którym też wcześniej przed podcastem jeszcze rozmawialiśmy, Tomek Górczyk i masę, masę różnych. Tak naprawdę wszystko zależy od tematu, od gości. Jeśli coś mnie zainteresuje, to też wskakuję w dany temat. 

 

Super rekomendacje, dzięki za nie. Dobrze, to myślę, że standardowo przeszliśmy sobie już przez ten wstęp i warto się skierować na nasz główny temat, jakim jest właśnie droga od juniora do seniora w testowaniu oprogramowania. 

I zacznijmy może od początku, od czego zacząć, kiedy jestem zupełnie na początku drogi w testowaniu, na co powinienem zwrócić uwagę, czego się dowiedzieć, o jakich rzeczach może doczytać?

 

Trochę zależy od tego, jak zinterpretujemy na samym początku. Bo jeśli np. jesteśmy na początku i jeszcze nie weszliśmy do branży, dopiero się zastanawiamy nad wejściem, to myślę, że bardzo ważne na początku zdefiniować sobie, czego tak naprawdę chcemy, jaki jest nasz faktyczny cel, dlaczego chcemy akurat iść do tej branży i zostać testerem oprogramowania, a następnie odpowiedzieć sobie na bardzo ważne pytanie, ile mamy czasu na zostanie tym testerem, jaki jest nasz horyzont czasowy, ile mogę poświęcić czasu, życia, pieniędzy, czyli ogólnie zasobów na naukę, rozwój, a później też i pracę w tej roli. 

Również warto się zastanowić, jakie mamy wykształcenie, background techniczny czy umiejętności miękkie, które mogą nam pomóc wejść w tej branży i się rozwijać, ale też zobaczyć, jakie są możliwości na rynku. Więc to są takie, bym powiedział, rzeczy, o których powinniśmy pomyśleć, jak jeszcze nie zaczęliśmy być w tej branży. 

Natomiast jeśli jesteśmy na samym początku, ale już pracujemy jako tester, jesteśmy tam, powiedzmy, od kilku tygodni, może kilku miesięcy, to też na początku bym zasugerował zastanowienie się, czy dobrze rozumiemy rolę testera, na zasadzie czy to, jak wcześniej postrzegaliśmy tę rolę przed wejściem do branży, spina się z tym, gdzie jesteśmy, jak teraz organizacja postrzega tę rolę, czy raczej opisuje tę rolę, i tutaj nadrobić ewentualnie, bądź zmodyfikować właśnie nasze postrzeganie, żebyśmy też widzieli, w jaką stronę się powinniśmy rozwijać. 

A następnie myślę, że bardzo ważny jest rozwój zarówno umiejętności miękkich, jak i technicznych, czyli narzędzia, w których mamy styczność, czyli chociażby komunikacja tutaj w umiejętnościach miękkich, to jest bardzo ważne, a tak naprawdę to jest podstawa tego wszystkiego. 

A później po umiejętnościach miękkich i technicznych, o których, myślę, jeszcze sobie trochę powiemy później, bardzo ważne jest na początku już rozeznanie się, rozejrzenie się za różnymi społecznościami testerskimi. Czy to np. społecznościami, które działają online, różnymi grupami, czy też społecznościami, które działają lokalnie, czyli są jakieś meetupy, konferencje, bo to jest świetna możliwość złapania nowych kontaktów, inspiracji, znalezienia może nawet mentorów już na tych różnych grupach, eventach, więc myślę, że to jest też bardzo ważne. 

Kolejny temat, też warto od razu się otworzyć na feedback i na samodoskonalenie się, czyli jak pracujemy, jesteśmy w pierwszej pracy, to od razu jasno też poprosić naszych przełożonych, osoby, z którymi pracujemy, żeby dawały nam feedback z tego, co robimy, jak robimy to, żebyśmy od razu mieli tę informację zwrotną, żebyśmy mogli od razu się doskonalić w tym, co robimy. I tutaj właśnie przede wszystkim ważna jest otwartość na błędy, taka, że cały czas się czegoś uczymy. 

Też ważne jest śledzenie trendów, nowości w branży, czyli cały czas aktualizowanie tej wiedzy, bo też branża IT, i też testowanie ogólnie, bardzo często i dynamicznie się zmienia, więc to, co np. było 5 lat temu popularne i na topie, dzisiaj może być już przestarzałe i nieużywane tak naprawdę, więc też warto śledzić trendy. 

Tutaj zaproponowałbym też od razu pomyślenie o budowaniu portfolio, a nawet troszeczkę wyszedłbym dalej, na zasadzie budowanie takiej marki osobistej nawet bym zaproponował. Przy czym to też nie wrzucałbym wszystkich na markę osobistą. Warto to się zastanowić, czy nam się to nie przydało. Tutaj w sumie nawiążę już do twojej książki, którą napisałeś, budowanie marki osobistej to nie jest występowanie na konferencjach i nie wiadomo czego robienie, tylko to jest tak naprawdę już dzielenie się tym, co umiemy, pisanie jakiegoś bloga, pomaganie innym, opisywanie tak naprawdę naszej drogi, którą przebywamy, jak podchodzimy do rozwiązywania problemów i też branie udziału w różnych inicjatywach, które występują. 

Więc myślę, że to jest, może być mega wartościowe, a jest też dużo możliwości i tematów, jakie możemy podejmować. Więc myślę, że tutaj każdy może coś dla siebie znaleźć. Lubisz pisać? Super, możesz zacząć pisać jakiegoś bloga. Lubisz pomagać innym? Super, możesz zacząć też pomagać osobom, które mają jeszcze mniej doświadczenia niż ty na przykład. Więc myślę, że tutaj każdy by znalazł coś dla siebie. 

I też dodałbym tutaj chyba najważniejsze, co powinienem na początku de facto powiedzieć, planowanie dalszego rozwoju, czyli określenie swoich celów, zarówno krótkich, jak i długoterminowych. Czyli gdzie tak naprawdę chcesz być za rok, za dwa, za pięć lat, dlaczego przyszedłeś do tej branży, czy może cele się zmieniły w trakcie, to też jest okej, dostosujmy teraz te kroki, żeby teraz dojść do tego nowego celu. I to też wpłynie na ścieżkę kariery, którą później będziemy jakby wybierać, czy akcje, które będziemy podejmować, czy chcę np. iść w stronę automatyzacji, security, performance, czy jakiejś specjalizacji seniora, czy może w ogóle bardziej role liderskie albo związane z biznesem. 

 

Zaznaczyłeś potrzebę czy wręcz konieczność równomiernego rozwoju nie tylko tych umiejętności kompetencji twardych, ale i miękkich, ale oczywiście w zależności od tego, na jakim poziomie rozwoju kariery jesteśmy, to głębiej lub nieco płyciej mamy konieczność, potrzebę wchodzenia w te różne aspekty. I myślę, że często taką nieoczywistą rzeczą jest stwierdzenie, na jakim właściwie poziomie rozwoju jesteśmy, czy jakiego typu wiedzę powinniśmy chłonąć w zależności od tego, na jakim etapie obecnie jesteśmy.

Czy masz jakieś porady, jakieś wskazówki co do tego właśnie, jak w testowaniu oprogramowania określić, czy jesteśmy juniorem, regularem, a może już seniorem?

 

Myślę, że to jest świetne pytanie i tutaj rozważłbym dwa konteksty. Jeden kontekst to jest kontekst organizacji, bo często organizacje mają jasno określone wymagania do każdego z poziomów. No i same poziomy też mają w miarę jasno określone, tutaj też mocno to zależy od organizacji. Więc pierwszym krokiem byłoby to, że poszukałbym, czy coś takiego jest w organizacji, jakieś macierze, jakieś dokumenty, które to opisują, a następnie zapoznałbym się i określił trochę samemu na zasadzie, czego mi brakuje, gdzie już jestem, gdzie niby spełniam jakieś oczekiwania czy wytyczne.

Jednak powiedziałbym, że to jeszcze nie jest wystarczające, gdyż tutaj zasugerowałbym też znalezienie kogoś bardziej doświadczonego, to może być rekruter, mentor z tej organizacji, do którego mamy jakieś zaufanie, tak żeby przegadać ten poziom, czy na pewno tutaj czegoś nie przeoczyliśmy, czy np. nie uznaliśmy, że coś umiemy, gdzie okazało się, że to jest tylko jakiś wierzchołek góry lodowej. Więc warto tutaj skonfrontować trochę ten poziom, który nam wyszedł z tej macierzy, z tych dokumentów, z kimś, kto ma tutaj większe doświadczenie.

I przede wszystkim tutaj, tak jak trochę wcześniej wspomniałem, należy być, myślę, bardzo otwartym na feedback i takie krytyczne podejście do tego, co umiemy albo czego nie umiemy, bo taki feedback może być kluczowy i krytyczny w kontekście naszego rozwoju i przyspieszenia naszego rozwoju. I to byłoby tak w kontekście organizacji. Czyli, że mamy jakieś dokumenty, możemy sobie może jakoś to określić.

Czasami jest tak, że w tej organizacji nie ma takich dokumentów, bo organizacja to jest dopiero startup albo jakikolwiek inny powód. I teraz możemy właśnie wyjść tak trochę na zewnątrz, czyli popatrzeć na rynku, jakie są standardy, jakie są poziomy. Możemy tutaj poszukać różnego rodzaju materiałów w internecie, np. czego zazwyczaj się wymaga od seniorów, czy mediumów, czy juniorów, jakie kompetencje powinny mieć te osoby.

Jednak też tutaj przestrzegłbym, że jakość tych materiałów bywa równa, więc tutaj warto też poszukać co najmniej wielu takich źródeł i je zostawić, tak trochę też krytycznie do tego podejść. Natomiast też tutaj później zasugerowałbym np. znalezienie kogoś również doświadczonego, też rekrutera jakiegoś, mentora, też jakąś osobę zaufaną i też zestawienie się po prostu z tą osobą, zobaczenie, co ta osoba może powiedzieć na temat naszego poziomu, nawet zasugerowałbym wykonanie takiej testowej rozmowy rekrutacyjnej. Dzięki temu będziemy mieć od razu feedback, jak zostaliśmy ocenieni, co można by było poprawić i myślę, że to byłoby mega cenne w kontekście rozwoju.

A poza taką osobą, jeśli np. nie mamy takiej osoby, bo to też nie wszyscy mamy znajomych rekruterów czy mentorów, to myślę, że cały networking jest bardzo wartościowy, dyskusje na różnych spotkaniach, meetupach, forach, bo możemy sobie właśnie od tych osób też nawet jako słuchacze zaczerpnąć, zobaczyć, czy to, czy czegoś nam brakuje, nie wiemy np. o jakich tematach mówią, albo jesteśmy w stanie się jakoś porównać. Więc to też może być jakimś takim kolejnym elementem, który może nam pokazać, na jakim poziomie jesteśmy.

Też bym powiedział, że czasami ciężko określić tak bardzo dokładnie, że jestem np. na 59% mediuma, bo tak naprawdę liczba tych wszystkich umiejętności, czy chociażby umiejętności miękkie są mało mierzalne, mało smart i czasami bardzo ciężko tak dokładnie określić, że okej, tutaj np. z komunikacji jest bardzo dobrze, a z zarządzania czasem albo priorytetami powinniśmy popracować. Znacznie łatwiej tak naprawdę określić swój poziom w programowaniu.

 

Tak, to prawda. Rozmawiamy dzisiaj o drodze od juniora do seniora w testowaniu oprogramowania, w związku z tym pojawia się pytanie, jak Ty definiujesz stanowisko seniora, kim do Ciebie jest taki senior i o jakich ścieżkach wiodących właśnie do tej roli, czy też stanowiska, tutaj też jestem ciekawy, jak na to patrzysz, czy możesz powiedzieć?

 

Tak, zacznę od tego, kto według mnie jest seniorem. Dla mnie seniorem jest taka osoba, która jak zostanie przydzielona do danego projektu, jest w stanie ogarnąć mi ten projekt pod wszystkimi względami w kontekście jakości, czyli procesy, narzędzia, kontakt z klientem, testy automatyczne, testy wydajnościowe, tematy związane z DevOpsem, narzędzia CI/CD, tak w dużym uproszczeniu.

I teraz, jakie ma umiejętności ta osoba, tam jakieś doświadczenie, powiedzmy, nie wiem, plus 5 lat zazwyczaj to jest zdefiniowane, umiejętności przywódcze, komunikacyjne, zarządzanie ryzykiem, jakieś strategiczne myślenie, i też jest np. nastawiona na ciągły rozwój. I jakie są ścieżki do tego stanowiska? To też trochę tutaj może się powtórzę, to też zupełnie zależy od organizacji. Jeśli są te dokumenty, to też mamy jakieś tam zdefiniowane liczba lat doświadczenia. To zazwyczaj jest 5-8 lat doświadczenia. Albo liczba projektów, w których ta osoba powinna być, czyli na przykład minimum trzy projekty, doświadczenie minimum trzech projektów.

A poza takimi powiedzmy miękkimi tematami, czy tam związanymi z projektami, to też jasne wytyczne dotyczące wiedzy i znajomości projektów i technologii. Czyli dobra znajomość programowania w jakimś, chociaż w jednym języku, znajomość różnych narzędzi do CI/CD, jakichś systemów chmurowych, jakichś narzędzi do automatyzacji, też poziom komunikacji z zespołem albo jakiś poziom dzielenia się wiedzą, czyli np. blogi prowadzi ta osoba, samodzielność w pracy, w podejmowaniu decyzji. To jest taka najprostsza ścieżka. W zasadzie mamy wytyczone to w organizacji i możemy tym podążać.

Często może być tak, że nie będzie czegoś takiego, nie ma takich dokumentów, nie jest to jasno określone i teraz mamy taką opcję, że możemy w takim razie pogadać może z liderem albo z jakimiś osobami odpowiedzialnymi za awans, aby dowiedzieć się o potrzebach firmy, organizacji czy projektu, gdyż my w trakcie naszego rozwoju, jeśli pokryjemy te potrzeby, to jest szansa, że szybciej będziemy awansować, a organizacja nas dostrzeże, jesteśmy cennym pracownikiem, to jest szansa, że awansujemy. Więc to jest też jeden ze sposobów.

Natomiast kolejnym, jeśli np. też nie mamy takich osób, powiedzmy, nie mamy lidera z jakiegoś powodu, to tutaj musimy trochę sami podejść do tego i zobaczyć, co dla projektu i co dla organizacji jest ważne i sami trochę spróbować określić właśnie, co jest najważniejsze, ale tutaj też podobnie jak poprzednio, to wiedza techniczna i umiejętności miękkie, one się będą pojawiać cały czas, więc to są takie dwie inwestycje, które nie chcę powiedzieć na pewno, ale z dużym prawdopodobieństwem się spłacą.

I też tak mówiliśmy o organizacji, ale tak nawet poza organizacją, ja bym tutaj sugerował, żeby też nie iść tak nawet za tymi wytycznymi, które tej organizacja sugeruje, tylko ja bym też sięgał trochę po więcej tak naprawdę, czyli pomyślał o takim rozwoju indywidualnym, zastanowił się, co mnie jara, w którą stronę chciałbym iść, gdzie się właśnie widzę za te pięć lat i tutaj na przykład zainwestowałbym właśnie w jakieś kursy, które poszerzają wiedzę horyzonty, z których tematów, które mnie w tym momencie rajcują, bo prawdopodobnie najszybciej przyswoję tę wiedzę, i które też są w jakiś sposób pokrewne z tym, gdzie organizacja dąży. Na przykład automatyzacja albo tematy DevOpsowe.

Można też własne projekty tworzyć czy nawet własne produkty, w których też się mega dużo uczymy. Ja tutaj np. też ostatnio chociażby robię wtyczki do VS Code albo też aplikacje dla testerów tworzę, co też mi daje mega dużo wiedzy z programowania, zarządzania projektami, która może nie jest jakby stricte powiązana z tym, co robię na co dzień, ale daje mi dużo dodatkowej wiedzy, doświadczenia chociażby z kontaktu z klientem, z zarządzania produktem, z wiedzy, którą później mogę przełożyć na zasadzie takiej, że jak pracuję z klientem w projekcie, to ja zaczynam dostrzegać pewne jego potrzeby albo potrzeby klienta końcowego, których prawdopodobnie mógłbym nie dostrzec, jeśli bym nie realizował tych własnych projektów.

Jeszcze np. mentoring, też bym zastanowił się nad tym, bo mentoring naprawdę daje boosta właśnie w tym rozwoju. O marce osobistej, tak jak właśnie wcześniej wspominaliśmy trochę, czyli też kontakty, blogi, własne strony, jakaś aktywność właśnie w projektach, czy w firmie też może pozwolić sobie zdobyć ten poziom, czy ogólnie udział w jakichś projektach publicznych, np.jakieś pull requesty do projektów open source.

 

Tych ścieżek tutaj wymieniłeś całkiem sporo i to jest, myślę, dobra wiadomość dla tych, którzy chcą sobie wybrać to, co po prostu najbardziej im pasuje. I tak, jak tutaj też zaznaczyłeś, zgadzam się z tym absolutnie, często bardzo to zależy od organizacji. Nie ma czegoś takiego jak jedna wykuta w kamieniu definicja seniora. Często pomiędzy organizacjami potrafi się ona różnić, co jest zrozumiałe, bo działają one w jakimś tam różnym zapleczu, jeśli chodzi o domenę, o standardy, o technologię itd.

Ale myślę sobie, że stawiając właśnie ten nasz dzisiejszy temat w ten sposób, że wspominamy tutaj, czy mówimy o drodze od juniora do seniora, to traktujemy tego seniora jako taki ostateczny cel do osiągnięcia w naszej karierze. No i pojawia się pytanie, czy to faktycznie tak jest, czy zawsze powinniśmy mieć ten cel pod tytułem zostanie seniorem, czy też bycie uznanym jako senior w organizacji? Czy też może nie ma w tym absolutnie nic złego, żeby na jakimś etapie się rozwijać i służyć organizacji w ten sposób równie dobrze?

 

Parafrazując to pytanie, czyli czy każdy powinien być tym seniorem? Tak naprawdę awans na seniora nie jest obowiązkowy ani niezbędny dla każdego testera. Tutaj myślę, kluczowe jest zdefiniowanie własnych celów zawodowych i dążenie do nich z własnymi preferencjami, potrzebami, rozwijanie się właśnie w kierunkach, które przynoszą nam faktycznie satysfakcję i spełnienie, i bycie przede wszystkim świadomym swoich mocnych stron, które możemy wykorzystać w pracy.

<blockquote>Tak naprawdę awans na seniora nie jest obowiązkowy ani niezbędny dla każdego testera. Tutaj myślę, kluczowe jest zdefiniowanie własnych celów zawodowych i dążenie do nich z własnymi preferencjami, potrzebami, rozwijanie się właśnie w kierunkach, które przynoszą nam faktycznie satysfakcję i spełnienie, i bycie przede wszystkim świadomym swoich mocnych stron, które możemy wykorzystać w pracy.</blockquote>

To jest niezależnie tak naprawdę od formalnego tytułu. Więc tak naprawdę dużo zależy właśnie od celów, aspiracji czy umiejętności. Więc moim zdaniem awans na seniora nie jest nie jest obowiązkowy, aczkolwiek różne organizacje mogą mieć też równe postrzeganie tego na zasadzie takiej, że jak ktoś przez 12 lat jest np. juniorem, to organizacja może różnie na to spojrzeć, więc warto się zastanowić, czy są takie rzeczy, które mnie blokują przed tym awansem i uzupełnienie ich, chociaż na ten właśnie minimalny sposób, żeby móc, powiedzmy, awansować odrobinę.

Bo jeśli chodzi o seniora, często to się wiąże właśnie z większymi obowiązkami, odpowiedzialnościami, czasami kierowaniem całym zespołem, więcej kontaktu np. z klientem, więc ja np. uważam, że są osoby, które sobie lepiej w tym radzą, są osoby, które sobie z tym gorzej radzą, ale każdy ma jakieś mocne strony, które powinniśmy wziąć pod uwagę i wykorzystać jakoś w projekcie właśnie te dobre strony.

Na przykład Janek nie lubi kontaktu z klientem, ale jest na przykład dobry w kodowaniu, to wrzućmy go do kodzenia, a nie pchajmy go na pierwszą linię do pracy z klientem, bo tam się albo szybciej wypali, albo będzie mniej efektywny niż jakby właśnie nam szkodził ten mikroserwis, taki przykład deweloperski, ale tak, tutaj tak bym odpowiedział na to.

 

Okej, troszkę dotknęliśmy tematu seniora, wymagań, oczekiwań, tego, z czym się wiąże właśnie takie stanowisko. Na moment jeszcze chciałbym tutaj zrobić krok wstecz i wrócić do juniorów. Bo myślę, że nie wiem, czy teraz jeszcze tak jest, o to też bym chciał Cię spytać, ale jakiś czas temu to właśnie testowanie oprogramowania było taką furtką wejściową do IT dla wielu osób, które gdzieś się przebranżawiały, gdzieś szukały swojej drogi, zmieniały branżę.

I wtedy dosyć często pojawiało się pytanie, które też bym chciał skierować do Ciebie, czy takie formalne wykształcenie różnego typu kursy być może są tutaj niezbędne, czy też da się tej działki, tej branży nauczyć samodzielnie, posługując się dostępnymi materiałami i równie dobrze odnaleźć w ten sposób w pracy?

 

Tutaj mogę krótko odpowiedzieć, też z doświadczenia, że nie, nie jest to niezbędne, bo znam bardzo dużo osób, które są obecnie seniorami, czy to jako testerzy, czy QA, QE, czy developerzy, którzy nie mają takiego formalnego wykształcenia technicznego, czyli nie skończyli studiów informatycznych i świetnie wykonują swoją pracę. I to doświadczenie nabywali albo w projektach, albo w jakichś dodatkowych projektach, które gdzieś robili, albo na kursach.

Więc tutaj jakby dróg czy do wejścia, czy do rozwoju w IT jest wiele, jeśli chodzi właśnie o dojście do tego seniora i to wcale to się nie wiąże właśnie tak jeden do jeden ze studiami takimi typowo technicznymi.

Jednak co ważne, co warto tutaj też poruszyć, takie studia, bo to zawsze jest tam 4-5 lat, to jest sporo czasu, one dają na pewno też nam jakieś fajne podstawy odnośnie do programowania, doświadczenia w kwestii rozwiązywania różnych problemów, pracy w zespołach. Jest dużo też równej wiedzy, którą możemy nie wykorzystać w przyszłości, też warto to jednak powiedzieć. Jednak jest dużo rzeczy, które my możemy wynieść z tych studiów i teraz trochę od nas zależy, ile my tak naprawdę z tych studiów wyciągniemy i wykorzystamy później.

Jeśli np. realizowaliśmy dużo projektów, to to może nam później zaprocentować właśnie, że startujemy z masą projektów w portfolio. Jeśli przeszliśmy tak po prostu przez te studia, to to też w jakiś sposób będzie procentowało to, gdzie będziemy i jak będziemy się szybko poruszać, więc tutaj dużo od nas zależy.

A inną opcją jest też po prostu skorzystanie z kursów, mentoringów i tego typu sposobów rozwoju, bo to może nas tak bardziej dać tam wiedzę, umiejętności punktowe na zasadzie, jeśli potrzebujemy programowania, okej, wykorzystajmy jakiś sprawdzony przede wszystkim kurs związany właśnie z programowaniem, okej, no to mamy tę umiejętność techniczną pokrytą, ona była główną tą umiejętnością, której potrzebujemy i to nam da już też jakiś tam plus na starcie.

Więc wracając do pytania, wykształcenie takie formalne, techniczne myślę, że tutaj nie jest niezbędne, może dużo zaprocentować, jeśli jesteśmy w stanie z niego wyciągnąć to, co nam oferuje.

 

Z pewnością mając kontakt z wieloma juniorami, działając też w takiej, można powiedzieć, branży edukacyjnej właśnie w temacie testowania, oprogramowania, miałeś okazję zobaczyć wiele błędów, wiele takich wpadek popełnianych przez juniorów w tym rozwoju kariery na początku. Mógłbyś się podzielić właśnie takimi lekcjami czy takimi uwagami, które gdzieś zauważyłeś w tym temacie?

 

Myślę, że mógłbym, gdyż te błędy myślę, że tak naprawdę wszyscy popełniamy. Na każdym poziomie te błędy się pojawiają. Jednak na początku kariery, czym szybciej je wyeliminujemy, tym po prostu będzie nam później łatwiej.

Taki pierwszy błąd, który tutaj wysoko umiejscowił: unikanie feedbacku i przyjmowania krytyki, czyli takie ignorowanie trochę opinii innych albo odbieranie je jako ataku. Jeśli tak podchodzimy do informacji zwrotnej, którą osoby nam oferują, to to nam ogranicza możliwości rozwoju i poprawy naszych umiejętności. Czyli tutaj warto być otwartym na konstruktywną przede wszystkim krytykę i traktować ją jako szansę na rozwój. Czyli coś, co my możemy właśnie poszlifować i progresować, a nie jako atak. Więc unikanie feedbacku, przyjmowanie krytyki.

Kolejny błąd, który występuje też na wszystkich poziomach, ale warto go wyeliminować wcześniej, to jest niedocenianie umiejętności miękkich, czyli skupiamy się tylko np. na umiejętnościach technicznych, czyli przychodzimy do IT i uczymy się tylko kodowania czy tam kodzenia, w zależności od odmiany, a w ogóle zapominamy o komunikacji, zapominamy o zarządzaniu czasem albo o umiejętności uczenia się. Jesteśmy tylko skupieni na umiejętnościach technicznych, a tak naprawdę komunikacja jest podstawą wszystkiego, bo dzięki komunikacji my jesteśmy w stanie sprzedać nasz pomysł, jesteśmy w stanie, oczywiście później, zachęcić nasz zespół do tego rozwiązania, nad którym pracowaliśmy np. przez ostatnie pół roku, czy wiele innych.

Więc tutaj warto o tę komunikację, o te umiejętności miękkie na początku zaraz się też zatroszczyć.

Co dalej? Brak ciągłego jakiegoś uczenia się i rozwoju. Też to o umiejętności miękkie zahacza, ale też warto wziąć pod uwagę, że IT się bardzo dynamicznie zmienia i warto od samego początku gdzieś patrzeć na różne tematy, obserwować blogi, interesować się tymi tematami, gdzieś podszkalać się, żeby się nie okazało, że po 10 latach w jakimś projekcie wykonywaliśmy tylko testy manualne i tak naprawdę cały czas to samo, bo rynek tutaj naprawdę galopuje i te umiejętności bardzo, bardzo szybko się tutaj, nie chcę powiedzieć przeterminowują, ale zmieniają.

Więc jeśli tutaj wchodzimy do IT, wchodzimy właśnie jako tester, to po prostu musimy być gotowi na to, że będziemy, nie chcę powiedzieć tutaj zmuszeni, ale będziemy musieli po prostu cisnąć z tym rozwojem i uczyć się nowych umiejętności może nie co miesiąc, ale tak co rok coś nowego na pewno będzie wpadało.

I dodałbym tutaj jeszcze chyba jedno: brak zrozumienia kontekstu biznesowego. Przychodząc do projektu, jakikolwiek de facto projektu, który mamy w IT, on rozwiązuje jakiś problem, czyli mamy np. użytkownika końcowego, załóżmy transport, który chce się przemieszczać i klient nasz chce rozwiązać jego problem przez jakiś nowoczesny system biletowy.

I my jako testerzy musimy testować ten system, który jest rozwijany przez naszą organizację i bardzo często jest tak, że zapominamy o tym użytkowniku końcowym, o tym tak naprawdę, jaki problem ma ten system rozwiązywać, czyli że ma usprawniać komunikację itd., tylko skupiamy się na takich bardzo prostych, błahych trochę rzeczach, na zasadzie np., nie wiem, czy kod testów automatycznych jest tam wypolerowany, czy gdzieś tam jakieś mało znaczące, może tak to ujmę, kontrolki są gdzieś tam troszeczkę niewypoziomowane, może nie wchodzimy za bardzo w UX, ale są takie czasami rzeczy, że skupiamy się zbytnio na nich, a one tak naprawdę nie składają się na tą wartość dla klienta.

Więc tutaj warto też od samego początku pomyśleć właśnie o tym, że to jest produkt, on rozwiązuje jakiś problem i tak wejść właśnie w buty tego klienta, tego użytkownika końcowego i z tą myślą tak naprawdę się rozwijać, bo to też nie jest tak, że te wszystkie błędy, które tutaj wymieniłem, że się budzę i już mam ten jeden problem załatwiony, już umiem tak naprawdę, tylko cały czas tak naprawdę też widząc po moim rozwoju, trzeba pielęgnować, trzeba się zastanawiać właśnie i pracować z tym klientem i ten kontekst biznesowy cały czas poznawać.

I chyba jeszcze bym dodał tak na koniec jeszcze: często unikanie po prostu nowych wyzwań i nowych doświadczeń. Bo tak naprawdę nowe wyzwania, nowe doświadczenia pozwalają nam się rozwijać, czyli czy to jest nowy projekt, czy to jest udział właśnie w konferencji, pójście na meetup chociażby, to już jest jakieś wyzwanie, już jakieś osiągnięcie, czy nawet prelekcja na jakimś wykładzie, czy np. dla mnie tutaj udział w podcaście, to też jest jakieś wyzwanie, przygotowanie się i udział, przełamanie tremy, więc to jest też masa rzeczy, których się też uczę i które też w jakiś sposób będą wpływać na mój rozwój, na osiągnięcie moich kolejnych celów, moich kolejnych tutaj planów, które mam.

Taki pierwszy błąd, który tutaj wysoko umiejscowił: unikanie feedbacku i przyjmowania krytyki, czyli takie ignorowanie trochę opinii innych albo odbieranie je jako ataku. Jeśli tak podchodzimy do informacji zwrotnej, którą osoby nam oferują, to to nam ogranicza możliwości rozwoju i poprawy naszych umiejętności. Czyli tutaj warto być otwartym na konstruktywną przede wszystkim krytykę i traktować ją jako szansę na rozwój. Czyli coś, co my możemy właśnie poszlifować i progresować, a nie jako atak

 

Właśnie, unikanie tych pułapek, o których powiedziałeś, myślę, że to jest ważna rzecz, bo to nas zwyczajnie ogranicza, zwalnia ten rozwój i ten progres kariery, ale to, co mnie na końcu właśnie tutaj uderzyło w Twojej odpowiedzi, to to, że nazwałbym to mindset, nazwałbym to podejście, jest pewnie równie ważne, dlatego chciałbym Cię zapytać o zbiór cech, które, powiedzmy, pozwalają nam szybciej awansować, albo które jeśli rozwijamy, to pozwalają nam szybciej iść właśnie tą drogą od juniora do seniora.

 

Tutaj można by było w sumie te wszystkie błędy, które wymieniłem, odwrócić. Ale tak, zacząłbym od komunikacji, bo to jest jednak sprzedaż nasza, naszej osoby, naszych pomysłów. Te wszystkie feedbacki, to wszystko się tutaj zawiera w tej komunikacji. Wydobywanie tej informacji od innych osób, zrozumienie potrzeb biznesowych, kontakt z klientem, to wszystko gdzieś tutaj w tej komunikacji myślę, by się zawierało. Więc dobra komunikacja, organizacja przede wszystkim pracy i czasu.

Czyli jak my sobie tę pracę układamy, czyli czy ta praca nam się rozlewa i przez niby pracując 8 godzin, a tak naprawdę pracujemy 12 godzin, bo tutaj mamy przerwę, bo tutaj kawka, bo tutaj wyjście do kuchni itd. Czy się np. skupiamy, praktykujemy na przykład pracę głęboką, czy jakieś techniki priorytetyzacji zadań. Myślę, że to jest też mega ważne, żeby jakby wycisnąć z tego dnia trochę więcej, czyli zrealizować jeden projekt więcej, tutaj ogarnąć coś szybciej, więc to też byłaby cecha, która pomaga ogólnie awansować i ogólnie rozwijać tak naprawdę.

Kolejnym tutaj tematem czy cechą, którą bym wymienił, to jest motywacja do rozwoju i ciekawość, gdyż ta ciekawość i ta motywacja pchają nas do spróbowania nowych rzeczy. Czyli np. spróbujmy tego nowego frameworka, który się pojawił. Może on jeszcze jest w jakiejś wczesnej fazie, może jeszcze go nie zastosuję w projekcie, ale już poznam sposób, podejście, jaki tutaj twórcy proponują do rozwiązywania też jakichś problemów. Jakichś problemów, czyli tutaj w tym konkretnym przypadku, jeśli to jest framework do testów, to jest rozwiązywanie kwestii zapewnienia jakości w projekcie, czy tam zapewnienie, żeby regresja nie występowała w naszym produkcie, załóżmy. Więc ta ciekawość i motywacja właśnie do rozwoju.

Dalej proaktywność i inicjatywa, czyli chociażby właśnie branie jakichś nowych zadań, czy dzielenie się chociażby wiedzą, czyli pisanie na blogach, czy występowanie w jakichś spotkaniach wewnętrznych, firmowych, gdzie coś przedstawiamy, czy jakiś show and tell tak zwany.

A dalej idąc, kształtowanie zdolności przywódczych, to też może się przydać w zależności od tego, jeśli celujemy w taką rolę bardziej liderską, seniorską w zależności od organizacji, to też pielęgnowanie takich zdolności przywódczych, budowanie autorytetu może się przydać.

Inną cechą jest szybka adaptacja do zmian. Rynek ewoluuje, projekty się zmieniają tak naprawdę w zależności od organizacji, ale czasami przeskakujemy pomiędzy projektami co pół roku, bo jest taka potrzeba, bo w innym projekcie jesteśmy potrzebni, musimy wesprzeć zespół. Jest totalnie inna technologia, totalnie inne narzędzia, no i to od nas zależy, jak szybko się wdrożymy i czy w ogóle będziemy chcieli się wdrożyć. Myślę, że to jest kluczowe, że jednak jest ta otwartość na to jednak wejście, podjęcie tego wyzwania, na nauczenie się właśnie tego czegoś nowego, tych nowych narzędzi czy nowego podejścia.

I na koniec jeszcze jakieś zdolności analityczne, rozwiązywanie problemów, czyli np. testujemy coś, coś jakoś działa, ale teraz zadajemy te pytania, czy to poprawnie działa, czy to faktycznie rozwiązuje ten problem, może coś w dokumentacji nie jest dobrze opisane, to jednak jesteśmy tutaj ciekawi i analizujemy, jak to wygląda, czy kontaktujemy się z klientem, czy np. umiejętności drążenia problemów, czyli mamy na przykład problem, przycisk nie działa na stronie i teraz nie robimy czegoś takiego, nie sugerowałbym, żebym tak, czegoś takiego, że zgłaszamy błąd, przycisk nie działa i koniec, tylko bardziej na zasadzie zgłaszamy błąd, gdzie informujemy albo drążymy ten problem: okej, przycisk nie działa, bo pod spodem po rest upie np. leci 403, bo token autoryzacji nie jest dołączony albo coś, czyli dodajemy trochę więcej kontekstu, a jeszcze lepiej np. jak jakiś kawałek kodu, albo konkretnie kawałek kodu wskazujemy, gdzie to występuje.

Tylko to są już takie bardziej zamaskowane rzeczy. Jednak to pokazuje taką właśnie chęć dążenia i drążenia, co jest przyczyną tego problemu. Tutaj też ważna uwaga do słuchaczy. Nie spędzajmy nad tym całego dnia. Załóżmy sobie jakiś timebox, 15 minut. Jeśli w ciągu 15 minut nie jesteśmy w stanie dojść do przyczyny problemu, to może warto jednak zapytać kogoś o pomoc.

 

To jest, myślę sobie, też jedna z umiejętności właśnie miękkich, żeby potrafić tym czasem dobrze zarządzać, ale też o tym tutaj już mówiłeś. Mówiłeś też o tym, że zwłaszcza juniorzy mają taką tendencję do przywiązywania dużej, może zbyt dużej roli do właśnie umiejętności technicznych, że skupiają się na rozwoju tylko tej części tych swoich kompetencji.

Jednak patrząc na dziedzinę, w której się poruszamy, jakby nie było umiejętności techniczne, kompetencje twarde są tym, co służy nam do wykonywania codziennej pracy. Więc chciałbym Cię zapytać, właśnie myśląc o rozwoju kariery, o tym przechodzeniu od juniora do seniora, jaką rolę, jaką wagę przywiązywałbyś do umiejętności technicznych?

 

Jeśli chodzi ogólnie o umiejętności techniczne, powiedziałbym, że są ważne. I teraz tak trochę doprecyzowując. Na początku bardzo często, jak juniorzy zaczynają pracę, to umiejętności techniczne są ważne, ale na poziomie znajomości różnych narzędzi, czy ogólnego sposobu działania aplikacji, na zasadzie np. REST API jak działa, czym jest w ogóle. A jeśli chodzi o narzędzia, to np. Postman, Swagger albo Chrome DevTools. Kilka takich podstawowych narzędzi, z których na co dzień się po prostu korzysta, w zależności od projektu, ale to są takie najczęściej wykorzystywane.

Ten poziom wiedzy technicznej myślę, że od samego początku gdzieś będzie towarzyszył juniorom w rozwoju. Idąc dalej, to umiejętności techniczne są coraz ważniejsze. Jak mamy to REST API, to później np. na poziomie seniora to już wiemy, jak ono konkretnie działa, co tam pod spodem się dzieje, jakie są możliwe zapytania. Sami jesteśmy w stanie nawet napisać jakiś serwis do REST API czy testy automatyczne, które się komunikują z tym REST API, bo tak naprawdę dzięki takim testom, nawet nie tyle testy, nawet same skrypty, które możemy napisać, one już nam znacznie mogą usprawnić pracę, przyspieszyć to, co robimy na co dzień. Pozwalają nam np. sprawdzić jakieś bardziej wysublimowane przypadki, więc to zaczyna być niezbędne.

Też o, przykładowo CI/CD, takie modne słowo, gdzieś tam koło DevOpsa sobie krąży. Są różne narzędzia wspomagające proces CI/CD, np. GitHub, GitLab, GitHub Actions, GitLab CI, Azure DevOps, Jenkins, bardzo popularny nadal, Na początku, jak jesteśmy juniorem, to okej, wiemy, że jest takie narzędzie, tam coś potrafimy wyklikać, ale na poziomie seniora zazwyczaj może być od nas oczekiwane, że jesteśmy w stanie postawić takie całe narzędzie, skonfigurować je, przygotować coś w pipeline, które tam są, podpiąć testy automatyczne itd.

Więc z czasem nabiera to na wadze. I tutaj, co ważne, jeszcze bym zaznaczył, że trochę powróciłbym do naszego to zależy od organizacji, bo to mocno zależy od organizacji. Czasami jest tak, że jak trafimy do organizacji, to może umiejętności techniczne mogą się nie wydawać zbyt ważne. Na zasadzie my nawet bez tej wiedzy programistycznej, bez tej wiedzy o CI/CD jesteśmy w stanie gdzieś tam dojść do tego seniora.

I tutaj bardzo ważne jest, żebyśmy się orientowali, co jest ważne na rynku, jak wygląda ten poziom senior w innych miejscach. Czyli jeśli w naszej organizacji to programowanie nie jest ważne, ale wszyscy piszą, że to programowanie jest ważne, to może być tak, że nasza organizacja jest w jakiś sposób wyjątkowa i jeśli coś się złego stanie, np. redukcje, które były ostatnio bardzo częste, to my nagle kończymy bez projektu, bez firmy i bez tych ważnych umiejętności, które są, jakby nie było, wymagane na rynku i w każdej innej organizacji.

Więc tutaj bardzo bym też przestrzegał albo sugerował właśnie takie rozdanie, co jest ważne i też rozwijanie się w tę stronę, nabywanie tych umiejętności, które na rynku mówią, że są ważne i wykorzystywane powszechnie w projektach.

 

Pojawia się pytanie, ile czasu to wszystko zajmuje, czyli ile przeciętnie może nam zająć przejście od tego pierwszego kroku, od rozpoczynania jako junior i dojścia do etapu seniora. Oczywiście wiadomo tutaj po raz kolejny, że to zależy, ale gdybyś mógł jeszcze wskazać, jakie czynniki, jakie elementy mogą ten czas skrócić, a jakie ewentualnie wydłużyć?

 

Bardzo dobre pytanie. Tak jeszcze nawiązując do czasu, to on tak równie jest podawany od 5 do 8 lat zazwyczaj, to się można gdzieś spotkać w różnych źródłach. I ten czas dużo zależy właśnie od wielu czynników, m.in. od naszego doświadczenia zawodowego. W ilu projektach byliśmy i jakie rzeczy tam realizowaliśmy, jak duże były te projekty, czyli czy to był projekt dwuosobowy, czy to był projekt siedemdziesięcioosobowy, i długość naszego przebywania w tych projektach, bo niekiedy decyzje, które podejmujemy dzisiaj, będą mieć swój wynik dopiero za np. dwa lata. Więc jeśli my nie dotrwamy przez dwa lata do tych decyzji, to może nam po prostu dużo doświadczenia i wiedzy umknąć, więc warto też być w niektórych projektach trochę dłużej.

Poza tym umiejętności techniczne, czyli ta wiedza na temat właśnie, jak wspominałem wcześniej o oprogramowaniu, o CI/CD, chmurze, umiejętności miękkie, proaktywność, inicjatywa. Jeśli nie będziemy po prostu korzystać z tych rzeczy, nie będziemy ich wykorzystywać, nie będziemy ich brać pod uwagę, to dojście do tego seniora może nam nam zająć dłużej.

Tutaj też znowu w zależności od organizacji, w niektórych organizacjach jest tak, że minimum to jest pięć lat. W zasadzie nie ma pięciu lat, to nie zostaniesz seniorem i czasami musimy się z tym pogodzić, ale też bym podszedł do tego, że good, to mamy możliwość po prostu na wykorzystanie tego czasu, to może kolejny projekt, rozjrzyjmy się za kolejnym projektem, który możemy realizować, może wyciągnijmy więcej z tego projektu, bo czas tak naprawdę tutaj może grać na plus, będziemy mieć po prostu więcej tego doświadczenia, będziemy mogli więcej przedstawić na tej rozmowie, czy to właśnie rekrutacyjnej, czy poziomującej, więc warto tutaj jak najbardziej chwytać się po prostu większej liczby rzeczy.

 

Wrócę znowu do tego tematu umiejętności technicznych, kompetencji technicznych. Mówimy, że ich rozwój jest bardzo istotny, niezależnie od tego, na jakim etapie tej naszej kariery jesteśmy. Wspominałeś też dużo o umiejętnościach miękkich, o komunikacji, o wchodzenie w interakcje z innymi po to, żeby nad wspólnym celem, projektem pracować.

I w momencie, kiedy już zbliżamy się powoli do tego stanowiska seniora, to coraz więcej tych naszych odpowiedzialności przesuwa się z działki technicznej w kierunku być może liderskim, być może menadżerskim. Oczywiście to znowu zależy od organizacji, niektóre dosyć duże organizacje potrafią mieć kilka jeszcze pośrednich różnych ról, które właśnie w pełni są skupione na tego typu odpowiedzialnościach, ale w nieco może mniejszych albo inaczej zorganizowanych organizacjach faktycznie senior przejmuje już część odpowiedzialności za zespół, chociażby w postaci mentoringu, czy w postaci jakiegoś dzielenia się wiedzą, układania procesów, różnie to może wyglądać.

Czy według Ciebie równoważne jest z zostaniem seniorem to, że będziemy odpowiedzialni za zespół, za inne osoby, czy też może niekoniecznie i jesteśmy w stanie znaleźć takie projekty, gdzie będziemy cały czas kontynuowali tylko rozwój techniczny?

 

Bardzo często tak. Jeśli zostajemy seniorem, to może to po prostu być od nas wymagane, że po prostu mamy zarządzać, zarządzać to może złe określenie, ale przewodzić, kierować naszym zespołem, aby osiągnąć jakieś wyniki. W czym to dużo też zależy od samego projektu, nawet nie tyle organizacji, bo czasami po prostu trafiamy do projektu, który się składa np. z pięciu seniorów i jeden z nich po prostu ma tę rolę taką liderską.

Więc wtedy, powiedzmy, te odpowiedzialności związane właśnie z prowadzeniem zespołu jakby odchodzą. My nie musimy się aż tak tym zajmować, przy czym też bym tutaj podkreślił, że to nie chodzi o to, że teraz my możemy powiedzieć, dobra to ja teraz w ogóle nie zarządzam zespołem, ja w ogóle zapominam o moich umiejętnościach miękkich i porzucam je, ale o to, że nie musimy może formalnie pełnić tej roli, jednak z racji, że jesteśmy mimo wszystko tym seniorem, musimy, znaczy oczekiwałbym od tego seniora, że będzie wspierał pozostałych członków zespołu w pracy.

Czyli np. jeśli tamten senior zachoruje, będzie na urlopie czy cokolwiek, to my jesteśmy w stanie przejąć jego obowiązki, w jakimś stopniu jesteśmy w stanie poprowadzić ten projekt dalej, ale także senior to też postawa pewna, więc też oczekiwałbym tutaj, że osoby na stanowisku seniorowym będą miały tę postawę, czyli będą miały komunikację na odpowiednim poziomie chociażby, czy będą w odpowiedni sposób podchodziły do feedbacków, rozmów z klientem, rozwiązywania problemów, raportowania z odpowiednią szczegółowością tych błędów, które gdzieś tam są, czy realizowania zadań, które nie są stricte techniczne, czyli to nie jest, że sobie siedzimy i kodzimy. Więc tutaj potrzebujemy bardziej do tego w ten sposób.

Czyli ogólnie przywództwo, odpowiedzialność. Powinniśmy mieć takie umiejętności i powinniśmy być gotowi je wykorzystać w pewnym momencie.

 

Okej, to na koniec, Krzysztof, chciałbym Cię jeszcze zapytać tak przyszłościowo, na jakie Ty kompetencje byś postawił, żeby ten awans przyspieszyć w przyszłości? Co według Ciebie warto tutaj rozwijać, na jakie obszary stawiać, aby mieć większe szanse na awans w przyszłości właśnie w testowaniu oprogramowania?

 

Ja bym podzielił te kompetencje na dwa poziomy. Jeden taki niskopoziomowy, czyli umiejętności bardziej techniczne, ale ogólnie automatyzacja testów, programowanie, to cały czas jest potrzebne, cały czas to jest wymagane. Od tego kodu jeszcze się nie odpędzimy, AI jeszcze nam nie zabiera pracy i myślę, że jeszcze przez długi, długi czas nie zabierze nam pracy, a może nam ją przyspieszyć.

Ale jak jesteśmy przy programowaniu, to też różnego rodzaju umiejętności związane z DevOpsem i CI/CD, obsługa tych narzędzi, konfiguracja pipeline’ów. To też jest bardzo ważne i to nie tylko DevOpsi robią, to też testerzy powinni robić. To jest spotykane w projektach, to też jest od testerów i od QA, QE wymagane.

Różnego rodzaju specjalizacje, bezpieczeństwo, wydajność. Teraz szczególnie w dobie, gdy AI się rozwija, gdy mamy teraz super wydajne karty graficzne i wszystko jest po sieci, to to bezpieczeństwo należy szczególnie zadbać i o wydajność, gdy wszystko jest właśnie w chmurze, gdy wszystko jest przesyłane po sieci, więc wydajność jest też kluczowym, jakby jednym z kluczowych punktów, tak naprawdę, w tworzeniu oprogramowania.

Sztuczna inteligencja, o której wspomniałem, i machine learning. Nie tylko w testowaniu, ale i ogólnie, jak możemy wykorzystać te nowe narzędzia w pracy, jak one mogą nam przyspieszyć pracę, trochę jak działają, a może w kontekście samego testowania, jak chociażby testować, bo teraz jest coraz więcej narzędzi, które są oparte o AI, no a ktoś musi je przetestować, ktoś musi zobaczyć, czy te wyniki, które dostajemy, są poprawne. Bo już było parę takich afer, które gdzieś tam występowały w AI i dosyć mocno zahaczało o różne kierunki, które nie były zbytnio prawidłowe, poprawne. Więc to też jest bardzo ważne, żeby umieć to testować chociażby.

Jak tutaj mówimy właśnie o danych, to analiza danych, Big Data, te tematy też będą mniej bądź bardziej popularne i to też może być fajna działka, jeśli kogoś to interesuje, to myślę, że tutaj nie zabraknie pracy.

To były takie, powiedzmy, niskopoziomowe, techniczne bardziej tematy, ale też nawiązałbym znów do tych tematów czy umiejętności miękkich, czyli komunikacja, przywództwo, zarządzanie czasem i priorytetami, bo bez tego nie sprzedamy pomysłów, jak już wcześniej wspominałem, czy chociażby nie będziemy w stanie zrealizować wszystkich naszych planów czy celów, nie chcę powiedzieć tutaj wszystkich, ale większości, albo tych chociażby, które mamy zamierzone i które są główne, bo jednak planowanie to chodzi też o czas, chociażby czas dla rodziny.

Adaptacja, ciągłe uczenie się, elastyczność, śledzenie trendów, bycie na bieżąco z najnowszymi zmianami w branży, czy gotowość chociażby do szybkiego nauczenia się i wdrożenia się w jakąś technologię, w jakieś narzędzie, które zostało wprowadzone właśnie teraz w organizacji. Organizacja ma, nie wiem, załóżmy Playwrighta, jedno z takich popularniejszych narzędzi, i trzeba się tego nauczyć, bo organizacja ma klientów, którzy chcieliby z tego skorzystać, albo my widzimy w tym dużą korzyść, więc to też jest, myślę, ważne.

Ciekawość, chęć odkrywania nowych rzeczy, też trochę tu się wiąże z tą ciągłą nauką, proaktywność, no i też, myślę, ten networking cały czas, ta marka osobista, to też, myślę, jest ważne, to też tak jak wcześniej wspominaliśmy, nie jest to coś, co się wiąże tylko i wyłącznie z wystąpieniem jakimś publicznym przed milionową widownią, tylko to są też takie małe akcje, blogi, nie blogi, więc tutaj myślę, każdy chce coś znaleźć, a później progresowanie. Jak już zaczniemy pisać bloga, to znacznie łatwiej jest pójść na jakiś mały meetup i nawet zrobić wystąpienie, niż jakby od razu skoczyć w wystąpienie.

Więc małymi krokami możemy naprawdę ogromne rzeczy zrealizować i co ważne, te wszystkie w sumie punkty, które tutaj wymieniłem teraz, to nie jest tak, że z dnia na dzień jesteśmy w stanie się tego nauczyć, tylko to jest czasami naprawdę wiele miesięcy, jeśli nie lat pracy, chociażby marka osobista. To jest coś, czym myślę, że warto zacząć się tym interesować. Czym wcześniej się zaczniemy interesować, tym później będzie nam łatwiej, bo to są naprawdę miesiące, jeśli nie lata budowania tutaj jakiegoś naszego obrazu.

Tak samo z innymi umiejętnościami. Kompetencje miękkie. Do dzisiaj się wielu tych rzeczy uczę, chociażby właśnie priorytetyzacja, realizacja zadań i zarządzanie moim czasem.

Ja bym podzielił te kompetencje na dwa poziomy. Jeden taki niskopoziomowy, czyli umiejętności bardziej techniczne, ale ogólnie automatyzacja testów, programowanie, to cały czas jest potrzebne, cały czas to jest wymagane. Od tego kodu jeszcze się nie odpędzimy, AI jeszcze nam nie zabiera pracy i myślę, że jeszcze przez długi, długi czas nie zabierze nam pracy, a może nam ją przyspieszyć.

Ale jak jesteśmy przy programowaniu, to też różnego rodzaju umiejętności związane z DevOpsem i CI/CD, obsługa tych narzędzi, konfiguracja pipeline’ów. To też jest bardzo ważne i to nie tylko DevOpsi robią, to też testerzy powinni robić. To jest spotykane w projektach, to też jest od testerów i od QA, QE wymagane.

 

Tak, ja się absolutnie po tym wszystkim podpisuję. Warto może jeszcze podkreślić, że te wszystkie kompetencje, bo większość z nich cały czas się rozwija, rzadko która raz nabyta zostaje z nami już do końca kariery, więc ta otwartość umysłu i ten odpowiedni mindset jest tutaj takim kluczowym elementem.

Świetnie. Swoim bogatym doświadczeniem i spostrzeżeniami co do awansu od juniora do seniora na ścieżce testowania oprogramowania dzielił się dzisiaj z nami Krzysztof Kijas. Krzysztof, bardzo Ci dziękuję za poświęcony czas i za tę rozmowę. 

 

Ja również bardzo dziękuję. 

 

Powiedz jeszcze, proszę, na koniec, gdzie Cię możemy znaleźć w internecie, gdzie możemy słuchaczy odesłać? 

 

Powiedzcie mi, znaleźć na stronie jaktestować.pl albo na LinkedIn, po prostu wpisując Krzysztof Kijas. 

 

Oczywiście linki będą w notatce do odcinka. Jeszcze raz Ci, Krzysztof, bardzo dziękuję. Udanego dnia! Do usłyszenia! 

 

Dzięki wielkie. 

 

I to na tyle z tego, co przygotowałem do Ciebie na dzisiaj. Więcej wartościowych treści znajdziesz we wcześniejszych odcinkach. Masz pytania? Napisz do mnie na krzysztof@porozmawiajmyoit.pl lub przez social media. Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o ścieżce kariery testera oprogramowania. 

Do usłyszenia w następnym odcinku!

Cześć!