Nigdy nie będzie gier bez błędów. O pracy testera gier

Sergiusz Ślosarczyk, z którym rozmawiamy o pracy testera gier, jest dyrektorem działu QA w firmie QLOC S.A., zajmującej się testami, lokalizacją i portowaniem gier video na różne platformy. Swoją karierę zawodową zaczynał jako tester. Zdobywał doświadczenie również za granicą, pracując dla Electronic Arts w Madrycie.

Sergiusza w pierwszym tekście, który jest częścią miesiąca tematycznego #gamedev, zapytaliśmy m.in. o to, czy istnieją gry bez błędów. — Gry są zbyt złożone, by to było możliwe. Na poziomie produkcji w każdym studiu jest ktoś, kto w pewnym momencie musi zająć się zarządzaniem ryzykiem i ocenić, które błędy trzeba naprawić, a które niestety trzeba pozostawić — mówi Sergiusz Ślosarczyk.

Jak testowanie gier wygląda od środka? Jak duży wpływ na grę ma tester? Oraz jak często zdarza się, że tester staje się później twórcą gry? Oto zapytaliśmy naszego dzisiejszego rozmówcę.

Testowanie gier wydaje się pracą marzeń. Jesteś pierwszą osobą, która ma dostęp do nowej gry i możesz cieszyć się nią przed innymi. Jak praca testera wygląda w rzeczywistości?

Dla wielu ludzi, to praca marzeń i to prawda, że często mamy dostęp do gier, które nie zostały jeszcze zapowiedziane. Ciekawie czyta się w prasie i Internecie spekulacje na temat tytułu, do którego ma się dostęp. Jednakże trzeba pamiętać, że gry, które trafiają do testów są w fazie produkcji, a więc poznajemy je, gdy nie są kompletne. Często nie mają wszystkich poziomów, mechanik, finalnych grafik czy dźwięków. To trochę jak oglądanie sztuki teatralnej, w której aktorzy mylą tekst, nie mają strojów ani makijażu, a w tle brakuje scenografii. Jeśli jednak kocha się gry, to z przyjemnością ogląda się zza kulis proces ich powstawania.

W pracy testujemy, a nie gramy. Robimy to z konkretnym nastawieniem, żeby albo potwierdzić, że coś działa poprawnie, albo żeby znaleźć w tytule defekty. Każdy z członków zespołu ma przed sobą postawione konkretne zadanie, które w danym dniu ma do zrealizowania. Często towarzyszy temu sporo „papierkowej” roboty, czyli wypełniania dokumentacji.

Jak zostałeś testerem gier? To zawsze zaczyna się od zamiłowania do gier?

W moim wypadku właśnie tak było. Grałem w gry od małego i pasja ta towarzyszy mi do dziś. Kiedy akurat nie siedziałem przed monitorem, zaczytywałem się w czasopismach branżowych, takich jak Secret Service, CD-Action, czy Reset. W tym czasie powstawały masowo kafejki internetowe, więc sporo czasu spędzałem ze znajomymi „poza domem” – kolekcjonując fragi i ćwicząc strafe-jumpy w Quake 2 oraz ogrywając inne tytuły w lokalnym multiplayerze.

Od tego wszystko się zaczęło, choć tak naprawdę testerem zostałem trochę z przypadku. Jako student ostatniego roku japonistyki zacząłem rozglądać się za pracą. Przeczesując ogłoszenia natrafiłem na ofertę QLOC. Aż do tamtego momentu nie wiedziałem nawet, że w Polsce można pracować jako tester gier. Natychmiast wypolerowałem „cefałkę”, napisałem list motywacyjny, wysłałem zgłoszenie i po rozmowie kwalifikacyjnej dość szybko zacząłem pracę na moim pierwszym projekcie. Już pierwszego dnia poczułem, że jestem we właściwym miejscu. Poznałem wielu świetnych ludzi, którzy podzielali moją pasję. Wtedy pomyślałem, że odnalazłem coś, czym chciałbym zajmować się zawodowo i że nie jest to praca tylko na chwilę. Tak rozpoczęła się moja przygoda z branżą gier.

Kiedy tester zaczyna swoją pracę? Na jakim etapie produkcji otrzymuje grę do testów, jakie informacje otrzymuje wtedy od producentów na temat samej gry?

Projekty, nad którymi pracujemy w QLOC, trafiają do nas na różnym etapie zaawansowania w zależności od tego, czego dany developer od nas oczekuje. Na dłuższych projektach startujemy często w alphie, czasami w becie. Są projekty, nad którymi pracujemy tylko tydzień, a są takie, które trwają przez parę lat. Często współpracujemy też z naszym wewnętrznym działem developmentu, który zajmuje się przygotowywaniem portów gier na różne platformy.

Jeśli chodzi o informacje o grze, to zwykle dostajemy dokumenty przygotowane przez designerów lub QA naszego partnera. Często jest to tzw. „GDD”, czyli Game Design Document, który zawiera opis całego wyobrażenia developerów o grze – fabułę, opis wszystkich mechanik, sposoby przejścia, ale także spis elementów, które posłużyły studiu za inspirację do stworzenia danej postaci, mechaniki czy trybu gry. Nierzadko są tu odniesienia do filmu, świata komiksów, książek, czy innych gier.

Oprócz GDD często dostajemy dostęp do test cases i test planu danego projektu. Nierzadko opracowujemy je też sami od zera. Oczywiście zdarzają się sytuacje, że nie ma żadnej dokumentacji albo ta, która jest dostępna, dawno się przedawniła. W toku powstawania gry, jej mechaniki, fabuła przechodzą wiele iteracji. Zawsze przecież można coś zrobić lepiej, dodać coś o czymś nikt wcześniej nie pomyślał. Dokumentacja niestety nie zawsze nadąża za rzeczywistością, ale to normalne w tak kreatywnym środowisku jak branża gier.

Podczas prezentacji na TestingCup 2016 mówiłeś o macie do tańczenia, za pomocą której przeszedłeś Street Fightera. Czego o grze dowiedziałeś się korzystając z tego rodzaju kontrolera?

Przemyślenia miałem dwa. Pierwsze było takie, że da się tego zrobić, więc odblokowałem niejako pewne osiągnięcie w swoim życiu (oraz zrealizowałem rzecz jasna przydzielone mi zadanie). Drugie natomiast było takie, że jest to niezwykle wyczerpujące zajęcie i na co dzień lepiej jednak grać na padzie, hitboxie lub klawiaturze.

Co zawiera takie zgłoszenie błędu? Każdy bug to zdjęcie, opis i propozycja naprawy błędu?

Każdy zgłoszony błąd zawiera dokładny opis, informację o jego wadze i częstotliwości występowania oraz wytyczne, jak dany element powinien poprawnie funkcjonować. Wszystkie defekty muszą mieć treściwe tytuły i być przypisane do odpowiednich komponentów, aby łatwiej było przeszukiwać bazę błędów, która może liczyć dziesiątki tysięcy raportów. Do tego dochodzą różne załączniki jak screeny, filmy, DxDiagi, czy crash logi.

Istotnym elementem pisania błędów są kroki niezbędne do odtworzenia defektu. Chodzi o to, żeby każdy (nawet osoba słabo zaznajomiona z tytułem) był w stanie wywołać ten błąd, podążając za spisaną instrukcją. Z doświadczenia wiemy, że to czasem jedyna sekcja, którą czytają programiści.

Jakie błędy są trudniejsze do wykrycia i wymagają więcej pracy testera?

Najtrudniejsze do wykrycia są błędy, które występują losowo. Odtworzenie takiego defektu w celu jego poprawnego zaraportowania może pochłonąć sporo czasu. Należy pamiętać, że testerzy gier nie mają dostępu do kodu testowanej gry. Tak zwane testy czarnej skrzynki uniemożliwiają precyzyjne namierzenie błędu z poziomu kodu, a opierają się głównie na eksploracji i badaniu funkcjonalności. Doświadczony tester większą uwagę i więcej czasu poświęci na badanie obszarów gry, w których błędy występują najczęściej. Natomiast to, czy wykrycie defektu będzie w tym wypadku trudne, zależy od poziomu skomplikowania samej gry, kreatywności testera oraz stanu dostarczonego builda.

Jak duży wpływ na rozgrywkę ma tester gier? Czy oprócz błędów technicznych zazwyczaj wskazuje, co warto poprawić w samym scenariuszu, co poprawić w dialogach?

Jednym z zadań QA poza znajdowaniem błędów jest opiniowanie tego, co trafia do gry. Bardzo często udzielamy feedbacku na temat tego, czy rozgrywka jest angażująca, historia ciekawa, balans sprawiedliwy albo czy sama gra nie jest np. za łatwa lub za trudna. Zawsze dzielimy się w tych kwestiach naszymi sugestiami, jak można dane elementy poprawić lub zmienić, żeby były bardziej przystępne lub ciekawsze dla graczy. Oczywiście każde studio ma nieco inne podejście do tego typu informacji zwrotnej. Czasami nasze pomysły są implementowane z entuzjazmem, czasami częściowo, a bywa, że i wcale.

Trzeba pamiętać, że każda dodatkowa funkcjonalność czy poprawka, którą zasugerujemy musi zostać przez kogoś opracowana i zaimplementowana, a nie zawsze jest na to czas i zasoby.

Zajmujemy się też testami lokalizacyjnymi (językowymi), w czasie których poprawiamy wszelkie błędy, które wkradły się do gry w trakcie jej tłumaczenia. Trzeba tu koniecznie wspomnieć, że tłumacz rzadko kiedy ma dostęp do gry, nad którą pracuje i czasem brak mu pełnego kontekstu. Tutaj wchodzą do akcji testerzy językowi. Ich rolą jest doszlifowanie tłumaczenia gry tak, aby poprawić wszelkie tego typu błędy kontekstowe, ale nie tylko.

Sprawdzamy nagrane dialogi, korygujemy napisy (aktorzy w trakcie nagrań nie zawsze trzymają się skryptu co do słowa) i zgłaszamy brakujące teksty. Podczas implementacji lokalizacji zdarzają się problemy z czcionką (zwłaszcza z naszymi „ogonkami”), często też tłumaczenie jest dłuższe niż angielski oryginał, co może powodować problemy z nachodzeniem zbyt długiego tekstu na jakiś element interfejsu lub zwyczajnie może on zostać obcięty. W takich sytuacjach skracamy go lub, jeśli to niemożliwe, przesyłamy developerowi raport z opisem błędu. W przypadku konsol sprawdzamy też poprawność wymaganej terminologii certyfikacyjnej.

Oferty pracy z

Ile w pracy testera jest kreatywności? Ile czasu spędza się na samym testowaniu, a ile na szukaniu sposobów rozwiązywania problemów, błędów znalezionych w grze?

Im więcej swobody ma gracz w danej grze, tym więcej rzeczy może się zepsuć i tym większe pole do popisu dla kreatywności testerów. Zawsze znajdą się nieprzewidziane przez developerów sposoby użycia dostępnych w grze mechanik, przedmiotów czy fizyki świata. Każdy błąd, który znajdziemy trzeba dokładnie sprawdzić, aby określić częstotliwość oraz warunki jego występowania. Są defekty, które występują zawsze, gdy wykona się konkretne kroki, a są takie, które wystąpią np. 3 razy na 10 podjętych prób. Trudno więc czasem określić, ile dany raport zajmie nam czasu.

Załóżmy, że końcowy gracz spędzi nad grą 300 godzin. Ile czasu zajmuje testowanie takiej gry? Ile razy tester musi ją przejść w całości?

Przy grze na 300 godzin tester na pewno spędzi nad nią dużo więcej czasu niż statystyczny gracz i na pewno przejdzie ją wielokrotnie. Nierzadko będzie znał każdy kamyczek na każdym poziomie. Nie oznacza to natomiast, że będzie ciągle przechodził grę od A do Z i robił to samo. Część mechanik, zadań, lokacji dodawana jest do gry z czasem, więc tester będzie w danym momencie skupiał się nad tym co jest w grze zaimplementowane oraz nad mechanikami czy poziomami, które w danym momencie są tworzone i wymagają doszlifowania i informacji zwrotnej.

Wyobraźmy sobie np., że developer wprowadza do gry czar pozwalający graczowi przejąć kontrolę nad innymi postaciami. No i tester musi jego działanie sprawdzić na wszystkich postaciach występujących w grze. Trzeba też np. sprawdzić dźwięk, działanie gry na różnych konfiguracjach sprzętowych, czy odblokować wszystkie osiągnięcia. Często robi się tzw. „speed runy” przez „critical path”, czyli jak najszybsze przejście samego głównego wątku fabularnego. Jest dużo zadań, których w trakcie developmentu podejmują się testerzy.

Dla testera certyfikacja (zbiór wymogów od twórców konsol, platform) to swoisty poradnik, jakie błędy nie przejdą? Czy w ogóle istnieją gry bez błędów?

Nie ma gier bez błędów i nigdy nie będzie. Gry są zbyt złożone, by to było możliwe. Na poziomie produkcji w każdym studiu jest ktoś, kto w pewnym momencie musi zająć się zarządzaniem ryzykiem i ocenić, które błędy trzeba naprawić, a które niestety trzeba pozostawić. Gdy brakuje już czasu, nie tyka się z reguły mniej poważnych błędów, na które gracze mają małe szanse natrafić, a których naprawa może pochłonąć zbyt dużo czasu i środków oraz co gorsza istnieje ryzyko, że próba naprawy może zepsuć jakiś inny element kodu. Czasami, gdy jakaś gra wychodzi i ma dużo bugów, mówi się, że została źle przetestowana przez QA. Często nie jest to do końca prawda. Błędy mogły być znalezione, ale podjęto decyzję, aby grę wydać mimo to, żeby zdążyć na obiecaną premierę. Potem zawsze jest szansa poprawić coś w patchu.

Twoim zdaniem brak certyfikacji w przypadku wydawania gry na PC to dobre rozwiązanie?

PC to z natury otwarta platforma, która jako taka do nikogo nie należy w całości, więc niemożliwe byłoby tu wprowadzenie jednej, wspólnej certyfikacji. Poszczególni właściciele sklepów z grami w cyfrowej dystrybucji (mówię tu o dużych graczach) mogą i często wprowadzają własne wymogi certyfikacyjne dla gier produkowanych przez swoje wewnętrzne studia lub dla tytułów, których są wydawcami. Rzecz jasna nie są wtedy tak ostrzy, jak to ma miejsce w przypadku konsol.

Dlaczego w dniu premiery niektóre gry mają mnóstwo bugów i w przeciągu dwóch tygodni producenci potrafią wydać wielogigowe łatki/patche?

Najczęściej dlatego, że developer nie zdążył naprawić ich na czas, a grę trzeba było w końcu wydać. Tworzenie gry to jak tworzenie dzieła sztuki i chyba nie ma takiego momentu, w którym zespół developerski powiedziałby sam z siebie, że skończył pracę, wszystko jest idealne i można grę wydać.

Zawsze znajdzie się coś jeszcze, co można zrobić lepiej, poprawić, a to generuje kolejne błędy. Dlatego ktoś w końcu musi ustalić termin wydania. Nie powinien być to natomiast QA, bo my z racji naszej skrupulatności moglibyśmy wpaść w inną skrajność – opóźnialibyśmy wydanie gry w nieskończoność tak, aby wszystkie błędy zostały naprawione. Naszą rolą jest informować o zagrożeniach i stanie jakościowym, a finalną decyzję podejmuje ktoś inny.

Zdarzyło Ci się, że gra wychodziła z jakimiś krytycznymi błędami, ale liczyliście, że nie zostaną one zauważone do czasu łatki?

Naturalnie, że zdarzają się sytuacje, że developer nie naprawia wszystkich błędów przed wydaniem. Każdy taki nienaprawiony bug powoduje, że gdzieś na świecie płacze jeden tester.

Niemniej jednak takie postępowanie developera nie jest rzadkością i jest zwykle wynikiem decyzji biznesowej. Gry dużych wydawców mają wielu nabywców na całym świecie i są nikłe szanse, że defekt znaleziony przez testera pozostanie niezauważony przez graczy. Należy jednak pamiętać, że każda naprawa elementu gry, może skutkować wystąpieniem dodatkowych błędów w innych miejscach, więc na późnym etapie projektu, każda poprawka to ryzyko.

Z naszej strony, jedyne co możemy zrobić, to w fazie testów zaraportować wszystkie napotkane błędy oraz w odpowiedni sposób, na bieżąco komunikować developerowi ich wagę i znaczenie dla produktu końcowego, co też w QLOC skrupulatnie i w pocie czoła czynimy. Natomiast to, czy błędy te ostatecznie trafią na produkcję, czy zostaną wcześniej naprawione, zależy już tylko od decyzji developera.

Po wielu godzinach spędzonych na testowaniu i szukaniu błędów, przychodzi czas przetestowania gry po wdrożonych poprawkach. Jak zachowujesz dystans do gry?

Z własnego doświadczenia wiem, że były gry, które uwielbiałem i takie, które lubić się nauczyłem. Trzeba zachować zdrowy dystans i niezależnie od prywatnych odczuć wobec danego tytułu, należy pamiętać, że jesteśmy odpowiedzialni za jego jakość. Nasza praca polega na tym, aby sprawić by był on w jak najlepszym stanie po trafieniu na sklepowe (lub cyfrowe) półki. Zawsze cieszą nas później dobre recenzje w prasie i Internecie.

Po całym dniu testowania masz ochotę jeszcze grać w domu?

Od lat już sam bezpośrednio nie testuję gier, ale gdy to robiłem, to nigdy nie miałem problemu z tym, żeby po powrocie do domu uruchomić sobie inny tytuł, w który chciałem zagrać. Koniec końców trzeba umieć oddzielić pracę od czasu na przyjemności.

Jakie są różnice pomiędzy testerem oprogramowania a testerem gier?

Nie mam doświadczenia w testach oprogramowania, ale na pewno z uwagi na poziom skomplikowania samo testowanie gier wymaga dużo więcej pomysłowości pod kątem tego jak można „zepsuć” dany tytuł. Soft ma spełniać jakąś funkcję, więc tam łatwiej określić, czy coś jest zgodne ze specyfikacją, czy nie. Gry poza poprawnym działaniem muszą przede wszystkim być fajne, a to jest czynnik, którego żadna specyfikacja nie uchwyci. Myślę też, że przyjemniej jest testować RPG-a, niż aplikację bankową, ale to oczywiście zależy od indywidualnych preferencji.

Duże studia developerskie mają własne zespoły testerów czy raczej korzystają z firm zewnętrznych?

Różnie. Najczęściej mają swój wewnętrzny zespół, który zależnie od potrzeb mogą skalować poprzez zlecanie części testów na zewnątrz, do takich firm jak QLOC. Niektóre firmy w całości bazują na zewnętrznym zespole, a są też firmy, które mają bardzo duże wewnętrzne działy QA i nie zlecają nic na zewnątrz. Pełen przekrój.

Co myślisz o otwartych beta testach? Czy Twoim zdaniem oddanie społeczności procesu testowania gry to dobry pomysł czy tylko PRowa zagrywka?

Na pewno jest to dobra okazja, żeby zebrać feedback na temat swojej produkcji. W przypadku tytułów z trybem dla wielu graczy pozwala to na sprawdzenie obciążenia serwerów. PR-owo również jest to dobre posunięcie, bo często pozwala to twórcom na zainteresowanie swoim tytułem szerokiego grona odbiorców.

Ogólnie jestem pozytywnie nastawiony do otwartych beta testów, ale warto pamiętać, że wersja, którą udostępnia się graczom powinna być choćby w pewnym zakresie profesjonalnie przetestowana. Z definicji build open beta będzie zawierał błędy, ale jeśli developer udostępni grę w zbyt kiepskim stanie, to PR-owo może odnieść efekt odwrotny od pożądanego. Istnieje też różnica między profesjonalnym zespołem testerów ukierunkowanym na konkretne zadania, a dużą liczbą ludzi, którzy siadają do tytułu głównie po to, żeby się z nim zapoznać przed premierą.

Jak dba się o to żeby gra nie wyciekła do Internetu przed premierą?

Dbamy o bezpieczeństwo na różne sposoby. Do QA Labu nie można wnosić telefonów komórkowych ani niczego, co może posłużyć za nośnik pamięci. Konsole i komputery mają specjalne tagi, a dostęp do Internetu jest ograniczony. Wszyscy pracownicy podpisują też rygorystyczne umowy o poufności. Wiadomo, że czasem człowieka aż nosi, żeby pochwalić się kolegom, że pracuje się nad znanym tytułem. Dlatego dokładnie tłumaczymy naszym pracownikom jak ważna jest poufność oraz to, że gra i dane, do których mają dostęp, są własnością naszych klientów i nie możemy zawieść w tym zakresie ich zaufania.

Praca testera otwiera drzwi do zajęcia się tworzeniem gier? Ścieżka kariery game developera zaczyna się właśnie od testera gier?

Praca testera często jest ludziom przedstawiana jako brama do branży gier i jest w tym bardzo dużo prawdy. Wiele osób, które znam, a które dziś zajmują się rozmaitymi rzeczami w różnych studiach developerskich, zaczęło swoją karierę właśnie od testowania gier. Jeśli ktoś myśli o karierze programisty to może niekoniecznie jest to ścieżka dla niego, ale tester to (poza samą możliwością kariery w QA) bardzo dobry pierwszy krok dla przyszłych designerów, leadów, producentów, czy project managerów. Znam też osoby, które dzięki pierwszej pracy testera dziś zajmują się PR-em, marketingiem czy biznesem w naszej branży.

W QLOC mamy długą tradycję rekrutacji wewnętrznych. Wiele z osób, które dziś pracują w HR, IT, lokalizacji, działach biznesowym i developmentu (m.in. jako PM-owie, designerzy oraz dev support), swoje pierwsze kroki stawiało właśnie jako testerzy. Wszyscy team leaderzy i managerowie w dziale QA również od tego stanowiska zaczynali swoją karierę.

Kilka lat temu było głośno o problemie zarobków testerów gier. Zarówno w Stanach Zjednoczonych, jak i w Polsce, to testerzy zarabiali najmniej w całym game devie. Coś zmieniło się w tej kwestii?

Wraz z upływem lat i dojrzewaniem branży nasza praca jest coraz bardziej doceniana i zarobki powoli idą w górę. W cenie są zwłaszcza osoby z większym doświadczeniem, które obejmują stanowiska leadów.

Jeśli mogę coś dodać na koniec, to wszystkich zainteresowanych tematem, zapraszam do sprawdzenia się w roli testera gier. To świetny punkt wyjścia do rozpoczęcia kariery w branży i przepis na ciekawą pracę przy najnowszych tytułach gier.

W naszym cyklu tematycznym chcemy Wam pokazać, że gamedev jest ciekawym miejscem dla wszystkich developerów. Niebawem opublikujemy kolejne wywiady z ekspertami tej branży, ale już teraz mamy do Was pytanie: czego o gamedevie chcielibyście się dowiedzieć?