Čo si ľudia v tvojom okolí myslia, že robíš?

No, vzhľadom na to, že túto prácu som robil už aj počas covidu, a vtedy som niekoľko mesiacov trávil u rodičov, tak mali možnosť vidieť to na vlastné oči. A z veľkej časti sa reakcie ľudí dajú zhrnúť asi takto: „Veď ty vlastne robíš to isté, čo keď si sa ako dieťa hrával na počítači, nie?“ Teda, že len klikám a sledujem, čo sa deje.

Ale to je samozrejme veľmi zjednodušený pohľad. Mám technické zázemie, takže moji blízki možno trochu chápu, o čo ide. Keď poviem, že som tester, často si predstavia, že len klikám viacej ako iní. A možno je to aj pravda, ale nie je to len o kliknutí.

Ľudia si podľa mňa často neuvedomujú rozsah a komplexnosť tejto práce. Napríklad, kým som bol len používateľom, a nie testerom, tiež som si hovoril: „Ako je možné, že si túto chybu nevšimli?“ Ale keď som sa dostal na druhú stranu, pochopil som, že kombinácií, ktoré treba otestovať, sú tisíce. Naozaj sa nedá pokryť úplne všetko. Nie je možné otestovať aplikáciu na 100 %. Každý si myslí, že práve tá jeho chyba je zásadná a mala byť odhalená. Ale realita je taká, že sa to jednoducho nedá. A to je podľa mňa najväčšie nedorozumenie.

A ako to teda vyzerá v praxi? Kedy vstupuješ do procesu vývoja?

Keď programátor dokončí svoju prácu, odovzdá ju mne, teda označí danú funkcionalitu v systéme, aplikácii alebo riešení ako „ready for review“, čiže pripravenú na testovanie. Dôležité je však vedieť, že to neznamená, že je to nasadené u klienta. V rámci nášho procesu máme niekoľko prostredí, developerské, integračné a až potom produkčné. Testovanie prebieha primárne na developerskom a na integračnom prostredí len pri výnimočných situáciách.

Napríklad, keď sa vyvíja nová funkcionalita, tak nezasahujem hneď počas vývoja, ale až keď je celok hotový. Je zbytočné testovať polovičaté riešenia, lebo ďalšie časti môžu ovplyvniť tie predošlé. Čiže keď sa niečo dokončí, ja dostanem informáciu, že to je hotové, nasadí sa to na testovacie prostredie a ja začínam testovať.

Ako vyzerá testovanie konkrétne?

Najprv si prejdem, čo bolo upravené alebo pridané. Mám pripravený testovací scenár, teda presné kroky, ako simulovať danú situáciu. Ak sa chyba prejaví tak, ako som ju popísal, a je odstránená, môžem to považovať za vyriešené. Ak nie, vraciam to späť vývojárovi a doplním presný popis chyby.

V takom prípade vytváram tzv. „issue“ v JIRA, to je nástroj, ktorý používame na sledovanie celého vývojového cyklu. Do tejto „issue“ napíšem názov chyby, popis, v akej verzii sa vyskytla, v akom prostredí, priložím screenshoty a najmä presné kroky, ako chybu nasimulovať. Vývojár musí vedieť, ako sa k nej dostanem, lebo on si to potrebuje vedieť u seba overiť.

Napríklad: prihlás sa, klikni na dokument, urob toto, tam sa niečo pokazí... Musí to byť presné.

Čiže pre každý bug vytváraš takýto „protokol“?

Áno. A ten protokol nie je len o texte. Musí byť technicky zrozumiteľný, musí obsahovať aj obrázky, verziovanie, presné podmienky. Napríklad, môže sa stať, že vývojár nedokáže chybu zopakovať a vtedy zisťujeme, či nejde o problém len v konkrétnom prehliadači alebo zariadení. Môže sa stať, že ja som testoval v Chrome, ale on vo Firefoxe. A chyba sa prejavuje len tam. Alebo dokonca len na iPhone, alebo len na Androide s konkrétnou verziou.

Dokonca raz sme mali nahlásený bug a nakoniec sme zistili, že používateľ mal prehliadač DuckDuckGo. Takže testovať úplne všetky možné kombinácie hardvéru, softvéru a prostredí je nereálne. Preto sa vždy sústredíme na to, čo je relevantné pre cieľový trh, napríklad, ak testujeme.

A ten tvoj testovací scenár, to je nejaký štandardizovaný dokument?

Áno, máme vytvorené testovacie scenáre. Niektoré som písal ja, niektoré moji kolegovia. Ideálne by tieto scenáre mali byť zdokumentované a zdieľané medzi všetkými testermi, hlavne ak je v tíme viac ľudí. Niektoré scenáre sú určené aj pre automatizované testy, tie sú uložené v špeciálnych kolekciách a tiež majú popísané, čo robia, aký je očakávaný výsledok.

A čo sa deje, keď nájdeš napríklad tridsať bugov?

Každý jeden zadám do JIRA ako samostatné issue. Každý z nich musí byť popísaný, zdokumentovaný, a vývojár si ich prejde. Keď ich opraví, znova nasadí upravenú verziu, a ja opäť prechádzam všetky scenáre. Ak je všetko vyriešené, označím to ako uzavreté a môžeme ísť ďalej.

A opakuje sa to vždy pri každej verzii?

Presne tak. Pri každej novej verzii. Máme napríklad verziu 1.0, vývojári opravili bugy, a ja testujem znova. Ak sú tam stále chyby, cyklus sa opakuje.

Existuje niečo ako „bezchybná verzia“?

Teoreticky áno. Ale v praxi nie. Každá aplikácia má bugy. Ide o to, ktoré sú ešte akceptovateľné. Napríklad, bug, ktorý sa prejaví len pri kombinácii Firefox na iPade, to je tak marginálne, že je to považované za nízku prioritu. Samozrejme, sú kategórie bugov. Máme „blocker“, čo znamená, že nemôžeme nič robiť ďalej, napríklad ak nefunguje server. Potom sú „critical“, čo sú chyby v základnej funkcionalite. Nasledujú „major“, „minor“ a nakoniec „trivial“, ako napríklad logo v nižšom rozlíšení alebo nepresne zobrazený prvok na neštandardnom zariadení. Tie sú väčšinou len kozmetické.

Koľko toho vlastne treba naozaj testovať? Je to vôbec kvantifikovateľné?

To sa veľmi ťažko vyčísľuje, ale často to prirovnávam k tomu, že testovanie zaberá minimálne polovicu celého vývoja. Nie je to niečo, čo sa dá urobiť len tak „popri“. Ak niečo programuješ týždeň, tak aspoň rovnaký čas sa tomu musí venovať aj na testovanie. A čím zložitejšia je aplikácia, tým viac kombinácií vzniká a tým viac času treba.

Napríklad jazykové mutácie, to je kapitola sama o sebe. Ak máš aplikáciu, ktorá beží v angličtine, poľštine, maďarčine, češtine a slovenčine, tak musíš všetko preklikať v každej verzii. A to aj vtedy, keď nerozumieš konkrétnemu jazyku. Vtedy sa aspoň pozeráš, či tam nechýbajú texty, či nie je niečo zle zalomené, alebo sa ti nezobrazujú znaky z iného jazyka. Už sa nám aj stalo, že v maďarskej verzii sa zobrazovala nejaká hláška v ukrajiništine. Takéto veci sa jednoducho dejú.

Testovanie je podľa mňa stále podceňované v tom, koľko času a energie si vyžaduje. A to hovorím aj o manuálnom testovaní, kde musíš všetko robiť ručne: kombinácie vstupov, rôzne zariadenia, rôzne situácie.

A čo tie prípady, ktoré sa nedajú testovať automaticky? Všetko robíte ručne?

Dlho sme fungovali čisto manuálne, no teraz prechádzame na to, aby sme aspoň časť scenárov pokrývali automatizovane. Máme s vývojármi spoločný cieľ, vytvoriť automatizované testy, ktoré sa spúšťajú každý deň. Zároveň ale tvorím nové, kratšie manuálne scenáre, ktoré sa dajú prejsť za deň alebo dva. Nejde o to, aby sme testovali všetko naraz, ale aby sme vedeli operatívne preveriť dôležité časti.

A keď už prejdeš všetky scenáre, čo potom? Projekt tým pádom pre teba končí?

Záleží od projektu. Niekedy sa tým moje zapojenie skončí, inokedy pokračujem aj po nasadení do produkcie, robím podporu, konzultácie so zákazníkom. Naozaj to závisí od toho, ako je projekt nastavený.

Pri svojej práci teda musíš myslieť ako používateľ?

Skúšam sa vžiť do úlohy používateľa, a nie vždy je to jednoduché. Každý používateľ má iné návyky, každý používa systém iným spôsobom. Sú ľudia, ktorí klikajú nelogicky, zmätočne, alebo niečo robia úplne inak, než by si čakal. A práve oni často objavia chyby, ktoré bežné testovanie neodhalí. Preto sa stáva, že klient nahlási chybu a my len krútime hlavou, „veď my sme to testovali, všetko bolo v poriadku!“

A čo potom robíš?

Začnem overovať, skúšať, simulovať... a nie vždy sa mi to podarí. Sú situácie, keď neviem chybu zopakovať. A to je najhoršie, keď nevieš, čo presne ten človek urobil. Zistíš, že išiel nejakou veľmi neštandardnou cestou, ktorú by bežný používateľ nikdy neskúsil. Vtedy si musíš vyhodnotiť: je to chyba, ktorá sa môže opakovať, alebo je to niečo tak ojedinelé, že to nestojí za opravu?

Napríklad pri veľkých systémoch ako sú portály s dokumentmi, kde máme desiatky tisíc používateľov, sa môže stať, že niekomu nepôjde registrácia. A pre nás je to signál: OK, treba sa pozrieť do logov, zistiť, prečo sa to stalo. Možno je to len technická výnimka. Alebo to človek skúšal v čase, keď mu padol internet. No a tam sa často pozrieme do developerskej konzoly, sledujeme, aká odpoveď tam prišla zo servera, čo sa stalo. Ak to viem nasimulovať, viem chybu potvrdiť a riešiť. Ak nie, musím pátrať ďalej.

Aké sú najbizarnejšie scenáre?

Klasika je, že používateľ trikrát po sebe klikne na rovnaké tlačidlo. Ale nie v zmysle, že kliká zo zúfalstva, že sa niečo nenačítava. Ide o tie situácie, keď sa nejaké tlačidlo zobrazí len na sekundu a on je schopný ho stlačiť trikrát po sebe, a tým rozbije celý proces.

Alebo testujeme situácie s pomalým internetom, musím si spomaliť prehliadač, nastaviť oneskorenia, lebo to simuluje reálne prostredie používateľov, ktorí bývajú na miestach s horším signálom. Ľudia fungujú rôzne, majú rôzne zariadenia, podmienky. Niekto klikne na niečo, potom ide variť, vráti sa o dve hodiny a očakáva, že stále bude môcť pokračovať, ako keby sa nič nestalo. Ale aplikácia medzičasom vypršala, odhlásila ho, alebo expiroval link. A oni sa čudujú, že prečo to nejde.

A stretávaš sa aj s tým, že klient nahlási chybu, ale reálne nejde o bug?

To je častý scenár. Napríklad niečo v dokumentácii je popísané, ako má systém fungovať, ale používateľ to spraví úplne inak, nie podľa toho, ako sa očakáva. A potom sa mu niečo pokazí. Ozve sa, že má bug, ale v skutočnosti len obišiel proces, ako bol navrhnutý. A my to musíme vyhodnotiť, je to reálna chyba? Alebo len nesprávne použitie? A niekedy je to produkčný bug, ktorý treba riešiť okamžite. Inokedy len používateľ spravil niečo, čo mu systém síce povolil, ale nemal. A z toho vznikol problém. Tester musí vedieť túto hranicu identifikovať.

Takže musíš poznať aj systém zvnútra, aj zvonku.

Určite. Napríklad, ja dodnes neviem presne, ako vyzerá v reálnom prostredí internetbanking banky, ak ho osobne nepoužívam. Ale poznám procesy, viem ako fungujú, ako majú spolupracovať s inými modulmi. Nám to trvalo mesiace, kým sme pochopili všetky súvislosti. Napríklad na to, aby naša aplikácia fungovala, musí byť všetko prepojené s ďalšími viac ako 10 systémami od rôznych dodávateľov. Každý robí niečo iné, všetko musí spolu ladiť. A ešte to musí celé prejsť bezpečnostným auditom, schvaľovaním, kontrolou...

Spomínal si, že spolupracuješ s analytikmi aj vývojármi. Kto je tvoj najbližší okruh ľudí, s ktorými denne komunikuješ?

Primárne sú to vývojári a analytici. S analytikmi riešim logiku systému, funkčné požiadavky, s vývojármi zasa to, ako je čo implementované, aké boli technické obmedzenia. Občas sa k tomu pridá aj projektový manažér, konzultant, niekedy priamo klient. A niekedy, keď chyba spadne mimo môjho testovacieho rámca, tak odpovedám na to aj ako konzultant, teda hľadám, čo sa vlastne stalo, prečo sa to nepodarilo nasimulovať a kto by mohol mať odpoveď.

Ako si sa vlastne dostal k IT?

V podstate to začalo ako hra. Doma sme mali počítač, nejaké tie prvé hry, ktoré mi rodičia zakázali, lebo vraj „krvavé“, ako napríklad Duke Nukem. Ale mňa to fascinovalo. Skúšal som obchádzať zákazy, kopírovať si hry, inštalovať ich tajne, schovávať inštalácie do skrytých priečinkov...

Postupne som sa do toho dostával, učil sa veci sám, skúšal. A to je vec, ktorá mi neskutočne pomáha aj dnes. Lebo mnohí ľudia si povedia: „Veď ja robím s počítačom denne.“ Ale keď robíš 10 rokov v banke a otváraš stále len Excel alebo Word, tak ešte neznamená, že rozumieš princípom. Povieš „Tlačidlo Windows + E? Netuším, čo to robí.“ Ale keď si ten typ človeka, čo sa rád „vŕta“ v systéme, skúša, hľadá, tak potom máš veľkú výhodu. Vieš sa na veci pozrieť inak.

Čiže tester by mal byť trochu ako „samorast“?

Tester v našom tíme by nemal byť niekto, kto čaká, že mu vždy dajú presné zadanie a podľa neho ide krok za krokom. Jasné, niekedy to tak je. Ale často to tak nie je. Napríklad my máme niekedy aj osemdesiatstranové dokumentácie. Plné popisov, ako má čo fungovať. Lenže aj tak sa veľa vecí nedá úplne nasimulovať. V bankovom prostredí máš toľko špecifík, že to všetko preniesť do testu je takmer nemožné. A ak čakáš, že ti niekto všetko nakreslí a presne povie „urob toto“, tak máš problém. Preto je dôležité, aby tester vedel rozmýšľať, vedel si doplniť chýbajúce informácie, vedel odhadnúť, čo sa ešte dá overiť a čo už je nad rámec.

Čo by si povedal, že je taká základná výbava testera?

Určite trpezlivosť. A schopnosť myslieť „out of the box“. Tester sa musí vedieť pozrieť na vec inak, rozmýšľať za používateľa, ale aj za vývojára. Mať predstavivosť a chuť hľadať chyby. Nestačí len ísť podľa návodu. Keď ti niekto povie: „Choď otestovať podpis dokumentu,“ tak nestačí len prejsť základný scenár — otvoriť, podpísať, odoslať.

Musíš skúšať aj to, čo sa stane, keď to pokazíš. Čo sa stane, keď zadáš nesprávne údaje? Keď zatvoríš stránku uprostred podpisovania? Keď klikneš tam, kam by si nemal?

Aké je teda najväčšie nedorozumenie, s ktorým sa najčastejšie stretávaš ohľadom tvojej práce?

Najväčšie nedorozumenie je predstava, že chyby sa dajú odhaliť všetky. Ľudia si myslia, že ich chyba je taká zásadná, že ju musel niekto určite otestovať. Lenže v praxi sú tých kombinácií doslova tisíce a nie je reálne otestovať úplne všetko. Zober si bežného používateľa: niečo mu nefunguje, nevyhodí sa chyba, obrázok sa nezobrazí správne... a on si povie: „Ako je možné, že ste práve toto neodhalili?“ No lenže keď si uvedomíš, koľko je tých možností, na koľkých zariadeniach, s akým softvérom, v akých kombináciách... testovať všetko na 100 % sa nedá.

Existuje niečo ako stereotypný tester?

Nemyslím si. Ja napríklad nepoznám nikoho, kto by sa k testovaniu dostal cielene. Väčšinou sme tam všetci tak trochu „spadli“. Mňa do toho hodili rovno: „Tu máš, toto budeš robiť, nemáme na to človeka.“ A ja som si povedal: „Tak dobre, vyskúšam.“ A postupne som sa učil.

Prejavuje sa nejaká profesionálna deformácia v tvojom súkromnom živote?

Vidím to, keď mi niekto zdieľa obrazovku a ja sledujem, ako kliká. Či je rýchly, či zmätočný, či vôbec rozumie navigácii. Sledujem rozhrania aplikácií, čo by sa dalo zlepšiť, ako by to malo fungovať. Keď vyplňujem nejaký formulár alebo narazím na chybu v e-shope, tak automaticky spustím konzolu, pozriem logy, hľadám príčinu. A priznám sa, niekedy aj vypĺňam feedback formuláre, aj keď viem, že ma to zdržuje. Lebo viem, že niekde na druhej strane je niekto ako ja, komu tým môžem pomôcť.

Potrebuje človek špeciálne vzdelanie alebo schopnosti?

Myslím, že potrebuje hlavne zápal. A nejaké základné znalosti práce s počítačom. To, čo ja dnes považujem za bežné — ako sa orientovať v systéme, pracovať s prehliadačom, vedieť si niečo otestovať sám — to nie je samozrejmosť. Mne to prišlo prirodzené, lebo som sa tomu venoval roky. Ale veľa ľudí bez tohto základu sa do testovania jednoducho nedostane.

A komu by si odporučil túto prácu?

Každému, kto rád rieši problémy, ale nechce priamo programovať. Niekoho, kto sa rád vŕta vo veciach, analyzuje, testuje, skúša rozbiť veci a potom hľadá, prečo sa rozbili. Niekedy je fajn mať bug, ktorý je zdanlivo nevyriešiteľný, ale potom nájdeš ten jeden detail, ktorý ho spôsoboval, a máš z toho taký „boss fight“ zážitok ako v hre. A to je ten najlepší pocit.

Spomínal si videohry, ty si aj recenzoval?

Áno, písal som viac ako 10 rokov. Bolo to také hobby, čo vyšlo z toho, že som mal vzťah k hrám a vedel som sa na ne pozerať trochu inak, aj technicky, aj z hľadiska používateľského zážitku.

A hrám sa venuješ stále?

Jasné, stále si zahrám. A občas ma to zvedie k tomu, že si poviem, „toto viem “. Ale už si dávam pozor, lebo viem, že to dokáže pokaziť celý zážitok. Napríklad v hrách, kde máš inventár a vieš predmet chytiť a preniesť – keď počas toho stlačíš inú klávesovú skratku, predmet sa zduplikuje. Takéto veci ti môžu pokaziť výzvu. A v hrách ako Dark Souls to úplne ničí atmosféru, keď si to „zľahčíš“ exploitom.

Čo najlepšia hra za posledné obdobie?

Elden Ring. Je to RPG, primárne singleplayer. Obrovský otvorený svet. Historicky za najlepší považujem Half-Life 2. To bol prelom, lebo priniesol fyziku do hier. Interakcia s prostredím bola úplne iná. Dnes to má napríklad Baldur’s Gate 3, preto je taký úspešný.