Co si lidé ve tvém okolí myslí, že děláš?

No, vzhledem k tomu, že tuhle práci jsem dělal už i během covidu, a tehdy jsem několik měsíců trávil u rodičů, měli možnost vidět to na vlastní oči. A z velké části se reakce lidí dají shrnout asi takto: „Vždyť ty vlastně děláš to samé, co když sis jako dítě hrál na počítači, ne?“ Tedy, že jen klikám a sleduju, co se děje.

Ale to je samozřejmě velmi zjednodušený pohled. Mám technické zázemí, takže moji blízcí možná trochu chápou, o co jde. Když řeknu, že jsem tester, často si představí, že jen klikám víc než ostatní. A možná je to i pravda, ale není to jen o klikání.

Lidé si podle mě často neuvědomují rozsah a komplexnost této práce. Například když jsem byl jen uživatelem a ne testerem, taky jsem si říkal: „Jak je možné, že si téhle chyby nevšimli?“ Ale když jsem se dostal na druhou stranu, pochopil jsem, že kombinací, které je třeba otestovat, jsou tisíce. Opravdu se nedá pokrýt úplně všechno. Není možné otestovat aplikaci na 100 %. Každý si myslí, že právě jeho chyba je zásadní a měla být odhalena. Ale realita je taková, že to prostě nejde. A to je podle mě největší nedorozumění.

A jak to tedy vypadá v praxi? Kdy vstupuješ do procesu vývoje?

Když programátor dokončí svou práci, předá ji mně – označí danou funkcionalitu v systému, aplikaci nebo řešení jako „ready for review“, tedy připravenou k testování. Důležité je ale vědět, že to neznamená, že je to nasazené u klienta. V rámci našeho procesu máme několik prostředí: vývojové, integrační a teprve poté produkční. Testování probíhá primárně na vývojovém prostředí a na integračním jen ve výjimečných situacích.

Například když se vyvíjí nová funkcionalita, tak nezasahuju hned během vývoje, ale až když je celek hotový. Je zbytečné testovat napůl dokončená řešení, protože další části mohou ovlivnit ty předchozí. Takže když se něco dokončí, dostanu informaci, že je to hotové, nasadí se to na testovací prostředí a já začínám testovat.

Jak testování konkrétně vypadá?

Nejdřív si projdu, co bylo upraveno nebo přidáno. Mám připravený testovací scénář – tedy přesné kroky, jak simulovat danou situaci. Pokud se chyba projeví tak, jak jsem ji popsal, a je odstraněna, mohu to považovat za vyřešené. Pokud ne, vracím to zpět vývojáři a doplním přesný popis chyby.

V takovém případě vytvářím tzv. „issue“ v JIRA – to je nástroj, který používáme ke sledování celého vývojového cyklu. Do této „issue“ napíšu název chyby, popis, ve které verzi se vyskytla, v jakém prostředí, přiložím screenshoty a hlavně přesné kroky, jak chybu nasimulovat. Vývojář musí vědět, jak se k ní dostanu, protože si to potřebuje ověřit u sebe.

Například: přihlas se, klikni na dokument, udělej tohle, tady se něco pokazí... Musí to být přesné.

Takže pro každý bug vytváříš takový „protokol“?

Ano. A ten protokol není jen o textu. Musí být technicky srozumitelný, musí obsahovat i obrázky, verzování a přesné podmínky. Například se může stát, že vývojář nedokáže chybu zopakovat, a tehdy zjišťujeme, jestli nejde o problém jen v konkrétním prohlížeči nebo zařízení. Může se stát, že já jsem testoval v Chromu, ale on ve Firefoxu – a chyba se projevuje jen tam. Nebo dokonce jen na iPhonu, nebo na Androidu s konkrétní verzí systému.

Dokonce jsme jednou měli nahlášený bug a nakonec jsme zjistili, že uživatel měl prohlížeč DuckDuckGo. Takže testovat úplně všechny možné kombinace hardwaru, softwaru a prostředí je nereálné. Proto se vždy zaměřujeme na to, co je relevantní pro cílový trh, například při testování.

A ten tvůj testovací scénář, to je nějaký standardizovaný dokument?

Ano, máme vytvořené testovací scénáře. Některé jsem psal já, jiné moji kolegové. Ideálně by tyto scénáře měly být zdokumentované a sdílené mezi všemi testery, hlavně pokud je v týmu víc lidí. Některé scénáře jsou určené i pro automatizované testy – ty jsou uložené ve speciálních kolekcích a také mají popsané, co dělají a jaký je očekávaný výsledek.

A co se děje, když najdeš například třicet bugů?

Každý jeden zadám do JIRA jako samostatné issue. Každý z nich musí být popsán, zdokumentován a vývojář si je postupně projde. Když je opraví, znovu nasadí upravenou verzi a já opět procházím všechny scénáře. Pokud je vše vyřešeno, označím to jako uzavřené a můžeme pokračovat dál.

A opakuje se to pokaždé při každé verzi?

Přesně tak. Při každé nové verzi. Máme například verzi 1.0, vývojáři opravili bugy a já testuju znovu. Pokud tam stále zůstávají chyby, cyklus se opakuje.

Existuje něco jako „bezchybná verze“?

Teoreticky ano. Ale v praxi ne. Každá aplikace má bugy. Jde o to, které jsou ještě akceptovatelné. Například bug, který se projeví jen při kombinaci Firefoxu na iPadu, je tak okrajový, že je považován za nízkou prioritu. Samozřejmě, chyby mají své kategorie. Máme „blocker“, což znamená, že nemůžeme dál pokračovat – například když nefunguje server. Potom jsou „critical“, tedy chyby v základní funkcionalitě. Následují „major“, „minor“ a nakonec „trivial“, například logo v nižším rozlišení nebo nepřesně zobrazený prvek na nestandardním zařízení. Ty bývají většinou jen kosmetické.

Kolik toho vlastně je potřeba opravdu testovat? Dá se to vůbec kvantifikovat?

To se velmi těžko vyčísluje, ale často to přirovnávám k tomu, že testování zabírá minimálně polovinu celého vývoje. Není to něco, co se dá dělat jen tak „bokem“. Pokud něco programuješ týden, tak alespoň stejný čas je potřeba věnovat i testování. A čím složitější je aplikace, tím víc kombinací vzniká a tím víc času je potřeba.

Například jazykové mutace – to je kapitola sama o sobě. Pokud máš aplikaci, která běží v angličtině, polštině, maďarštině, češtině a slovenštině, musíš všechno proklikat v každé verzi. A to i tehdy, když nerozumíš konkrétnímu jazyku. V takovém případě aspoň sleduješ, jestli nechybí texty, nejsou špatně zalomené nebo se nezobrazují znaky z jiného jazyka. Už se nám i stalo, že v maďarské verzi se zobrazovala nějaká hláška v ukrajinštině. Takové věci se prostě dějí.

Testování je podle mě stále podceňované v tom, kolik času a energie si vyžaduje. A to mluvím i o manuálním testování, kde musíš všechno dělat ručně – kombinace vstupů, různá zařízení, různé situace.

A co ty případy, které se nedají testovat automaticky? Děláte všechno ručně?

Dlouho jsme fungovali čistě manuálně, ale teď přecházíme na to, abychom alespoň část scénářů pokrývali automatizovaně. Máme s vývojáři společný cíl: vytvořit automatizované testy, které se spouštějí každý den. Zároveň ale tvořím nové, kratší manuální scénáře, které se dají projít za den nebo dva. Nejde o to, abychom testovali všechno naráz, ale abychom dokázali operativně prověřit důležité části.

A když už projdeš všechny scénáře, co potom? Projekt tím pádem pro tebe končí?

Záleží na projektu. Někdy tím moje zapojení skončí, jindy pokračuji i po nasazení do produkce — dělám podporu, konzultace se zákazníkem. Opravdu to závisí na tom, jak je projekt nastavený.

Při své práci tedy musíš myslet jako uživatel?

Snažím se vcítit do role uživatele, a ne vždy je to jednoduché. Každý uživatel má jiné návyky, každý používá systém jiným způsobem. Jsou lidé, kteří klikají nelogicky, zmateně, nebo dělají něco úplně jinak, než bys čekal. A právě oni často objeví chyby, které běžné testování neodhalí. Proto se stává, že klient nahlásí chybu a my jen kroutíme hlavou: „Vždyť my jsme to testovali, všechno bylo v pořádku!“

A co potom děláš?

Začnu ověřovat, zkoušet, simulovat… a ne vždy se mi to podaří. Jsou situace, kdy nedokážu chybu zopakovat. A to je nejhorší — když nevíš, co přesně ten člověk udělal. Zjistíš, že šel nějakou velmi neobvyklou cestou, kterou by běžný uživatel nikdy nezkusil. Tehdy si musíš vyhodnotit: je to chyba, která se může opakovat, nebo je to něco tak ojedinělého, že nestojí za opravu?

Například u velkých systémů, jako jsou portály s dokumenty, kde máme desítky tisíc uživatelů, se může stát, že někomu nepůjde registrace. A pro nás je to signál: OK, je třeba podívat se do logů, zjistit, proč se to stalo. Možná je to jen technická výjimka. Nebo to člověk zkoušel v době, kdy mu spadl internet. No a tam se často podíváme do vývojářské konzole, sledujeme, jaká odpověď přišla ze serveru, co se stalo. Pokud to dokážu nasimulovat, umím chybu potvrdit a řešit. Pokud ne, musím pátrat dál.

Jaké jsou ty nejbizarnější scénáře?

Klasika je, když uživatel třikrát po sobě klikne na stejné tlačítko. Ale ne ve smyslu, že kliká ze zoufalství, protože se něco nenačítá. Jde o situace, kdy se nějaké tlačítko zobrazí jen na sekundu a on ho dokáže stisknout třikrát po sobě – a tím rozbije celý proces.

Nebo testujeme situace s pomalým internetem – musím si zpomalit prohlížeč, nastavit zpoždění, protože to simuluje reálné prostředí uživatelů, kteří žijí na místech se slabším signálem. Lidé fungují různě, mají různá zařízení, různé podmínky. Někdo klikne na něco, pak jde vařit, vrátí se za dvě hodiny a očekává, že bude moct pokračovat, jako by se nic nestalo. Jenže aplikace mezitím vypršela, odhlásila ho, nebo expiroval odkaz. A oni se diví, proč to nefunguje.

A setkáváš se i s tím, že klient nahlásí chybu, ale ve skutečnosti nejde o bug?

To je častý scénář. Například je v dokumentaci popsáno, jak má systém fungovat, ale uživatel to udělá úplně jinak, než se očekává. A pak se mu něco pokazí. Ozve se, že má bug, ale ve skutečnosti jen obešel proces, jak byl navržen. A my musíme vyhodnotit: je to skutečná chyba? Nebo jen nesprávné použití? Někdy je to produkční bug, který je třeba řešit okamžitě. Jindy jen uživatel udělal něco, co mu systém sice dovolil, ale neměl by. A z toho vznikl problém. Tester musí umět tuhle hranici rozpoznat.

Takže musíš znát systém zevnitř i zvenku.

Určitě. Například já dodnes přesně nevím, jak vypadá v reálném prostředí internetové bankovnictví dané banky, pokud ho osobně nepoužívám. Ale znám procesy, vím, jak fungují a jak mají spolupracovat s ostatními moduly. Nám trvalo měsíce, než jsme pochopili všechny souvislosti. Třeba aby naše aplikace fungovala, musí být propojena s více než 10 dalšími systémy od různých dodavatelů. Každý dělá něco jiného, všechno musí spolu ladit. A navíc to celé musí projít bezpečnostním auditem, schvalováním, kontrolou…

Zmiňoval jsi, že spolupracuješ s analytiky i vývojáři. Kdo je tvůj nejbližší okruh lidí, se kterými denně komunikuješ?

Primárně jsou to vývojáři a analytici. S analytiky řeším logiku systému a funkční požadavky, s vývojáři zase to, jak je co implementováno, jaká byla technická omezení. Občas se do toho zapojí i projektový manažer, konzultant nebo přímo klient. A někdy, když chyba spadne mimo můj testovací rámec, odpovídám i jako konzultant — tedy hledám, co se vlastně stalo, proč se to nepodařilo nasimulovat a kdo by mohl mít odpověď.

Jak ses vlastně dostal k IT?

V podstatě to začalo jako hra. Doma jsme měli počítač, nějaké ty první hry, které mi rodiče zakázali, protože prý „krvavé“, třeba Duke Nukem. Ale mě to fascinovalo. Zkoušel jsem obcházet zákazy, kopírovat si hry, instalovat je tajně, schovávat instalace do skrytých složek…

Postupně jsem se do toho dostával, učil se věci sám, zkoušel. A to je věc, která mi neuvěřitelně pomáhá i dnes. Protože spousta lidí si řekne: „Vždyť já pracuju s počítačem denně.“ Ale když děláš 10 let v bance a pořád jen otevíráš Excel nebo Word, tak to ještě neznamená, že rozumíš principům. Řekneš si: „Kombinace kláves Windows + E? Netuším, co to dělá.“ Ale když jsi ten typ člověka, který se rád „vrtá“ v systému, zkouší, hledá, tak máš obrovskou výhodu. Umíš se na věci podívat jinak.

 

Takže tester by měl být trochu jako „samorost“?

Tester v našem týmu by rozhodně neměl být někdo, kdo čeká, že vždy dostane přesné zadání a půjde krok za krokem podle něj. Jasně, někdy to tak je. Ale často ne. Například my máme někdy i osmdesátistránkové dokumentace. Plné popisů, jak má co fungovat. Jenže i tak se spousta věcí nedá úplně nasimulovat. V bankovním prostředí máš tolik specifik, že přenést to všechno do testu je téměř nemožné. A pokud čekáš, že ti někdo všechno nakreslí a přesně řekne „udělej tohle“, tak máš problém. Proto je důležité, aby tester uměl přemýšlet, doplnit si chybějící informace, odhadnout, co se ještě dá ověřit a co už je nad rámec.

Co bys řekl, že je taková základní výbava testera?

Určitě trpělivost. A schopnost myslet „out of the box“. Tester se musí umět podívat na věci jinak – přemýšlet za uživatele, ale i za vývojáře. Mít představivost a chuť hledat chyby. Nestačí jen jet podle návodu. Když ti někdo řekne: „Běž otestovat podepsání dokumentu,“ nestačí jen projít základní scénář – otevřít, podepsat, odeslat.

Musíš zkoušet i to, co se stane, když to pokazíš. Co se stane, když zadáš špatné údaje? Když zavřeš stránku uprostřed podepisování? Když klikneš tam, kam bys neměl?

Jaké je tedy největší nedorozumění, se kterým se nejčastěji setkáváš ohledně své práce?

Největší nedorozumění je představa, že chyby se dají odhalit všechny. Lidé si myslí, že jejich chyba je tak zásadní, že ji někdo musel určitě otestovat. Jenže v praxi těch kombinací existují doslova tisíce a není reálné otestovat úplně všechno. Vezmi si běžného uživatele: něco mu nefunguje, nevyhodí se chyba, obrázek se nezobrazí správně… a on si řekne: „Jak je možné, že jste tohle neodhalili?“ Jenže když si uvědomíš, kolik je těch možností – na kolika zařízeních, s jakým softwarem, v jakých kombinacích – testovat všechno na 100 % prostě nejde.

Existuje něco jako stereotypní tester?

Nemyslím si. Já třeba neznám nikoho, kdo by se k testování dostal cíleně. Většinou jsme se do toho všichni tak trochu „dostali náhodou“. Mě do toho rovnou hodili: „Tady to máš, tohle budeš dělat, nemáme na to člověka.“ A já jsem si řekl: „Dobře, zkusím to.“ A postupně jsem se učil.

Projevuje se nějaká profesní deformace v tvém soukromém životě?

Rozhodně ano. Vidím to, když mi někdo sdílí obrazovku a já sleduju, jak kliká. Jestli je rychlý, zmatený, jestli vůbec chápe navigaci. Sleduju rozhraní aplikací, přemýšlím, co by se dalo zlepšit, jak by to mělo fungovat. Když vyplňuju nějaký formulář nebo narazím na chybu v e-shopu, automaticky otevřu konzoli, podívám se do logů, hledám příčinu. A přiznám se, někdy i vyplňuju zpětnovazební formuláře, i když vím, že mě to zdržuje. Protože vím, že někde na druhé straně je někdo jako já, komu tím můžu pomoct.

Potřebuje člověk speciální vzdělání nebo schopnosti?

Myslím, že hlavně potřebuje zápal. A nějaké základní znalosti práce s počítačem. To, co já dnes považuju za běžné – jak se orientovat v systému, pracovat s prohlížečem, umět si něco otestovat sám – to není samozřejmost. Mně to přišlo přirozené, protože jsem se tomu věnoval roky. Ale spousta lidí bez těchto základů se do testování prostě nedostane.

A komu bys doporučil tuhle práci?

Každému, kdo rád řeší problémy, ale nechce přímo programovat. Někomu, kdo se rád „vrtá“ ve věcech, analyzuje, testuje, zkouší rozbít věci a pak hledá, proč se rozbily. Někdy je skvělé mít bug, který se zdá neřešitelný, ale pak najdeš ten jeden detail, který ho způsoboval, a máš z toho takový „boss fight“ zážitek jako ve hře. A to je ten nejlepší pocit.

Zmiňoval jsi videohry – ty jsi i recenzoval?

Ano, psal jsem přes 10 let. Bylo to takové hobby, které vyplynulo z toho, že jsem měl vztah ke hrám a dokázal jsem se na ně dívat trochu jinak – technicky i z hlediska uživatelského zážitku.

A věnuješ se hrám stále?

Jasně, pořád si zahraju. A občas mě to svádí k tomu, že si řeknu: „Tohle umím využít.“ Ale už si dávám pozor, protože vím, že to může pokazit celý zážitek. Třeba v hrách, kde máš inventář a můžeš předmět chytit a přenést – když během toho stiskneš jinou klávesovou zkratku, předmět se duplikuje. Takové věci ti můžou pokazit výzvu. A v hrách jako Dark Souls to úplně ničí atmosféru, když si to „ulehčíš“ exploitem.

Jaká je podle tebe nejlepší hra za poslední dobu?

Elden Ring. Je to RPG, primárně singleplayer. Obrovský otevřený svět. Historicky ale za nejlepší považuju Half-Life 2. To byl přelom, protože přinesl fyziku do her. Interakce s prostředím byla úplně jiná. Dnes to má například Baldur’s Gate 3 – a proto je tak úspěšný.