Keď vidím, ako dobre si AI agenti počínajú už dnes, a keďže je často lepšie zadať úlohu voľnejšie a nechať agenta, aby navrhol riešenie podľa seba, núti ma to premýšľať nad tým, čo to v súčasnosti znamená pre testovanie softvéru. Rád by som rozobral niekoľko bodov, ktoré z tohto pozorovania vychádzajú, a potom predstavil jednu ideu – riešenie testovania, ktoré by sa dnes (v septembri 2026) dalo zaujímavo využiť.
Keď kód generujú, nech ho aj testujú
Znie to jednoducho a priamočiaro, no asi to až také jednoduché nie je. Do rovnice vstupuje najmä fakt, že softvér stále používajú ľudia, ktorí majú rôzne zázemie, patria do rozličných záujmových alebo profesijných skupín a majú rozdielnu úroveň technických zručností. Na konci dňa sú to najmä ľudia, nie AI agenti. Majú svoje preferencie, niečo im prekáža, majú vlastnú intuíciu a do hry vstupuje aj to, aký „pocit“ softvér vyvoláva, nielen jeho funkčnosť.
Funkčnosť je však jedným zo základných kameňov dobrého softvérového produktu. Ani pri dobrom UI/UX produkt neprinesie sľúbenú úžitkovú hodnotu, ak nefunguje správne, a tým stráca na význame.
Preto je dobré mať zabezpečenú vrstvu testovania, ktorá overuje základnú funkčnosť. Práve s tým dokážu pomôcť AI agenti. Keď sa dá slovami a empiricky definovať, ako má niečo fungovať od A po Z, dá sa to pomocou agenta aj overiť. Myslím si, že v súčasnom svete, kde AI implementuje riešenia na základe podrobných špecifikácií, by mala tieto špecifikácie aj overovať.
- Najmä prostredníctvom automatizácie testovania (unit testy > integračné testy > end-to-end testy).
- V súčasnosti už aj pomocou voľného agenta, ktorý na požiadanie prechádza systémom podľa testovacieho scenára.
A nemusíme skončiť iba pri takomto jednoduchom modeli.
Prečo nie viac agentov?
Pôvodné meme od @beginbot na X.
Prečo nemať viacero agentov? Predstavme si webovú aplikáciu s technologickým stackom, ako sú napríklad Next.js, NestJS, Redis a PostgreSQL, možno doplnenú o externé API. V TypeScript projekte by sme mohli vytvoriť skupinu agentov a inštruovať ich, aby už počas vývoja – kým vývojár vytvára aplikáciu – paralelne budovali vlastnú sadu testov a v správnom čase overovali všetko potrebné.
Mohli by sme mať:
- agenta pre unit testy, ktorý by spravoval sadu unit testov v NestJS backende (napríklad pomocou Jestu) a bol by inštruovaný, aby na požiadanie vykonával nízkoúrovňové scenáre na úrovni modulov,
- agenta pre integračné testy, ktorý by spravoval sadu integračných testov, napríklad tiež pomocou Jestu na backende, no pracoval by už aj s mockovanou databázou, Redisom a externým API a zároveň by bol odborníkom na vykonávanie scenárov v tomto prostredí na požiadanie,
- agenta pre end-to-end testy, ktorý by spravoval sadu testov v Playwrighte a bol by odborníkom na ovládanie prehliadača (v našom fiktívnom projekte by išlo asi o najdôležitejšieho testera na požiadanie),
- agenta pre záťažové testy, ktorý by spravoval testy v k6 a dokázal ich upravovať a spúšťať,
- agenta pre bezpečnostné testy, ktorý by tiež spravoval vlastnú sadu testov a špecializoval sa na bezpečnosť.
Napokon by sme mohli mať hlavného manažéra testovania, ktorý by všetkých týchto agentov koordinoval. Celý systém by mohol využívať spoločnú databázu výsledkov naviazaných na jednotlivé verzie aplikácie, vďaka čomu by mal prehľad aj o minulosti projektu. To je už o niečo zložitejší systém, ale napríklad pamäť v Claude Code odvádza v tejto oblasti sama osebe dobrú prácu.
Počas vývoja aj ako samostatný AI tím
Keďže kód by bol rozložený vo viacerých repozitároch, bolo by užitočné, keby táto AI vrstva fungovala nad všetkými repozitármi projektu naraz a mala spoločnú definíciu. Zároveň by bolo dobré, keby vývojárske AI nástroje vedeli, že sú takíto agenti dostupní, a ich implementátori ich počas vývoja podľa potreby „vyvolávali z jaskyne“.
Ľudia, ktorí by sa na projekte venovali testovaniu (stále testeri?), by zároveň mohli tento testovací tím samostatne aktivovať a zadávať mu úlohy.