Wywiad z Markiem

Wstęp

Wyobraź sobie, że uciekasz przed policją, a ta nagle zaczyna do siebie strzelać… Dzisiejszym gościem jest Marek, który prosił o anonimowość. Marek swoją karierę rozpoczynał w gamedevie, podobnie jak Amir. Nie tylko testował gry, ale pracował również jako Team Leader! Dowiedzmy się dziś jak wygląda świat gamedevu oczami Marka.

Wywiad

Adam Gola: Cześć, Marku. Dziękuję Ci bardzo za udział w tym wywiadzie! Może na początek napiszesz parę słów o sobie?

Marek: Hej, witam Cię serdecznie i witam wszystkich, którzy to czytają! Pomysł wywiadu wydał mi się ciekawy, mam nadzieję, że taki wyda się też innym, a może nawet kogoś zainspiruje. Ja mam na imię Marek, pracuję w QA już od kilku lat. Obecnie na stanowisku Quality Assurance Engineer. Zajmuję się testowaniem webówek, mikroserwisów. Aktualnie działamy nad pewnym rozwiązaniem chmurowym.

Wcześniej jednak, przez parę lat, byłem leadem zespołów testujących, a jeszcze wcześniej testowałem gry i aplikacje mobilne. Także myślę, że rozstrzał w doświadczeniu mam całkiem spory.

Adam: Spisaliśmy się przez jedną z grup branżowych na Facebooku. Napisałeś wtedy, że masz dziewięć lat doświadczenia w testowaniu gier. Dziewięć lat! Niesamowity wynik. Zanim w ogóle wejdziemy w ten świat i szczegóły, jak oceniasz swoją karierę przez pryzmat czasu? Były to owocne zawodowo lata?

Marek: Wiesz… Pośród tych dziewięciu lat, siedem spędziłem w pracy z grami. W tym trzy jako tester, a cztery jako lider zespołu. Dopiero w ostatnich latach zmieniłem drogę na zapewnianie jakości aplikacji bardziej biznesowych.

Co do mojej wcześniejszej pracy… Uważam, że były dobre i złe strony. QA w świecie gamedevu to jeden z najlepszych i najbardziej dostępnych furtek do wejścia w świat QA lub szeroko pojętego IT, moim zdaniem. Praca może być naprawdę fajna, ze świetną atmosferą, świetnymi ludźmi. Z drugiej strony uważam, że jeśli ktoś chce iść “dalej” warto wiedzieć kiedy ruszyć do przodu lub zacząć poznawać nowe tematy. Ja mam wrażenie, że w “grach” zasiedziałem się trochę zbyt długo, ale nie narzekam. Na początku kariery załapałem i poznałem narzędzia, które często tak bardzo przydają się w naszej branży, jak Jira, Confluence, Testrail… I wiele innych.

Potem jako Lead było to wyzwanie dla moich kompetencji miękkich, społecznych, organizacyjnych. Była to rola znacznie bardziej wymagająca, ale też w pewnych obszarach o wiele bardziej rozwijająca.

Z Leada natomiast poszedłem w stronę QA Engineera i ani trochę nie żałuję tego wyboru. Obecnie sprawdzam się – jak wspomniałem wcześniej – w aplikacjach bardziej biznesowych, wprowadzam na projekt samo pojęcie QA, nadzoruję w pewnym sensie procesy, uczę się automatyzacji. Rola w pewnych aspektach łatwiejsza, w pewnych trudniejsza. Do gamedevu wiem, że już nie wrócę, ale i tak jestem wdzięczny za ten czas i doświadczenia. W końcu od tego zaczęła się moja zawodowa zabawa.

Adam: Czyta nas wiele osób. Są osoby, które dopiero się przebranżawiają i chcą w ogóle zacząć od testowania gier. Polecasz tę ścieżkę? Co według Ciebie trzeba dziś umieć, aby w ogóle wejść do branży gamedevu? I czy warto, Twoim zdaniem?

Marek: Wiesz co, wtedy moja rola ograniczała się do najzwyczajniejszego manualnego testowania. Natomiast czy polecam tę ścieżkę? Jak najbardziej, jeśli ktoś widzi to jako swój “entry point” lub pasjonuje go taka praca! Z pewnością jednak nie polecam tej drogi na całe życie. Jak wspomniałem, ja sam uważam, że zdecydowanie za długo przesiedziałem w roli testera gier lub leada. Myślę, że jest to fajna opcja na “rozruszanie się” w branży. Złapanie podstaw. No i zakładając, że kręcą Cię takie rzeczy, masz do czynienia z nowinkami technicznymi w świecie gamerskim.

Twoją ulubioną konsolą jest Playstation? Możesz jako jeden z pierwszych “pograć” na PlayStation 5 (wtedy jeszcze całkiem nowiuśkie).

Nie masz miejsca na VRa? Możesz go doświadczyć, jeśli taki projekt akurat się pojawi.

Może być z tym dużo zabawy, ale i ogólnego obycia z tym jak wyglądają konsole, modele smarphone’ów itp. Nie wszystko może przydać się w późniejszej pracy QA, ale to na pewno coś.

A i tak myślę, że nadal trzeba samemu mocno się uczyć i dokształcać. Ale tak jak i my wszyscy. W świecie QA praktycznie nie ma contans 😉

Adam: Swoją drogą, gdy ktoś mówi o ścieżce w gamedevie, prawie zawsze mówi się o tym jak o “początkowym wyborze”. Coś na start. Ty również o tym wspomniałeś. Namieszajmy jednak, odwróćmy to. Co jeżeli ktoś ma osiem lat doświadczenia jako QA i chciałby wejść w świat gier? 

Marek: Ciekawe pytanie. Spotkałem się z mnóstwem ludzi, którzy z gamingu poszli dalej w branżę. Nigdy odwrotnie. Myślę, że to coś mówi. O ile nie jesteś super-pasjonatem, to myślę, że jednak pójście w ścieżkę QA to kolejny krok.

Zwykle wtedy taka osoba spotyka się z małym murem – pojawiają się zupełnie nowe pojęcia, sposób pracy, narzędzia. A stare definicje takie jak np. “testowanie regresywne” zyskuje zupełnie nowe znaczenie. Spotykałem się z ludźmi, którzy pracowali w gamedevie jako tester kilka lat, a przychodzili testować webówkę i nie mieli pojęcia co to jest testowanie API, co to są DevToolsy itp.

Ja nie miałem aż tak źle, trafiłem na bardzo otwartą firmę, ale i tak było mnóstwo nauki z mojej strony. Nauki i stresu, czy dosłownie nie umiem za mało. Jest też pewna istotna sprawa, z której powodu nie sądzę, żeby ludzie z branży QA przeszli do gamedevu, mając już doświadczenie. Nie oszukujmy się, kwestia finansowa jest bardzo ważna. Niestety, w gamedevie zarabia się dosłownie grosze w porównaniu do innych stanowisk. Nie chcę nikogo straszyć, ale to także trzeba brać pod uwagę. Zapewne w studiach wewnętrznych QA jest lepiej, ale tu nie mam doświadczenia, więc nie będę się wypowiadał.

Jeśli jednak jesteś pasjonatem, nie masz wysokich zobowiązań finansowych, jesteś studentem lub szukasz łatwego wejścia do QA i gamedevu, myślę, że takie coś to idealna furtka. Mam zresztą kolegę z pracy, który tak jak ja, zaczął jako tester gier, potem awansował na leada. Obecnie ze swoim doświadczeniem i wiedzą, mógłby spokojnie iść do innych firm, ale uparcie chce zostać przy grach – bo to go pasjonuje, bo lubi, bo atmosfera mu odpowiada, bo poduszka finansowa nie jest dla niego takim problemem. I to też jest ok.

Adam: Jak wyglądał taki typowy dzień w pracy? Przychodzisz sobie rano do pracy i… co dalej? Od razu odpalasz jakąś grę czy może trzeba było najpierw uzupełnić dokumentację? Jak to w ogóle wyglądało?

Marek: Kwestia dokumentacji i organizacji pracy bardziej spoczywała na mnie jak już byłem leadem. Wtedy, gdy przychodziłem do pracy, faktycznie musiałem zadbać o to, by każdy tester miał potrzebne narzędzia i inforacje. Przypisywałem taski. Potem zaczęła się lawina maili i raportów do klienta, do przełożonego, jak i planowanie zespołu, sprzętu itd. Przygotowanie i rozpisanie dokumentacji, tworzenie test case’ów… lub chociaż przekazanie dokumentacji i testów, jeśli te już zostały przygotowywanie przez klienta, którym mógł być developer, producenci lub nawet wewnętrzne QA.

Praktycznie nie istniało w pracy coś takiego jak Agile (chyba, że zespół klienta tak pracował) i w większości czasu byłem takim jakby pomostem w komunikacji klient -> zespół.

Wiem jednak, że pytanie jest bardziej skierowane na pracę testera. Bo i ona pewnie wydaje się ciekawsza 🙂

Jako tester, istotnie, przychodziło się do pracy, zapoznawało z taskami na dzisiejszy dzień, dostawało najczęściej nowego builda lub wersję oprogramowania, włączało konsolę/PCta/wybranego smartphone’a i się jechało z zadaniem…

To, jakie były zadania zależało całkowicie od projektu. Czy było to po prostu “granie w grę”, bardziej pod pojęcie testów eksploracyjnych, przejścia całej gry jak najszybciej – tzw. happy path – jak również testowanie konkretnych wytycznych – np. czy statystyki postaci się zgadzają, czy numery i algorytmy są takie jak w założeniach, analiza poprawności animacji, grafiki czy fizyki. Często pełne retestowanie wcześniej zgłoszonych błędów i pełna regresja w grze po aktualizacji.

Czasem pracy było na 12 godzin i ledwo można było się zmieścić w zwykłym dniu pracy, czasem po 2 godzinach tester wyrabiał się ze swoim zadaniem i czekał na następne lub szukał błędów na własną rękę.

Adam: Z mojej inżynierki i magisterki pamiętam Unreal i Unity. Pracowałem na nich przy pracach dyplomowych. To ten kierunek czy raczej pracowałeś na czymś autorskim?

Marek: Tak jest. Jak najbardziej mieliśmy gry, wykorzystujące te silniki. Ba, nawet miałem w zespole testerów, którzy sami w domu zapoznawali się z nimi – jako hobby. Co potem, podczas testowania, dawało fajne rozumienie tego jak silnik działa i skąd błędy mogą się brać. Choć oczywiście naszym zadaniem nie była naprawa błędów, ani wskazanie ich źródła, zrozumienie na pewno przyspieszało proces.

Przy czym też w mojej pracy nie mieliśmy nigdy dostępu do kodu, ani wewnętrznej mechaniki gry. Testy były całkowicie “czarnoskrzynkowe” i opierały się na “froncie” gry, że tak powiem.

Adam: Przy jakich gatunkach gier pracowałeś? I czy to były Twoje gatunki czy raczej musiałeś się zmuszać do ich testowania? I ile czasu zajmowały testy takiego jednego tytułu? Dla przykładu, osobiście nie przepadam za strategiami czasu rzeczywistego i nie wyobrażam sobie klepać w to po kilka godzin dziennie przez pół roku. O zgrozo…

Marek: Właśnie w pewnym sensie odpowiedziałeś, na czym polega praca testera gier 😀 Olbrzymia część tej pracy to właśnie testowanie nie tych tytułów lub nawet gatunków, które się lubi, tylko to, co akurat przyjdzie od klienta… Jest to praca i tak właśnie przez 8 godzin pracuje się nad danym tytułem. Często nawet nie przypomina to “grania” per se, tylko wykonywanie odpowiednich akcji i porównywanie ich z tabelką w excelu bądź case’u w Testrailu 😀 Wspomniałeś strategie… Ja dosłownie modliłem się, żeby nie musieć ich prowadzić… Dla mnie gra strategiczna to dosłownie najgorszy typ gry do testów, ale oczywiście w moim zespole były osoby, które to uwielbiały.

Obecnie nie gram za dużo, natomiast miałem w życiu moment, gdy faktycznie to robiłem i było to zupełnie niezależne od testowania w pracy.

Zakładam, że prędzej czy później padnie legendarne pytanie, czy testując 8 godzin gry, ma się chęć jeszcze grać prywatnie. (oj, będzie to pytanie! 😀 – dop.) I myślę, że każdy tester odpowie tak samo. Ja odpowiem w ten sposób… Prywatnie lubię czasem popykać w platformówki lub RPG. W pracy na dziesiątki projektów, trafiła mi się chyba tylko jedna platformówka. Bardzo miły tytuł zresztą. Jednak lwia część projektów, z którymi miałem do czynienia (a były to strategie, survivale, zagadki/krzyżówki, mobilki typu Angry Birds lub match3, Pokery, kasyna, nie kasyna), mógłbym wymienić chyba tylko z 2 czy 3 tytuły, w które bym pograł prywatnie. I to też raczej nie na zasadzie “bardzo chcę to w grać”, ale raczej “zabiję na tym trochę czasu”. To jest raczej tak, jak przy testowaniu każdego produktu. Ta aplikacja jest, masz określone zadania do wykonania i musisz je dostarczyć.

Co do pytania “ile zajmowały testy”… Tu bardzo wiele zależy od decyzji góry, klienta, budżetu. Miewałem projekty, które trwały półtora roku. Miewałem takie, które trwały 4 dni. Miewałem takie, które wracały cyklicznie co miesiąc na 2 tygodnie na przykład. Często sytuacja dynamicznie się zmieniała i projekt ulegał przedłużeniu lub nagłemu skróceniu.

Ja ze swej strony jako lead, razem z project managerem, mogliśmy zawsze dawać feedback, sugerować w jakim stanie jest produkt, jaki jest nasz – QA – punkt widzenia na dalsze postępowanie. Ostateczna decyzja zawsze jednak należała do klienta.

Adam: Realnie, ile czasu dziennie (albo w skali tygodnia/miesiąca) testowałeś gry, a ile czasu spędzałeś na spotkaniach i nad dokumentacją? Istniała w ogóle dokumentacja?

Marek: I znów odpowiedź będzie brzmiała “to zależy”. Każdy projekt mógł się rządzić swoim flow i zadaniami. Choć nasze procedury były stałe, wygląd pracy zawsze naginało się trochę do potrzeb klienta i produktu.

Adam: Parę lat temu czytałem w jednym z wywiadów, że ktoś przez osiem godzin w Wiedźminie 3 wchodził i schodził z konia w różnych kombinacjach, uzbrojeniu i tak dalej. Czy to tak wyglądało czasami czy raczej podkolorowane?

Marek: He he… Myślę, że tego typu historie są ociupinkę egzaltowane, tak jak z uderzaniem przez 8 godzin w drzewo. Ale też jest w tym ziarnko prawdy. Wyobraź sobie przykład, że masz daną broń i musisz ją przetestować. Musisz popatrzeć po wszystkich numerkach jakie ma, ile zadaje, jak wzmacnia daną postać, spojrzeć na animację broni, particle, jej interakcję z innymi przedmiotami, ze ścianami, z NPCtami, czyli postaciami w grze… Przykłady można mnożyć.

Lub też dostajesz ekran główny z gry z przeróżnymi opcjami takimi jak Nowa Gra, ładowanie zapisanej gry, sterowanie, opcje audio i video… I twoim zadaniem jest odpalić grę w 22 językach i krok po kroku popatrzeć, czy wszystko jest wyświetlone, czytelne, mieści się na ekranie itp. W sumie cofam teraz swoje słowa, być może te historie nie są egzaltowane, a w grze tak dbającej o szczegóły, jak Wiedźmin 3, faktycznie takie zadania miały miejsce!

Tak, oczywiście, testowanie gry może być momentami bardzo nużące i repetytywne. W innych sytuacjach może być naprawdę wciągające, a nawet zabawne. Najzabawniejszy moment w mojej karierze był wtedy, gdy na zasadzie prezentowanego przykładu odpaliłem grę w języku polskim i okazało się, że developerzy postanowili przetłumaczyć opcję “Back”, jako “Plecy”. Albo “Settings” jako “Sterownica”.

Innym razem, podczas rozgrywki, AI policji nagle zaczęło strzelać do samych siebie. Przejeżdżający radiowóz można było zacząć klonować w nieskończoność… To są smaczki w pracy, które chyba już zawsze zostają w pamięci 😀

Adam: Czy testując gry ma się realny wpływ na wygląd produktu końcowego? Jak wygląda współpraca z twórcami i na jakim etapie jest ona zapoczątkowana? Byłeś w napisach końcowych? 🙂

Marek: Tak 🙂 W napisach końcowych da się znaleźć nazwisko moje i moich kolegów, choć przyznam szczerze, nigdy nie było to dla mnie jakimś super powodem do dumy, albo powodem do chwalenia się przed innymi. Dla mnie to dobrze wykonana praca i tyle.

Ale nie ukrywam, widząc docenienie tejże pracy przez klienta jest miłe.

Niestety byłem świadkiem praktyk w tej branży, gdy w napisach końcowych gry pojawia się jedynie nazwisko project managera, który mógł nawet gry nie widzieć na oczy. Albo pojawiła się tam po prostu nazwa firmy, a realni testerzy z krwi i kości mogli liczyć jedynie na “uśmiech prezesa”. Na szczęście takie przykłady to rzadkość.

Współpraca zaś – tak jak zahaczyłem wcześniej – bardzo zależy od projektu. Miałem klientów, z którymi kontakt ograniczał się do jednego maila dziennie, a my, jako eksperci w dziedzinie QA byliśmy odpowiedzialni za nadanie sobie zadań i oszacowaniu, co jest do zrobienia. Bywały projekty, gdzie kontakt był non stop na Slacku, Teamsach, czy innym komunikatorze. Czasem zdzwanialiśmy się raz tygodniowo. Czasem 3 razy dziennie.

I tak jak mówiłem, oczywiście lead i project manager mogą doradzać, dawać feedback, opiniować jak i ile pracy wymaga jeszcze dana gra, ale klient w każdym momencie mógł podziękować za współpracę lub przedłużyć ją jeszcze o rok.

Byli też klienci, którzy nie życzyli sobie jakiejkolwiek ingerencji w proces twórczy, a jedynie “znajdowanie bugów”. A byli i tacy, którzy bardzo chętnie przyjmowali feedback od nas, jako od “graczy”, czasem nawet słuchali pomysłów.

Adam: To teraz najważniejsze pytanie, o które w sumie już przewidziałeś – czy po pracy grałeś jeszcze w gry, prywatnie? I czy czerpałeś z tego frajdę?

Marek: Ha! Gdybym na przykład testował wyścigówkę, podczas gdy uwielbiałem grać w wyścigówki prywatnie, może miało by to jakikolwiek wpływ? A może nie!

Na pewno testowanie produktu, który się po prostu traktuje jak wykonywanie pracy, nie ma wpływu na granie w wolnym czasie.

Natomiast jest pewien “efekt uboczny” pracy. To zboczenie zawodowe powoduje, że zaczynasz zauważać błędy wszędzie… 🙂

Adam: Ciężką praca w środowisku gier zamieniłeś po ośmiu latach na równie ciężką pracę w środowisku webaplikacji. Nasuwa się jedno pytanie – dlaczego? Zarobki? Rozwój? Zmęczenie?

Marek: Przede wszystkim zarobki i chęć rozwoju. Może wyjdę na starego cynika, ale bez mrugnięcia oka wybiorę stabilniejszą pracę ponad pasję do gier. Wiesz, jestem już dorosłym facetem, mam rodzinę, zobowiązania finansowe i też chcę się jakoś piąć po tej drabince do góry, jak większość z nas. W pewnym momencie też jednak czułem, że dotknąłem sufitu w firmie. W kwestii technicznej poznałem wszystkie platformy, narzędzia tam dostępne, w kwestii branżowej procesy i nazewnictwo, nawet osobiście rozwinąłem się bardzo, będąc leadem, spotykając się z różnymi, czasem nawet nieprzyjemnymi sytuacjami. Poza nauką prywatną, nie miałem jak rozwinąć się jako QA. Ciekawiła mnie natomiast praca bliżej developerów lub devopsów, prawdziwy Agile, CI/CD, automatyzacja testów, testy API… Wszystko to, z czym jeszcze zawodowo się nie zetknąłem.

Tak więc zrobiłem. Przysiadłem do nauki wybranych tematów i zacząłem rozglądać się za stanowiskiem Test Engineera.

Adam: Jak wyglądała Twoja ścieżka związana z przebranżowieniem? 

Marek: Dwa słowa, które najlepiej oddałyby ten czas to stres i nauka. Nauka z wiadomych względów. Stresowałem się natomiast przed otworzeniem tych nowych drzwi, mimo, że nie było to teoretycznie zupełne przebranżowienie. Czy taka zmiana wyjdzie mi na lepsze? Czy podołam? Czy nie umiem za mało? Jak uda się pracować z testerami, którzy być może mają o wiele większe zaplecze techniczne?

Oczywiście, stres okazał się bezpodstawny. W nowy projekt “wniknąłem” bardzo szybko i przy nauce, chęci poznania produktu, procesów, przyjaznym zespole bardzo szybko nabyłem pewności siebie. Gdy pojawiał się problem, szukałem rozwiązania i zwykle znajdowałem je. Gdy nie rozumiałem czegoś, pytałem i dostawałem odpowiedź. Gdy obawiałem się, że nie mam dostatecznej wiedzy technicznej odnośnie automatyzacji, bądź kodu, nadrabiałem to szybko znajomością logiki aplikacji, świeżymi pomysłami na testy, komunikacją… A potem po pracy nadrabiałem wiedzę ze strony technicznej.

I w dużej mierze tak robię do dziś. 

Dwa lata temu nie potrafiłem napisać linijki kodu, dziś jako jedyny QA w projekcie automatyzuję testy. Wszystko jest do zrobienia.

(No dobrze, może nie absolutnie wszystko, ale chodzi mi o to, że dobra wola i własna praca zdziałają naprawdę wiele 🙂)

Adam: To był naprawdę wartościowy wywiad, dziękuję! Mam jeszcze takie luźne pytanie, ale zanim do niego przejdziemy, chciałbyś coś jeszcze dodać od siebie dla innych?

Marek: Dziękuję bardzo za wywiad i mam nadzieję, że było ciekawie. Podczas odpowiedzi towarzyszyły mi dwie myśli. Żeby pokazać, że testowanie gier to również branża zapewniania jakości. I jeśli ktoś chce iść tą drogą, śmiało!

Wiem też jednak, że jest mnóstwo osób, które chce iść dalej, a wielu się stresuje podjęciem tej decyzji. I tym osobom chcę powiedzieć – z własnego doświadczenia – dacie radę. Decyzja może być stresująca, może wymagać trochę pracy, ale WARTO!

Adam: To na koniec jeszcze dwa istotne pytania. Jaka jest Twoja ulubiona gra? Oraz Triss czy Yennefer? 😉

Marek: He he, cokolwiek odpowiem tak czy siak komuś się narażę. Ale jeśli już muszę, to jednak Yennefer!

Co do gier raczej nie mam jednej, jednej ulubionej. Natomiast moje faworyty w gatunkach, jakie lubię, na pewno wymieniłbym z platformówek Raymana, Sonica czy Castlevanię (jak widać jestem raczej retro graczem).

Co się tyczy RPG, to wybrałbym Final Fantasy, Chrono Trigger, może Zeldę? Wiele godzin spaliłem też na SimCity.

Raz jeszcze dziękuję!

Zakończenie

Gdy już zapoznasz się z powyższymi informacjami, zapraszam Cię również do newslettera branżowego. W każdy piątek dzielę się sporą dawką wiedzy z branży Quality Assurance, testowania oprogramowania oraz IT. Jeżeli interesuje Cię kompleksowe szkolenie dla przyszłych Quality Assurance, chcesz otrzymać ugruntowany proces działania, merytoryczne lekcje, ćwiczenia, testy oraz praktykę, zajrzyj do pełnego szkolenia, którego jakość i skuteczność potwierdziły dziesiątki kursantów. Do przeczytania!