O radostech a strastech herního testingu
i Zdroj: Hrej.cz
Témata Článek O radostech a strastech herního testingu

O radostech a strastech herního testingu

Aleš Tihlařík

Aleš Tihlařík

9. 4. 2021 16:30 3

Seznam kapitol

1. TESTUJU, TESTUJEŠ, TESTUJEME 2. KŘUP 3. VŠECHNO ZLÉ...

Bugy – tu malé, tu větší chyby a problémy, které kazí život vývojářům i hráčům. Pokud herní průmysl sledujete trochu blíže, jistě dovede z fleku vyjmenovat několik her z posledních let, které měly s technickým stavem velké problémy. Ať už to jsou technické problémy, kterými trpěly (či dodnes trpí) Kingdom Come: Deliverance, Fallout 76 nebo Cyberpunk 2077, či poddimenzování serverů jako v případě Diablo 3 nebo nejnověji u Outriders, v komentářích a reakcích hráčů se často setkávám s názorem, že za zpackaný stav hry mohou testeři.

Reklama

Problém ovšem tkví v tom, že pod pojmem „herní testing“ nebo „herní QA“ (Quality assurance, česky zajištění jakosti) si každý představuje něco jiného. Člověka zvenčí často prakticky okamžitě napadne, že jde o práci snů, ve které člověk jen celý den hraje hry a občas vývojářům řekne, že se mu něco nezdá. Tahle idealizovaná představa má však do reality celkem daleko. Jaké jsou tedy předpoklady pro roli testera, jak herní testing probíhá, čím se liší od toho běžného, softwarového, a hlavně – proč je tester paradoxně často ten úplně poslední, kdo může za neuspokojivý technický stav hotové hry?

O TESTERECH A LIDECH

Role testera je ve vývoji jakéhokoliv softwarového produktu velmi specifická. Na juniorní manuální pozice vlastně nejsou potřeba žádné extrémní znalosti, i proto se v testingu často najdou lidé, kteří nedisponují žádnými zkušenostmi z oboru. Nepotřebujete umět programovat či rozumět grafice nebo hudbě, základem je přirozená zvídavost, ochota učit se novým věcem a samozřejmě notná dávka puntičkářství. Stejná rovnice už samozřejmě neplatí o designérech automatických testů či vedoucích pozicích v QA, vstup do oboru je však pro osobu se základními předpoklady poměrně jednoduchý. I proto tyto pozice často zastávají studenti či lidé úplně mimo IT, kteří mohou testing brát jako vstupní bránu do velmi zajímavého a perspektivního odvětví. Je pak jen na nich, jestli se budou i nadále kariérně věnovat kontrole kvality, nebo se postupně vypracují do techničtějších pozic.

Hlavním úkolem softwarového testera je najít, zaznamenat a po opravě znovu retestovat chyby, na které narazí. Běžný člověk, který na obdobné pozici pracuje například ve firmě specializující se na vývoj webových stránek, tak šmejdí po vývojové fázi těchto stránek ve snaze najít veškeré problémy, které se na nich vyskytují. I když ruku na srdce – fakt, že nikdy nenaleznete a neopravíte úplně všechny chyby, je jedním ze základních pravidel testingu. Tester může ve své práci postupovat mnoha způsoby, často ale jedná na základě test scriptu, tedy jakéhosi seznamu kroků a jejich důsledků, kterému by měla odpovídat i realita.

I takhle může vypadat jednoduchý test script - na levé straně kroky, na pravé straně očekávaný výsledek. Do sloupce "Test Data" pak obvykle patří přihlašovací jména, hesla a další podobné propriety. které jsou ke správnému vykonání testu nezbytné.
i Zdroj: Hrej.cz
I takhle může vypadat jednoduchý test script - na levé straně kroky, na pravé straně očekávaný výsledek. Do sloupce "Test Data" pak obvykle patří přihlašovací jména, hesla a další podobné propriety. které jsou ke správnému vykonání testu nezbytné.

Onen script si napíše buď sám na základě projektové dokumentace, nebo jej připraví někdo na vyšší pozici. Je však naprosto klíčové zmínit, že takové testování probíhá v poměrně dobře izolovaném prostředí a 2D prostoru, skripty se tedy dají velice dobře řídit. Jednou z dalších poměrně častých variant postupu je tzv. průzkumné testování, kdy QA pracovník prochází stránkou či programem primárně na základě vlastních zkušeností a intuice.

Opravy problémů stojí čas, čas stojí peníze a takový čas, který musí developer místo reálného vývoje trávit opravami, není vhodně investovaný čas.

Pokud je v průběhu testování nalezen defekt (bug), je testerem zaznamenán do databáze defektů. Proces nahlášení takového bugu má samozřejmě své vlastní formality, které slouží k tomu, aby vývojář co nejlépe pochopil, jak takovou chybu reprodukovat a jaký je vlastně očekávaný stav. V optimálním případě pak vývojář vytvoří nápravu, kterou tester následně znovu ověří – pokud je vše v pořádku, je bug uzavřen. Pokud náprava sjednána nebyla, dochází k cyklu oprava-ověření klidně i několikrát za sebou. Hlavním cílem je co nejlépe odladěný software, ovšem vždy jen v rámci možností. Opravy problémů stojí čas, čas stojí peníze a takový čas, který musí developer místo reálného vývoje trávit opravami, není vhodně investovaný čas. Defekty se tedy zpravidla posuzují a opravují na základě závažnosti – nemožnost software spustit je samozřejmě zásadní problém, který musí být opraven bez ohledu na to, kolik času a vývojářů tento akt zabere. Méně zásadní věci však nemusí být opravovány prioritně, a pokud je zjištěno, že bug nemá velký vliv, nemusí být opraven nikdy. Tím spíše v případech, kdy jeho oprava spolyká příliš mnoho prostředků.

„JÓ HERNÍ TESTER, TEN TVRDEJ CHLEBA MÁ“

Práce herního testera se v základních principech až tak moc neliší, samotný proces testování je však úplně jiný. Do velké míry je to způsobeno zvýšeným počtem vjemů a zásadní změnou prostoru. Při testování webové stránky nebo jednoduché mobilní aplikace obvykle řešíte, jestli funguje tlačítko či jestli se načítají obrázky. Hry ale samozřejmě jdou mnohem dále. Najednou do rovnice vstupují proměnné jako gravitace, ambientní zvuky, chování umělé inteligence či variabilní vstup od samotného hráče. Největším rozdílem je ale samozřejmě pohyb v prostoru, kdy se ,obzvláště ve 3D hrách, tester setkává s neuvěřitelným množstvím možností, jak hru prozkoumávat a záměrně rozbíjet.

Stav běžného herního testera po celodenní práci dva týdny před vydáním, 2011, kolorizováno.
i Zdroj: Hrej.cz
Stav běžného herního testera po celodenní práci dva týdny před vydáním, 2011, kolorizováno.

V takovém případě samozřejmě není v lidských silách napsat testovací script pro všechny situace – tvorba takových scénářů by bez nadsázky trvala déle než vývoj samotný. V herním QA se tedy využívá hlavně průzkumného testování, kdy má tester přiřazenou oblast hry, které se má věnovat (typicky například inventář, jeden druh zbraně, nebo třeba specifická část mapy), ale žádný přesný návod neobdrží. V některých případech tedy testování her může vypadat i tak, že člověk vyloženě hraje hry za peníze. V drtivé většině případů ovšem vypadá úplně jinak. Tester běhá do zdí, aby zjistil, zda jsou správně nastavené hranice, střílí do různých materiálů, aby slyšel, zda zvuky opravdu odpovídají situaci, či 80krát spouští cutscénu aby se přesvědčil, že opravdu běží jako má. Některé z nás jímá hrůza už jen při čtení o lidech, kteří strávili vyšší desítky hodin v libovolném obrovském RPG. A teď si představte, že spousta zaměstnanců QA oddělení stráví stejnou porci času jen tím, že mění hlavní postavě helmy za účelem zjištění, zdali některý typ netropí neplechu.


I PŘES VODOPÁDY BUGY PLYNOU DÁL

Jedním z dalších rozdílů mezi klasickým a herním vývojem je koncepce vývoje samotného. Obzvláště historicky (a ve spoustě firem dodnes) probíhal vývoj softwaru dle tzv. vodopádového modelu. Co si pod tímto označením představit? Jednotlivé fáze vývoje na sebe navazují takovým způsobem, že další je započata až ve chvíli, kdy je předchozí fáze hotová. Iniciace práce tedy nemůže začít bez toho, aniž by nebyl plně hotový koncept, testing pak začíná až v době, kdy je software plně vyvinutý.

Ale představte si, že by se takovým stylem vyvíjely hry – jednalo by se o časovou (a tím pádem i finanční) sebevraždu. Hry tak ve svém vývoji velmi často využívají agilních metodik – tedy pravidelného dodávání malých kousků, které jsou testovány kontinuálně. Místo tříletého čekání na hotovou hru je tedy například vyvinut a odtestován inventář, za čtrnáct dní integrace herní mapy, za dalších čtrnáct dní bestiář a tak dále.


Jedním z důležitých aspektů testování je mj. schopnost reprodukce chyby. Bezmála noční můrou je pro herního testera nalezení kritické chyby, kterou ovšem nedovede zreprodukovat. Modelový příklad – hra padá na všech systémech, pokaždé v jiném místě a neexistuje žádná zjevná příčina, proč k problému dochází. Může se například naprosto klidně stát, že náhodná prolétající vrána má poškozený audiosoubor krákorání, a to je důvod, proč je hra nestabilní. Ovšem přijít na takový problém, odizolovat jej a najít jeho příčinu je samozřejmě mnohem obtížnější než všimnout si toho, že jsou všechny stromy červené. U větších herních titulů navíc do studií neustále proudí chyby nalezené hráči, což je další případ, ve kterém testeři musí daný bug nejprve zreprodukovat. Jednodušší práci mají obvykle na konzolích, kde z rovnice potenciálních příčin vypadávají různé hardwarové kombinace. Na počítačích se pak kromě obskurních hardwarových chyb občas přihlásí o slovo i problémová komunikace se softwarem třetí strany. V živé paměti mám například bug, který znemožňoval instalaci a hraní GTA V hráčům, kteří měli ve svém Windows účtu použité znaky s diakritikou. To je ten pravý testerův sen…

Předchozí
Další
Reklama
Reklama

Komentáře naleznete na konci poslední kapitoly.

Reklama
Reklama