Prečo sa sada prepisovala a prečo rovno s AI
Klient mal funkčnú sadu automatizovaných webových testov v Seleniu. Nešlo teda o to, začať testovať, ale prestavať existujúce riešenie. Dôvodom bola prebiehajúca iniciatíva zjednotiť testovacie nástroje naprieč firmou, aby každý tím nepoužíval niečo iné. Jeden nástroj znamená jedny pravidlá, jedno know-how a jednu sadu postupov, ktorú sa oplatí vyladiť poriadne.
A keď sa už raz sada prepisuje, je to najvhodnejšia chvíľa zapojiť do nej AI. Zámerom bolo postaviť ju tak, aby najzdĺhavejšiu časť práce, teda písanie a údržbu testov, prevzala AI. Ručný prepis celej sady by bola práca na mesiace.
Pre túto migráciu poskytol Playwright vhodný moderný základ pre automatizáciu prehliadača v cieľovej zostave Robot Frameworku. Pri inom projekte treba výber posúdiť podľa existujúcej sady, tímu a infraštruktúry; tieto kritériá podrobnejšie rozoberá porovnanie Playwrightu a Selenia.
Zapojenie AI do tvorby testov ale otvára otázku dôvery. Na trhu sú riešenia sľubujúce úplne autonómne testovanie, žiadne z nich však nevie ručiť za to, že vygenerovaný test kontroluje práve to správanie, ktoré mal overiť. A test, ktorému sa nedá veriť, je horší než žiadny. Nemá veľký zmysel skončiť s veľkou sadou testov, ktoré prechádzajú, ale o ktorých nikto nevie povedať, či sa im dá spoľahlivo veriť. Preto vznikla otázka, kde je v celom procese najlepšie zapojiť ľudskú prácu a kontrolu, aby bol výsledok spolupráce ľudí a AI čo najspoľahlivejší a zároveň čo najrýchlejší. Pri testovaní má byť prioritou vždy spoľahlivosť a presnosť, nie rýchlosť.
Zostava, ktorá uľahčuje ľudskú kontrolu
Cieľová zostava bola Robot Framework s Browser Library, ktorá ovláda prehliadač práve cez Playwright. Táto kombinácia má vlastnosť, ktorá sa pri spolupráci s AI ukázala ako rozhodujúca: Robot Framework drží testy v čitateľnom, takmer vetnom zápise, takže sa dá skontrolovať, čo test robí, bez čítania implementácie. Pri kóde, ktorý píše stroj, to nie je kozmetika: čím rýchlejšie vie človek prečítať, čo test overuje, tým ľahšia je jeho kontrola a tým väčšiu časť práce sa oplatí AI zveriť.
Testy používajú návrhový vzor Page Object Model, ktorý oddeľuje scenáre od selektorov a operácií nad stránkami. Nejde o vlastný výmysel. Odporúčajú ho tvorcovia Playwrightu aj Selenia a dlhodobo sa berie ako súčasť best practices.
Ako vznikne jeden test
Vstupom je testovací prípad opísaný vetami, tak ako ho napíše človek, ktorý pozná požadované správanie, nie ako kód. Podľa potreby sa k nemu môže pridať aj nahrávka priebehu a testovacie dáta.
Vstup najprv schváli kontrolór, teda človek, ktorý rozumie zadaniu a vie posúdiť, či hotový test overuje správnu vec. Obvykle je to tester, podmienkou to však nie je. Až potom AI pripraví plán, cez Playwright MCP si otvorí aplikáciu v prehliadači a nájde v nej skutočné prvky. Zisťuje pritom aj to, či sa dajú použiť už existujúce metódy v page objektoch, alebo treba vytvoriť nové. Výsledkom je test v Robot Frameworku spolu s page objektmi, ktoré preň chýbali. To, že si aplikáciu naozaj pozrie, je rozdiel medzi testom, ktorý sa dá spustiť, a testom, ktorý si AI domyslela podľa toho, ako weby zvyčajne vyzerajú.
Prípravu a kontrolu kódu majú na starosti samostatné roly agentov s vlastnými pracovnými postupmi. Zdieľané pravidlá určujú štruktúru testov, výber selektorov aj použitie Page Object Modelu. Nad tým bežia automatické kontroly syntaxe, duplicít a lintingu.
Kde sa to láme: test, ktorý prejde a nič neoverí
Najväčšie riziko generovaných testov nie je, že nebudú fungovať. Je to, že nebudú testovať to, čo treba v danom scenári otestovať.
Keď AI dostane úlohu „nech test prechádza“, má dve cesty. Buď napíše test, ktorý overí požadované správanie, alebo upraví overenie tak, aby sedelo s tým, čo aplikácia práve robí. Druhá cesta je jednoduchšia a na prvý pohľad vyzerá rovnako. Beh je zelený.
Stalo sa to napríklad pri teste, ktorý mal overiť validáciu jedného poľa vo formulári: po zadaní chybnej hodnoty sa mala zobraziť chybová hláška. AI do poľa namiesto toho vyplnila platnú hodnotu. Formulár prešiel, test skončil na zeleno a na prvý pohľad všetko sedelo. Neoverená pritom zostala práve tá jediná vec, kvôli ktorej test vznikol.
Je preto dôležité nastaviť pravidlá tak, aby k takýmto situáciám nedochádzalo. Výslovne zakazujú meniť význam scenára, vynechávať požadované kontroly či prispôsobovať očakávaný výsledok aktuálnemu správaniu aplikácie bez schválenia človekom. Zelený beh tak zostáva len jedným z podkladov kontroly, nie jej záverom.
Čo kontrolór posudzuje
Pred prijatím nového testu alebo jeho opravy sa hodnotí:
- či kroky, testovacie dáta a očakávané výsledky zodpovedajú slovnému zadaniu,
- či kód obsahuje overenia, ktoré skutočne vyhodnocujú požadovaný výsledok scenára,
- či sú selektory a operácie nad stránkami použité správne a test zostáva zrozumiteľný pri ďalšej údržbe,
- či navrhnutá oprava zachovala pôvodný účel testu a všetky potrebné overenia.
Keď test spadne
Pri zlyhaní vie AI znovu otvoriť aplikáciu cez Playwright MCP a navrhnúť opravu selektora alebo page objektu. Tento postup je známy ako self-healing. Návrh prechádza rovnakou kontrolou ako nový test: zachoval pôvodný účel a všetky overenia?
Pri sade v rozsahu stoviek testov je však často dôležitejšia iná otázka: ktoré zlyhania spolu súvisia. Riešenie preto zoskupuje zlyhania podľa významu chybových hlásení, dotknutých lokátorov a podobných prejavov. Namiesto zoznamu červených riadkov tím vidí, že veľká časť z nich má jednu spoločnú príčinu, a vie, kde začať.
Testy sa dajú spúšťať lokálne aj v procese priebežnej integrácie a nasadzovania (CI/CD). Výsledky sú dostupné v štandardných reportoch Robot Frameworku aj v Allure.
Jeden repozitár pre viac projektov
Projekty žijú v spoločnom repozitári (monorepo). Zdieľaná časť obsahuje skilly s pracovnými postupmi, definície agentov, všeobecné pravidlá a pomocné funkcie nezávislé od konkrétneho projektu, od založenia scenára cez tvorbu testov a page objektov až po vyhodnocovanie reportov a opravy.
Prakticky to znamená, že nový projekt nezačína na prázdnom repozitári, ale na postupoch, ktoré sa už niekde osvedčili. Práca v samostatných vetvách a oddelených pracovných kópiách toho istého repozitára (worktree) umožňuje, aby na sade pracovalo viac ľudí naraz.
Čo sa tým zmenilo
- Tvorba jedného testu sa z práce na hodiny zmenila na násobne kratšie prečítanie a schválenie vygenerovaného kódu.
- Migrácia zo Selenia sa dala spraviť v rozsahu, ktorý by ručne trval veľmi dlho.
- Ľudská pozornosť sa presunula tam, kde má najväčšiu hodnotu: na zadanie a na otázku, či test overuje správnu vec.
- Zlyhania sa riešia po skupinách so spoločnou príčinou, nie po jednom.
- Nový projekt začína na hotových postupoch, agentoch a pravidlách, nie od nuly.