Testowanie to nie zabawa?

Jak się robi gry, na przykładzie "Call of Juarez: Bound in Blood" Część 2:  Testowanie to nie zabawa?Lekko, łatwo i przyjemnie... ? W powszechnej opinii graczy, praca testera gier komputerowych jest zadaniem lekkim, łatwym i przyjemnym. Niektórzy nazywają to "graniem za pieniądze" uważając, że to  wymarzona praca dla każdego fana gier. Czy naprawdę to jest takie proste i każdy gracz jest z założenia świetnym testerem? Po przeczytaniu artykułu oceńcie to sami.

Testerzy w pracy (Damian i Marcin)

Praca na stanowisku testera gier z pewnością daje wiele radości i zadowolenia m.in. z bycia częścią ekipy developerskiej oraz z możliwości wpływania na ostateczny kształt gier, dzięki własnym pomysłom i uwagom. Nie da się nie zauważyć zalet obcowania z najnowszą technologią, sprzętem i ludźmi dzielącymi te same fascynacje. Nie jest to jednak praca dorywcza, sezonowa, "po godzinach", ani możliwa do wykonywania zdalnie. Stanowisko testera to ciężka, pełnoetatowa, bardzo odpowiedzialna praca, która odbywa się wyłącznie w siedzibie firmy. Celem działu Quality Assurance jest, jak sama nazwa wskazuje, dbanie o jakość gier będących w produkcji. Jest to o wiele więcej, niż tylko znajdowanie błędów.

Testowanie to używanie i sprawdzanie działania gry w kontrolowanych warunkach tzn. takich, które pozwolą na powtórzenie i opisanie kroków i okoliczności dojścia do zauważonego błędu.

Po ludzku oznacza to testowanie jednego tytułu przez wiele miesięcy, granie po kilkaset bądź kilka tysięcy razy w te same levele i raportowanie tysięcy błędów, uwag, opinii i sugestii. Zaczynając każdy kolejny test, trzeba zapomnieć o wszystkich poprzednich przejściach gry i starać się zupełnie na świeżo patrzeć w ekran. Tylko w ten sposób można wychwytywać nowe błędy i niedociągnięcia oraz spisywać kolejne uwagi. Wpadnięcie w rutynę jest najgorszą rzeczą jaka może przydarzyć się testerowi.

Dział testów, jako ostatnie ogniwo w łańcuchu produkcyjnym, jest zobowiązany do sprawdzenia poprawności działania wszystkich kolejnych wersji gry, pod każdym kątem. Wersje, które trzeba szczególnie dokładnie sprawdzić to następujące kamienie milowe:

• FPP - (First Playable Publishable) wersja pokazująca maksymalnie dopracowaną grę w jej małym, przekrojowym wycinku np. tylko na jednym levelu. Z tego powodu FPP zwany jest czasami "vertical slice".
• Alfa - ukończony duży procent gry, część rzeczy może być jeszcze w wersji tymczasowej (niektóre obiekty, tekstury, dźwięki, nagrania dialogowe). Działają wszystkie najważniejsze mechaniki, powinno być możliwe ukończenie całej gry.
• Beta - W pełni funkcjonalna gra, bez elementów tymczasowych i zastępczych. Wymaga jedynie dopracowania szczegółów i doszlifowania.
• Release Candidate - wersja będąca potencjalnie finalnym produktem gotowym do wydania. Przechodzi ostateczne, bardzo wnikliwe testy. Jeżeli ujawnią się w niej błędy krytyczne, to po ich naprawieniu tworzony jest kolejny Release Candidate.

Czas, w którym projekt wkracza w te najważniejsze fazy, jest szczególnie trudny i wymagający wielkich nakładów pracy. Niejednokrotnie trzeba wtedy spędzać po kilkanaście godzin grając w kółko w to samo, raportując kolejne problemy i sprawdzając czy nasze poprzednie zgłoszenia zostały naprawione. Aby zrozumieć ogrom przedsięwzięcia, należy wszystkie z powyższych kamieni milowych oraz wersje tworzone w międzyczasie, pomnożyć przez liczbę platform oraz wspieranych systemów operacyjnych (w przypadku PC), na które tworzony jest produkt. Wersja na każdą z platform traktowana jest oddzielnie i musi zostać z tak samo dużą dokładnością sprawdzona.

Przy "Call of Juarez: Bound in Blood" pracowało bez przerwy około 10 testerów w Techlandzie oraz około 30 - 50 testerów ze strony wydawcy, a dokładniej z oddziału Ubisoft Romania.

Z jakich narzędzi korzysta tester? Standardowym wyposażeniem testera gier w Techlandzie na dzień dzisiejszy jest pecet, "test kity" 360 i PS3 oraz różnego rodzaju kontrolery i peryferia obsługiwane w naszych grach. "Test kity", w odróżnieniu od sklepowych wersji konsol, pozwalają na uruchamianie gier, które są wersjami produkcyjnymi i które nie muszą być wytłoczone na płycie. Do test kitów dołączone są narzędzia producentów, które pomagają mierzyć średni FPS w danych miejscach na levelu, nagrywać filmy z przebiegu gry, robić screenshoty, zapisywać logi i dumpy tzn. zrzuty pamięci, które przydają się programistom do znalezienia przyczyny błędu. Testerski pecet nie jest super maszyną, a wręcz przeciwnie, powinien być zbliżony do konfiguracji komputerów spotykanych w domach graczy. Zainstalowane są na nim najnowsze wersje wszelkich sterowników, najnowszy DirectX oraz narzędzia dodatkowo usprawniające przebieg testów. Aby zwiększyć prawdopodobieństwo wykrycia błędów związanych z ewentualnym brakiem kompatybilności, bardzo ważnym jest, by komputery testerów miały zupełnie różne konfiguracje sprzętowe (m.in. karty graficzne, płyty główne, procesory), a także różne systemy operacyjne. Dodatkowo bardzo przydatnym jest "komputer z obrazami" tzn. osobna maszyna, gdzie w postaci obrazów dysków trzymane są systemy operacyjne, w różnych, często egzotycznych wersjach językowych. W końcu gra powinna bezbłędnie działać na każdej wersji językowej, w każdym kraju i z każdymi ustawieniami systemu.

Stanowisko testera gier komputerowych

Narzędziem, z którego najczęściej korzysta tester jest system zgłaszania błędów. Po znalezieniu błędu pracownik zobligowany jest do dokonania w nim jasnego i czytelnego wpisu opisującego ten błąd. Dokonując zgłoszenia należy podać m.in. na jakiej wersji gry błąd został zauważony, jak wysoki jest jego priorytet (od najpoważniejszego - crasha, aż po "opinię"), jak często błąd jest powtarzalny, jakie dokładnie kroki należy zrobić, by dojść do opisanego efektu, opis samego błędu i w niektórych przypadkach sugestię, w jaki sposób powinno być to naprawione.

Po tym, jak błąd zostanie naprawiony, wpis do systemu uzyskuje odpowiedni status, a zadaniem testera jest sprawdzenie, czy faktycznie problem już nie występuje i czy naprawienie go nie wpłynęło negatywnie na inne elementy gry.

Czym dokładniej są te testy? Jak wspomniałem już wcześniej, testy służą uzyskaniu maksymalnej jakości oraz zgodności ze specyfikacją. Należy być przewidującym (wiemy, że gracze są bardzo pomysłowi!) i sprawdzić każdą rzecz, którą potencjalnie mógłby ktoś wykonać w czasie gry. W sposób zorganizowany, przemyślany i możliwy do odtworzenia sprawdza się zatem wszelkiego rodzaju kombinacje zachowań, kolejności wydarzeń i często próbuje się celowo zepsuć grę. W końcu lepiej, żeby zepsuł ją tester i nastąpiła szybka naprawa, niż żeby gracz już po zakupie musiał oglądać nasze "wpadki przy pracy".

Wersja gry, która trafia do testera jest buildem zawierającym dodatkowe funkcje i klawisze developerskie ułatwiające testy. Buildy oznaczane są w taki sposób, aby niemożliwym było ich pomylenie lub nadpisanie nazw. Najprostsze metody są najlepsze, dlatego obok nazwy gry zapisuje się datę i godzinę utworzenia builda np. coj_bib_20090420_2130.zip.

Wspomnianymi ułatwiaczami są m.in. cheat menu, włączanie/wyłączanie fizyki obiektów, elementów graficznych, zabijanie wszystkich przeciwników na ekranie jednym klawiszem, dodawanie sobie dowolnego typu broni i ekwipunku, przeskakiwanie między levelami itp. itd. Oczywiście tester powinien jak najrzadziej korzystać z tego typu "wspomagaczy" ponieważ jego odbiór gry powinien być jak najbliższy temu, w co będzie grał gracz. Tym niemniej testując np. przebieg dziesiątego levelu trudno jest oczekiwać przechodzenia za każdym razem wcześniejszych dziewięciu. Tester przenosi się tam bezpośrednio i dodaje sobie np. broń, którą według założenia scenariusza i przebiegu gry, będzie miał w tym miejscu szczęśliwy nabywca tytułu.

Głównym typem błędów, które trzeba wyłapać i zgłosić są tzw. crashe, czyli sytuacje, w których gra traci stabilność i następuje jej zawieszenie się, zresetowanie lub wyjście do systemu operacyjnego. Równie ważne są tzw. blockery, czyli miejsca bądź sytuacje w grze, w których gracz może stracić możliwość kontynuacji gry. Blockerem może być równie dobrze zamknięta brama, przez którą nie możemy przejść (a według scenariusza powinniśmy móc), jak i np. zbyt trudna akcja ustawiona na levelu. Dalej błędy mogą dotyczyć praktycznie wszystkiego co widać, słychać i czuć - mechaniki postaci, AI, grafiki, muzyki, dźwięków, poziomu trudności, animacji, nawigacji po menu itp. itd. Nie da się stworzyć listy wszystkich potencjalnych błędów i kombinacji wywołania ich, dlatego praca, spostrzegawczość i  bystrość testera są tutaj na wagę złota. Jednakże nie jest najtrudniejszym znalezienie tego, co jest ewidentnie zepsute. Najtrudniejsze jest odnalezienie tego, czego brakuje. Przechodząc minutowy fragment dowolnej gry zastanówcie się, czy widzicie i słyszycie wszystko, co powinno tam się znaleźć. Na pierwszy rzut oka i ucha wszystko jest ok, prawda? Takie rzeczy jak brak dźwięku kroków gracza lub przeciwników, brak charakterystycznych dźwięków otoczenia, brak specyficznych obiektów na dalekim planie itp. trudno wyłapać dopóki się o nich nie pomyśli.

Oto kilka, z wielu rodzajów testów celowych tzn. mających sprawdzić jakąś bardzo konkretną rzecz:

• Testy stabilności - służą sprawdzeniu i upewnieniu się, że gra nie "wywala się", niezależnie od tego, co się w trakcie rozgrywki robi i jak bardzo zakombinuje. To ekstremalnie ważne testy. Nikt nie lubi gier, które nagle wyskakują do Windowsa, lub są w stanie zawiesić konsolę.

• Testy zgodności z TCR/TRC - są  specyficzne  dla konsol. Zarówno Microsoft jak i Sony udostępniają developerowi wymagania techniczne odnośnie jakości produktu. Wymagania spisane są w formie ponumerowanych punktów i należy je spełnić, by dostać pozwolenie na wydanie gry na daną konsolę. Przykładowymi wymaganiami są: długość loadingów i ich atrakcyjność, wymagania dotyczące sieci i przesyłu danych, specyficzne wymagania regionalne, obsługa różnych wyświetlaczy (np. telewizory z różnymi przekątnymi ekranu, proporcjami i rodzajami wyświetlacza - kineskopowe/LCD/Plazma, HD, monitory itd.), obsługiwanie dodatkowych peryferiów, specyficzne przypadki mogące się wydarzyć w czasie działania gry (np. wypięcie się kabla sieciowego), komunikaty przy save'ach, specyficzne nazewnictwo (quick game, ranking match) itd.

Kto się nadaje na testera gier? Pracy testera nie można nauczyć się na żadnych studiach lub kursach, ponieważ takie nie istnieją. Techland, rozważając kandydatury na to stanowisko, zwraca uwagę przede wszystkim na cechy osobowościowe. Kluczowa jest wysoka komunikatywność, ponieważ zauważone problemy trzeba w jasny i przejrzysty sposób umieć przekazać innym członkom zespołu. Dobrego testera charakteryzuje też umiejętność pracy w zespole, dokładność, sumienność, cierpliwość oraz spostrzegawczość.  W związku z tym, że tworzymy różne gry, oczekujemy od kandydatów na testerów szerokiej wiedzy ogólnej i wykształcenia minimum średniego. Nie oznacza to, że każdy ma być ekspertem w każdej nauce i dziedzinie życia, ale erudycja jest niezmiernie przydatna.

W związku z tym, że raportowanie błędów odbywa się często po angielsku, oczekujemy co najmniej komunikatywnej znajomości tego języka. Jeżeli ktoś jest w stanie rozumieć, czytać i czynnie posługiwać się jeszcze jakimś językiem to ma dodatkowy plus.

Najważniejsza jest jednak pasja do gier. Człowiek będący pasjonatem automatycznie staje się ekspertem w dziedzinie gier, branży, nowinek technicznych, znajomości hardware'u itp. Dla pasjonata nauka nowych rzeczy jest nie tylko łatwa, ale także bezbolesna i na swój sposób przyjemna.

Chcesz spróbować swoich sił? Jeżeli widzisz swoją przyszłość w branży gier komputerowych i jesteś zainteresowany spróbowaniem swoich sił jako tester gier komputerowych to masz teraz ku temu doskonałą okazję. Techland aktualnie prowadzi rekrutację nowych pracowników do działu QA, tak więc zapraszam do zapoznania się z poniższym ogłoszeniem:

Ogłoszenie Techlandu Paweł Kopiński Lead International Brand Manager (kiedyś - Tester Gier Komputerowych) Techland