Softvérový vývoj sa diametrálne zmenil – hlavne za posledné mesiace. Boom AI vo vývoji sa v mojej bubline datuje približne od januára 2026, keď veľa vývojárov, ktorí dovtedy ešte nič nepoužívali, začalo používať AI agentov na vývoj. Odvtedy sa celý ten náš priemysel posunul úplne mimo toho, čo bolo predtým zaužívané. Teraz už veľmi málo ľudí pochybuje o tom, že kód sa už ručne písať nebude. Stále však platí, že momentálne AI nástroje vykazujú lepšie výstupy, ak fungujú ako predĺžená ruka profesionála – softvérového inžiniera, ktorý vie, ako s agentom čo najefektívnejšie komunikovať, aby dosiahol kvalitný výsledok.

Ruka v ruke s meniacim sa svetom musia ísť aj ľudia z oblasti QA – čiže tí, ktorí sa starajú o kvalitu vyprodukovaného softvéru v tíme a berú za ňu zodpovednosť. S meniacim sa spôsobom konzumácie softvéru bude podľa mňa aj táto sféra ešte podliehať masívnym zmenám a profesia sa ešte viac „shapeshiftne“. Nateraz však nemôžeme snívať. Softvér stále používajú milióny ľudí, ktorí klikajú na tlačidlo a vypĺňajú polia. Ako teda momentálne takýto softvér čo najlepšie otestovať?

Rád by som tu zhrnul svoju víziu a zároveň aj to, čo a ako teraz robím ja na svojom projekte. Každý projekt má svoje špecifiká, no ten môj je podľa mňa momentálne dosť častým typom – aj čo sa týka zamerania produktu, aj technológií, ktoré používame. Čo je to za projekt, opíšem o chvíľu, aby sme boli v obraze. Hneď na začiatok by som však rád podotkol, že na projekte momentálne fungujem v takej hybridnej úlohe – vo svojej AI kuchyni produkujem aj produkčný kód v appke, na ktorý si trúfam, a popritom sa starám aj o QA stránku nášho projektu.

Čo testujeme

Ide o AI chatbota pre firmu v právnom odvetví. Zjednodušene ide o akýsi interný ChatGPT, do ktorého inkrementálne implementujeme nápady prichádzajúce z inovačného tímu klienta. Technologicky ide o webovú aplikáciu v Next.js, pričom serverová časť beží v NestJS v ďalšom samostatnom repozitári. Potom máme ešte nejaké špecifické doplnky, z ktorých má každý vlastný repozitár (add-in do Wordu a Outlooku). Takisto sa dávnejšie implementoval aj vlastný textový procesor, ktorý pomáhal pri vytváraní RAG pipelines v infraštruktúre, ktoré si môžu používatelia podľa svojej vôle v našej appke vytvárať. Používateľská a serverová časť webovej appky sú teda v TypeScripte.

Ako sme testovali

Poďme si najprv stanoviť nejaký východiskový stav – ako sa to robilo predtým, respektíve ešte celkom nedávno, doslova pred pár mesiacmi. Väčšinou sa manuálne testovanie robilo pre každý „ticket“ alebo podľa vopred pripraveného scenára (regresné testy). Automatizované testy sa vytvárali buď na základe opravy chyby či implementovanej funkcionality, alebo v rôznom čase po implementácii – podľa toho, aký komplexný mal byť daný test, koľko komponentov v požadovaných verziách v ňom muselo fungovať a koniec koncov aj podľa toho, aký tím testerov na teste pracoval. Testy boli rôzne zložité podľa toho, na akej úrovni testovacej pyramídy boli implementované.

Čiže buď išlo len o manuálne vykonanie testovania testerom, ktoré zaberalo čas, hlavne ak zahŕňalo aj nejakú analýzu, sledovanie dát v databáze, cache a podobne. Takisto vývoj automatizovaného testu zaberal kopu času – vytvoriť test často trvalo aj tri dni alebo viac, podľa toho, o aký test išlo.

Ako sa dá testovať teraz

Momentálne máme z môjho pohľadu tri druhy testovacích aktivít, ktoré vieme voľne kombinovať, pretvárať do hybridných podôb a implementovať ich do nášho pracovného postupu:

  1. manuálne testovanie človekom,
  2. automatizácia testovania,
  3. testovanie riadené AI agentom.

Poďme si ich jeden po druhom rozobrať, pozrieť sa, akú úlohu zohrávajú v súčasnosti a ako sa dajú kombinovať, a potom si dáme „reality check“.

Manuálne testovanie

Konečným produktom je stále väčšinou aplikácia, v ktorej používateľ kliká a zadáva veci cez klávesnicu a myš, respektíve často s aplikáciou pracuje cez mobilné rozhranie. Konečný používateľ je tak stále ľudský organizmus a softvér vníma svojimi zmyslami. Kdesi v podcaste som počul, že dizajn hier, čiže to, aby bola počítačová hra zábavná, sa stále ťažko dosahuje pomocou programovania s LLM, lebo konečný zážitok je niečo viac než súbor herných mechaník a ich grafického prevedenia. Je to čosi viac, čo hráčovi sedí – „feels good“. Toto sa podľa mňa dá v určitom zmysle aplikovať aj na klasický softvér, v našom prípade na webové aplikácie. Stále totiž zohráva veľkú úlohu to, aký pocit produkt vyvoláva a ako ľahko a dobre môže konečný používateľ využívať hodnotu, ktorú aplikácia prináša.

Preto, kým budú softvér používať ľudia, je dobré, ak na konci testovacej stratégie stojí tester – reálny človek. Mal by sa sústrediť na veci, ktoré dávajú najväčší zmysel, čiže na najpoužívanejšie funkcionality a rozhrania, hlavne na to, čo je jadrom produktu. Dobrou stratégiou je pri práci na automatizácii testov a inštruovaní AI agenta k testovaniu pýtať sa ho: „Čo mám otestovať ja (človek)?“ Tým už však predbieham hybridné metódy. Poďme k ďalšej aktivite.

Automatizácia testov

Automatizácia testov je lacná a momentálne je hriech ju nevytvárať. Super je, že jej kód už málokedy treba písať ručne – treba však napísať, respektíve pripraviť pravidlá (inštrukcie pre AI agenta), aby sa efektívne generovala sama. Myslím tým využitie súboru AGENTS.md (alebo CLAUDE.md či čohokoľvek iného, čo tím používa v repozitári či repozitároch; v texte už budem používať len prvý pojem) a zadefinovanie základu pre všetky úrovne testovacej pyramídy.

  • Čiže v serverovej časti vybrať testovací nástroj – napríklad v našom prípade Jest – a v AGENTS.md spomenúť, že unit testy sú písané v Jeste a že vždy, keď je to vhodné (keď proti tomu neexistuje pádny argument), treba popri oprave chyby alebo implementácii funkcionality vytvoriť nový unit test.
  • Stanoviť v serverovej časti, ako budú vyzerať integračné testy, a podobne inštruovať AGENTS.md.
  • Pripraviť prostredie pre end-to-end testy – napríklad u nás v Playwrighte v repozitári používateľskej časti – a v príslušnom AGENTS.md spomenúť, že sú uložené práve tu.

Človeku starajúcemu sa o automatizáciu testov potom ostane len starosť o údržbu tohto kódu, spúšťanie testov a analýza výsledkov. Áno, testy sa budú robiť samy. Ani pri kontrole PR vôbec nemusia byť tieto testy v centre pozornosti – zaberá to čas a vývojári by sa mali sústrediť na produkčný kód (kód v rámci code review v septembri 2026 stále kontrolujú vývojári). Ak majú testy nejaké problémy, mal by ich udržiavať napríklad človek, ktorý sa bude v tíme venovať testovaniu a ktorého čas bude trochu lacnejší.

Výhodou je, že pri oprave chyby alebo implementácii funkcionality vývojár často nahromadí krásne množstvo relevantného kontextu k implementácii, na ktorej pracuje. Bolo by škoda zahodiť túto príležitosť a neinštruovať pritom AI agenta, aby testy vygeneroval vo chvíli, keď presne vie, o čo ide. Keď to pridáme do systémových inštrukcií (AGENTS.md), vývojár sa nemusí o nič starať a testy sa budú generovať popri implementácii.

Testovanie AI agentom

Dostávame sa k bodu, ktorý už asi bude splývať s tým, ako tieto tri aktivity – manuálne testovanie, automatizáciu testov a testovanie AI agentom – kombinovať. Už sme si povedali, ako vývojár navrhuje riešenie a aké nastavenie pre QA by mal mať k dispozícii. Keď úloha („ticket“) prejde kontrolou PR – čo je podľa mňa stále dobrý kontrolný bod –, môže nasledovať akási kontrola QA.

Tu sa dostávame k zlatému klincu programu. Nastáva moment, keď si tester môže vziať úlohu a spraviť komplexnú kontrolu QA nad tým, čo sa implementovalo. Keď so svojím AI „harnessom“ prepojí napríklad aj Jiru alebo Linear (podľa toho, čo tím používa), často stačí číslo úlohy a ide sa na to:

“Let's test TICKET-001. Test the implementation yourself, check what the test coverage is across all levels (unit, integration, e2e). Run all the E2E tests at the end of your testing to make sure it didn't mess anything up elsewhere in the system.”

Po správnom nastavení Playwrightu a získaní prístupu k repozitárom aj Jire je AI agent často natoľko šikovný, že už bude vedieť, ako spraviť veľkú časť práce. Super je napríklad to, že Claude Code, ktorý používam, má pamäť. Okrem spoločných systémových inštrukcií, ktoré používam, mám teda v pamäti už aj značné množstvo informácií o tom, čo som robil nedávno, a on z nich čerpá.

AI si vie natiahnuť úlohu a jej opis, presné zmeny v kóde aj testy, ktoré sa implementovali... „You get the point.“ Claude Code je u mňa dostatočne múdry na to, aby si pripravil všetko, čo potrebuje – buď ide do používateľskej časti (cez prihlasovacie údaje, ktoré používam v súbore Playwright .env.test), alebo spustí dočasné kontajnery Docker pre databázu či „cache“, prípadne si pripraví skript a vygeneruje dáta. V tejto dobe je úžasné niečo testovať. Na všetky hlúposti a hraničné prípady, na ktoré sme museli myslieť, už teraz myslieť nemusíme.

Pohľad z odstupu

Toto všetko je pekné, ale realita u nás je napríklad taká, že všetky projekty – používateľská časť webu, serverová časť, doplnky a „DevOps pipelines“ – sú v osobitných repozitároch. Žijú pod jednou strechou v Azure DevOps, ale medzi sebou nekomunikujú. Preto sme si pripravili nielen AGENTS.md v každom repozitári, ale aj ďalší AGENTS.md v lokálnom nadradenom priečinku, do ktorého si vývojár naklonuje všetky repozitáre. Ten hovorí o tom, čo majú spoločné a čo ktorý repozitár rieši. Svoj AI nástroj (v mojom prípade Claude Code) si tak viem otvoriť v tomto nadradenom priečinku a AI skáče do projektov, do ktorých potrebuje.

Zatiaľ som si vytvoril ešte jeden priečinok s ďalšími AI inštrukciami, ktoré mám len pre seba. Viac tam napríklad rozprávam o tom, aké testovacie vrstvy máme, aké sú konvencie názvov úloh, vetiev a PR či celkové pravidlá pre opisy. Alebo že nechcem veľa komentárov v kóde a podobne.

Pointa však je, že systém pozostáva z viacerých Git repozitárov. Ak chceme, aby AI agent vedel o všetkých, musíme ho pustiť do nejakého nadradeného priečinka, v ktorom bude mať prístup ku všetkým, a zároveň mu dať kompaktné informácie o tom, čo je to za systém a čo má kde hľadať.

QA sa posúva k testovaniu ľudského vnímania produktu

Alternatívny pohľad na problematiku a na to, ako sa dá báza automatizovaných testov rozšíriť napríklad o performance alebo security testy, uvádzam v článku Tím testing AI agentov.

Vyústením celého tohto textu je, že sa pri testovaní môžeme naozaj sústrediť na to, čo aj subjektívne vnímame ako dôležité. Povedal by som, že subjektivita testera teraz zohráva ešte väčšiu úlohu než kedysi. Už to nebude analýza hraničných hodnôt a podobné techniky, ktoré sme sa učili pri certifikácii ISTQB. Tieto logické testy vygeneruje AI. Našou úlohou bude vcítiť sa do roly používateľa a používať softvér ako on. Možno by som aj povedal, že je čas, aby sa QA začalo približovať používateľom oveľa viac než kedykoľvek predtým.