V herním vývoji se každá koruna obrací třikrát – s Jakubem Hamarim o herním testingu, práci v herní branži a průmyslu jako takovém | Kapitola 4
Seznam kapitol
Rozporuplné vydání Cyberpunku v prosinci minulého roku vyvolalo (nejen) v herních kuloárech poměrně vášnivé diskuse ohledně neuspokojivého technického stavu dnešních her. Při hledání viníků pak spočinuly prsty mnohých i na herních testerech. Co pojem „herní testing“ rámcově obnáší jsem se již pokoušel objasnit ve shrnovacím článku – cítil jsem však, že k opravdové analýze situace bude potřeba člověka tzv. „od fochu“. Obrátil jsem se tedy na Jakuba Hamariho, který po mnohaleté praxi v softwarovém testingu v současnosti zastává pozici technického designéra na velmi úspěšném projektu Vigor v českém studiu Bohemia Interactive. Jakub mě v brněnském sídle „Bohemky“ mimo skvělé horké čokolády uvítal i ve své typicky ukecané náladě, čímž jsme položili základ pravděpodobně nejdelšímu rozhovoru, který jste kdy četli. Jak opravdu vypadá práce herního testera, jací lidi pracují v herním průmyslu a co si Jakub myslí o filmech Zdeňka Trošky? To a mnohem více se dozvíte na následujících řádcích…
Pojďme se raději vrátit k testingu (smích). Mluvili jsme o tom, že v herním vývoji je obzvláště důležité, aby spolu testeři a vývojáři komunikovali. Předpokládám, že se bavíte osobně, ale používáte i nějaké nástroje na zaznamenávání a sledování defektů?
Jasně, používáme svůj interní software i klasickou Jiru – dokonce máme v Praze dedikované Jira adminy, kteří nám do ní vymýšlí plug-iny a rozšiřují ji k našim potřebám. Je to dobrý způsob dokumentace, dá se v ní jednoduše cestovat zpět v čase a vidět veškerý vývoj. A jak to funguje? Tester klasicky potká věc, která je rozbitá, tak vytvoří ticket. Ten se dostane k zodpovědným lidem, kteří začnou pracovat na opravě. Opravu dodají a pokud se zdaří, tak se ticket zavře. Pokud ne, vrací se zpět k vývojářům. Aneb standardní postup známý z běžných IT firem.
Velkou roli pak samozřejmě hraje prioritizace závažnosti bugu. Když máme třeba vypadlou texturu na všech kamenech na herní mapě, je to chyba, kterou jako hráč vidíš na první dobrou. Kdyby ses přihlásil do hry a chyběla ti textura na všech kamenech, je to samozřejmě velký špatný a chceš to mít opraveno co nejdříve.
Prioritizace je samozřejmě extrémně důležitá v testování obecně, na co ale vyloženě kladete důraz u her?
V herním vývoji potřebuje tester hlavně spolehlivou reprodukci, aby developer přesně věděl, jak dosáhnout stavu, ve kterém tester pozoroval chybu. To je poměrně velký rozdíl, protože kroky pro testera nepíše test analytik nebo test inženýr, ale právě tester je ten, kdo musí velice přesně popsat kroky programátorovi. A opravdu přesně krok po kroku – „Ferdo, musíš udělat tohle, musíš mít v inventáři tuhle věc, pak udělat piruetu, otevřít uživatelské rozhraní a věc ti z inventáře zmizí.“ A když to pak programátor Ferda udělá, tak pak nemá problém bug pozorovat i u sebe.
Ještě krásnější pro vývojáře je, když mu tester napíše i procentuální úspěšnost reprodukce. Ferda se pak podívá a zjistí, ze kterých složek hra tahá data, no a díky tomu pak lépe najde příčinu. Představ si to jako mnohonásobné půlení, kdy na základě reprodukčního scénáře vývojář postupně zjistí, že se bug nachází v konkrétní části kódu. A že se třeba děje kvůli volání objektu, který někdo přejmenoval jen na některých místech kódu. Voláme proměnnou, kterou ale nejde podle jména nalézt, díky čemuž se nám zpět vrací prázdná hodnota. No a hráč pak vidí až důsledek, třeba že kameny nemají textury.
Pozoruješ i nějaká další specifika herního testingu?
Během testování v bance jsme museli postupovat hodně blackboxově, kdežto v Bohemia Interactive rozhodně nemáme daná nějaká pravidla jako „Nesmíš koukat do kódu!“ A právě zkušení testeři, kteří například dovedou v kódu najít, který asset nám ve hře zlobí, vývojářům opravdu pomáhají. Předmět se ve hře může jmenovat například „hunting cap“, což si sice vývojář dovodí, ale třeba na první dobrou neví, pod jakým jménem se takový asset skrývá v kódu – hráč totiž může v realitě vidět úplně jiný název. A když mu tester rovnou dohledá a napíše, že se asset jmenuje mash_head_61, tak už přesně ví, kam se kouknout. Stejným požehnáním je i slovník, tedy když tester používá stejné názvosloví jako vývojář.
No a o procentu reprodukce jsem už mluvil – pokud z defektu zjistím, že se chyba děje na jedné konzoli ze tří, a to jen v jednom případu z deseti, tak vím, že si asi protáhnu večerní pobyt v práci zjišťováním, co s tím vůbec můžeme dělat. Když tester naopak přijde se stoprocentním způsobem reprodukce, tak je diagnostika a následné opravování mnohem jednodušší. Nejhorší chyby jsou totiž takové, kdy vývojář i tester ví, že se něco rozbilo, ale ani jedna strana vlastně netuší, co přesně. Pak se volají na pomoc další lidé, kteří ale díky tomu samozřejmě nemohou pracovat na vlastních úkolech. I proto je role testera při zadávání bugu naprosto kritická. Dobře nahlášený bug je polovina řešení.
ČERNOBÍLÝ SVĚT TESTINGU
Pojem Black Box Testing označuje testování, při kterém tester nemá přístup ke kódu programu. K takovému testování nejsou zásadní znalosti vnitřních struktur či programování, řeší se hlavně funkční chování softwaru jako takového. Obecně jde o méně časově náročnou formu kontroly kvality programu či hry.
White Box Testing pak značí přesný opak – dotyčný je obeznámen s kódem a dochází hlavně k ověřování správné funkčnosti vnitřních struktur, přičemž je testována spíše logika programu. V praxi se White Box Testingu věnují hlavně vývojáři, protože je v něm zásadní právě znalost kódu, kterou testeři často neoplývají. To ovšem neznamená, že by jeden druh testingu byl lepší či účinnější než ten druhý – v reálném světě se totiž oba způsoby doplňují.
Měl by tedy herní tester být perfekcionista? Na hledání bugů přeci jen potřebuješ školené oko, na druhou stranu si ovšem dovedu představit, jak takový člověk musí trpět při pohledu na všechny ty malé chybky, kterých jsou například hry s otevřeným světem plné…
Je důležité si v jistém chvíli říct „Fajn, testingu už bylo dost.“ Když jsi perfekcionista, může ti to házet klacky pod nohy při jakémkoliv testování, nejen v herním vývoji. Potřeba, aby bylo všechno tip top, by tě mohla zdržovat od těch opravdu zásadních problémů. Každý asi chápe, že když se ti například popruh batohu protíná s bundou na jednom z pěti ženských charakterů, tak… Ano, je to chyba, nemělo by se to dít. Ale když se hráč nemůže připojit do hry, nebo když zmizí textury ze všech herních objektů? To je samozřejmě mnohem závažnější problém. Od toho ale ostatně máme component leadery, kteří u nalezených defektů mohou upravit prioritu, případně opravu odložit na později.
Komentáře naleznete na konci poslední kapitoly.
