Proč se sada přepisovala a proč rovnou s AI
Klient měl funkční sadu automatizovaných webových testů v Seleniu. Nešlo tedy o to začít testovat, ale přestavět stávající řešení. Důvodem byla probíhající iniciativa sjednotit testovací nástroje napříč firmou, aby každý tým nepoužíval něco jiného. Jeden nástroj znamená jednotná pravidla, jedno know-how a jednu sadu postupů, kterou se vyplatí důkladně vyladit.
A když se už sada jednou přepisuje, je to nejvhodnější chvíle zapojit do ní AI. Záměrem bylo postavit ji tak, aby nejzdlouhavější část práce, tedy psaní a údržbu testů, převzala AI. Ruční přepis celé sady by byl prací na měsíce.
Pro tuto migraci poskytl Playwright vhodný moderní základ pro automatizaci prohlížeče v cílové sestavě Robot Frameworku. U jiného projektu je třeba výběr posoudit podle stávající sady, týmu a infrastruktury; tato kritéria podrobněji rozebírá srovnání Playwrightu a Selenia.
Zapojení AI do tvorby testů ale otevírá otázku důvěry. Na trhu jsou řešení slibující zcela autonomní testování, žádné z nich však nedokáže zaručit, že vygenerovaný test kontroluje právě to chování, které měl ověřit. A test, kterému se nedá věřit, je horší než žádný. Nemá velký smysl skončit s rozsáhlou sadou testů, které procházejí, ale o kterých nikdo nedokáže říct, zda se na ně lze spolehnout. Proto vznikla otázka, kde je v celém procesu nejlepší zapojit lidskou práci a kontrolu, aby byl výsledek spolupráce lidí a AI co nejspolehlivější a zároveň co nejrychlejší. Při testování musí být prioritou vždy spolehlivost a přesnost, nikoli rychlost.
Technologická sestava, která usnadňuje lidskou kontrolu
Cílovou sestavou byl Robot Framework s Browser Library, která ovládá prohlížeč prostřednictvím Playwrightu. Tato kombinace má vlastnost, která se při spolupráci s AI ukázala jako rozhodující: Robot Framework zapisuje testy čitelně, téměř ve větách, takže lze zkontrolovat, co test dělá, bez čtení implementace. U kódu, který píše stroj, nejde o kosmetickou výhodu: čím rychleji člověk přečte, co test ověřuje, tím snazší je jeho kontrola a tím větší část práce se vyplatí svěřit AI.
Testy používají design pattern Page Object Model, který odděluje scénáře od selektorů a operací nad stránkami. Nejde o vlastní výmysl. Doporučují ho tvůrci Playwrightu i Selenia a dlouhodobě se považuje za součást best practices.
Jak vznikne jeden test
Vstupem je testovací případ popsaný větami tak, jak ho napíše člověk, který zná požadované chování, nikoli jako kód. Podle potřeby k němu lze přidat také nahrávku průběhu a testovací data.
Vstup nejprve schválí kontrolor, tedy člověk, který rozumí zadání a dokáže posoudit, zda hotový test ověřuje správnou věc. Obvykle je to tester, podmínkou to však není. Teprve potom AI připraví plán, prostřednictvím Playwright MCP otevře aplikaci v prohlížeči a najde v ní skutečné prvky. Zjišťuje přitom také, zda lze použít již existující metody v page objektech, nebo je potřeba vytvořit nové. Výsledkem je test v Robot Frameworku spolu s page objekty, které pro něj chyběly. To, že se AI na aplikaci skutečně podívá, je rozdíl mezi testem, který lze spustit, a testem, který si domyslela podle toho, jak weby obvykle vypadají.
Přípravu a kontrolu kódu mají na starosti samostatné role agentů s vlastními pracovními postupy. Sdílená pravidla určují strukturu testů, výběr selektorů i použití Page Object Modelu. Nad tím běží automatické kontroly syntaxe, duplicit a lintingu.
Kde se to láme: test, který projde a nic neověří
Největší riziko generovaných testů nespočívá v tom, že nebudou fungovat. Spočívá v tom, že nebudou testovat to, co je potřeba v daném scénáři otestovat.
Když AI dostane úkol „ať test prochází“, má dvě cesty. Buď napíše test, který ověří požadované chování, nebo upraví ověření tak, aby odpovídalo tomu, co aplikace právě dělá. Druhá cesta je jednodušší a na první pohled vypadá stejně. Běh je zelený.
Stalo se to například u testu, který měl ověřit validaci jednoho pole ve formuláři: po zadání chybné hodnoty se měla zobrazit chybová zpráva. AI místo toho do pole vyplnila platnou hodnotu. Formulář prošel, test skončil zeleně a na první pohled vše vypadalo správně. Neověřená přitom zůstala právě ta jediná věc, kvůli které test vznikl.
Je proto důležité nastavit pravidla tak, aby k podobným situacím nedocházelo. Výslovně zakazují měnit význam scénáře, vynechávat požadované kontroly nebo přizpůsobovat očekávaný výsledek aktuálnímu chování aplikace bez schválení člověkem. Zelený běh tak zůstává pouze jedním z podkladů kontroly, nikoli jejím závěrem.
Co kontrolor posuzuje
Před přijetím nového testu nebo jeho opravy se hodnotí:
- zda kroky, testovací data a očekávané výsledky odpovídají slovnímu zadání,
- zda kód obsahuje ověření, která skutečně vyhodnocují požadovaný výsledek scénáře,
- zda jsou selektory a operace nad stránkami použity správně a test zůstává srozumitelný při další údržbě,
- zda navržená oprava zachovala původní účel testu a všechna potřebná ověření.
Když test selže
Při selhání dokáže AI znovu otevřít aplikaci prostřednictvím Playwright MCP a navrhnout opravu selektoru nebo page objektu. Tento postup je známý jako self-healing. Návrh prochází stejnou kontrolou jako nový test: zachoval původní účel a všechna ověření?
U sady v rozsahu stovek testů je však často důležitější jiná otázka: která selhání spolu souvisejí. Řešení proto seskupuje selhání podle významu chybových hlášení, dotčených lokátorů a podobných projevů. Namísto seznamu červených řádků tým vidí, že velká část z nich má jednu společnou příčinu, a ví, kde začít.
Testy lze spouštět lokálně i v procesu průběžné integrace a nasazování (CI/CD). Výsledky jsou dostupné ve standardních reportech Robot Frameworku i v Allure.
Jeden repozitář pro více projektů
Projekty žijí ve společném repozitáři (monorepo). Sdílená část obsahuje skilly s pracovními postupy, definice agentů, obecná pravidla a pomocné funkce nezávislé na konkrétním projektu, od založení scénáře přes tvorbu testů a page objektů až po vyhodnocování reportů a opravy.
V praxi to znamená, že nový projekt nezačíná v prázdném repozitáři, ale na postupech, které se již někde osvědčily. Práce v samostatných větvích a oddělených pracovních kopiích téhož repozitáře (worktree) umožňuje, aby na sadě pracovalo více lidí současně.
Co se tím změnilo
- Tvorba jednoho testu se z práce na hodiny změnila na násobně kratší přečtení a schválení vygenerovaného kódu.
- Migraci ze Selenia bylo možné provést v rozsahu, který by ručně trval velmi dlouho.
- Lidská pozornost se přesunula tam, kde má největší hodnotu: na zadání a na otázku, zda test ověřuje správnou věc.
- Selhání se řeší po skupinách se společnou příčinou, nikoli jedno po druhém.
- Nový projekt začíná na hotových postupech, agentech a pravidlech, nikoli od nuly.