Když se dnes mluví o AI a testování, často se směšují dvě různá témata. Prvním je testování samotné AI. Ta do podnikových procesů přináší další úroveň komplexity a úplně nové problémy. Budeme muset hledat způsoby, jak vyhodnocovat výsledky modelů, pracovat s jejich nedeterministickým chováním a ověřovat, zda AI proces nejen technicky proběhl, ale také skončil přijatelným výsledkem.
K tomu se ale chci vrátit v některém z dalších článků. Dnes bych chtěl začít u tradičnějšího problému: jak s pomocí AI testovat klasické aplikace. Po každém technologickém zemětřesení je totiž podle mě vhodné znovu vyhodnotit některé zažité postupy. Ne proto, že by automaticky přestaly platit, ale protože nové nástroje mohou zásadně změnit náklady na jejich používání.
Možná od low-code platformy přirozeně očekáváte, že vás od některých tradičních problémů vývoje softwaru odstíní. A do určité míry je to správná úvaha. Nemusíme od začátku vytvářet formulářový framework, bezpečnostní model, databázovou vrstvu nebo celou infrastrukturu aplikace.
Low-code ale neznamená, že se aplikace nemůže rozbít.
Chyba může vzniknout v Power Fx logice, cloud flow, bezpečnostní roli, konfiguraci Dataverse, integraci nebo ve vlastním vývoji. Problém může přinést i zdánlivě nevinná změna formuláře nebo datového modelu, která ovlivní jinou část procesu.
U menších interních aplikací bývá testování často poměrně neformální. Změnu ověří autor aplikace, několik klíčových uživatelů a skutečný problém se někdy projeví až v produkčním provozu. To nemusí být automaticky špatně. Rozsah testování by měl odpovídat kritičnosti aplikace a riziku, které její selhání představuje.
Ani chyba v interní aplikaci ale nemusí mít zanedbatelný dopad. Může zablokovat vytvoření objednávky, schválení smlouvy nebo zpracování požadavku, jehož výsledek se nakonec dotkne také zákazníka. Vedle technického dopadu proto musíme zvažovat náklady na výpadek, počet ovlivněných uživatelů, možnost náhradního postupu i reputační riziko.
Platí ještě testovací pyramida?
Když přemýšlíme o testovací strategii, přirozeně se dostáváme k testovací pyramidě. Její základ tvoří velké množství malých a rychlých testů. Nad nimi se nacházejí integrační testy a na vrcholu menší počet testů, které ověřují aplikaci jako celek, často prostřednictvím uživatelského rozhraní.
U E2E testů jsme vždy museli porovnávat jejich přínos s cenou vytvoření a dlouhodobé údržby. Dokážou velmi dobře ověřit skutečný uživatelský scénář, ale současně patří mezi nejdražší testy. Potřebují funkční prostředí, správně připravená data, testovací identity a dostupné integrace. Jejich spuštění trvá déle a při selhání nemusí být na první pohled jasné, zda je problém v aplikaci, testu, datech nebo prostředí.
S příchodem AI je proto namístě položit si otázku, zda se toto paradigma nezměnilo.
Po bližším pohledu bych ale neřekl, že AI testovací pyramidu obrací. Jednotkové a integrační testy budou nadále rychlejší, přesnější a lépe izolují příčinu problému. AI však může změnit ekonomiku nejvyšší vrstvy pyramidy.
Může pomoci prozkoumat aplikaci, připravit první verzi testu, najít vhodné ovládací prvky a analyzovat selhání. Část práce, kvůli které byly E2E testy dlouhodobě drahé, tak může být rychlejší a dostupnější. To neznamená, že bychom měli začít všechno testovat přes uživatelské rozhraní. Některé důležité scénáře, jejichž automatizace nám dříve ekonomicky nedávala smysl, ale stojí za nové posouzení.
Hlavní myšlenku článku lze proto shrnout jednoduše:
Od teorie k Power Platform Playwright Samples
Praktický základ nám nabízí otevřený repozitář Power Platform Playwright Samples přímo od Microsoftu. Obsahuje Playwright toolkit a ukázkové testy pro model-driven aplikace, Canvas Apps, custom pages a nové Gen UX rozhraní. Vedle podpory přihlašování, vyhledávání prvků a čekání na načtení aplikace nabízí také připravené AI postupy pro vytvoření testu, ověření konfigurace a diagnostiku selhání; pomocí Playwright MCP přitom může AI pracovat se skutečnou aplikací v prohlížeči.
Nejzajímavější totiž není pouze to, že AI dokáže vygenerovat několik řádků testovacího kódu. Podstatná změna přichází ve chvíli, kdy může pracovat se skutečnou aplikací, ověřovat své předpoklady a využívat výsledky spuštěného testu jako zpětnou vazbu.
Co v tomto spojení skutečně přináší AI
Abychom pochopili přínos celého řešení, je dobré nejprve oddělit několik pojmů, které se dnes často objevují vedle sebe. LLM, skill, MCP a Playwright nejsou čtyři názvy pro stejnou technologii. Každá část má v procesu jinou úlohu.
Pro business uživatele bych si celé spojení dovolil přirovnat k novému kolegovi, který má připravit testovací scénář.
Pojem skill zde používám obecně pro sadu instrukcí, které AI naučí pracovat v konkrétním projektu. Podle použitého nástroje se můžeme setkat také s názvy jako custom instructions nebo agent definition. Princip je ale stejný: nemusíme AI při každém zadání znovu vysvětlovat, že Canvas App běží uvnitř určitého rámce, že se má používat Power Platform toolkit nebo že testovací data musí být při každém spuštění jedinečná.
Skill z AI neudělá odborníka tím, že by ji naučil úplně všechno o naší aplikaci. Poskytne jí ale podobný základ, jaký bychom předali novému členovi týmu: kde se testy nacházejí, jaké konvence používáme, jak se aplikace spouští a jakým způsobem se má ověřovat výsledek.
Od business scénáře k prvnímu testu
Vytvoření testu může začít zadáním, kterému rozumí i člověk bez znalosti TypeScriptu nebo Playwrightu:
AI si nejprve pomocí skillu načte pravidla projektu. Následně prostřednictvím MCP otevře aplikaci v prohlížeči a vyzkouší jednotlivé kroky. Najde potřebnou galerii, formulářová pole a tlačítko pro uložení. Z ověřeného průchodu potom vytvoří Playwright test a spustí jej.
Pokud první verze neprojde, AI získá konkrétní zpětnou vazbu. Může zjistit, že použila nesprávný název prvku, nepočkala na načtení Dataverse nebo že po uložení musí přejít na jinou obrazovku. Test upraví a znovu spustí.
Člověk přitom stále rozhoduje o tom nejdůležitějším: zda scénář odpovídá skutečnému business procesu a zda test ověřuje správný výsledek. AI může najít tlačítko „Uložit“, ale sama neví, zda má být po jeho stisknutí objednávka ve stavu Rozpracováno, Schváleno nebo Odesláno zákazníkovi.
AI nemusí být součástí každého spuštění
Z pohledu nákladů a předvídatelnosti je důležitý ještě jeden rozdíl. AI může pomoci test vytvořit, ale hotový test se následně uloží jako běžný TypeScript kód.
Při každém dalším spuštění proto nemusí LLM znovu procházet aplikaci a rozhodovat, na co klikne. Playwright pouze opakuje jednou připravený scénář a kontroluje předem definované očekávání. Test tak může běžet automaticky při nasazení nové verze, během noční regrese nebo jako součást CI/CD pipeline.
AI se znovu zapojí především ve chvíli, kdy chceme vytvořit další scénář nebo když existující test přestane fungovat. Díky tomu kombinujeme flexibilitu AI při tvorbě s opakovatelností klasické automatizace při běžném provozu.
AI jako pomocník při údržbě testů
Právě údržba bývá u E2E testů dlouhodobě nejdražší. Aplikace se změní, test selže a někdo musí zjistit, zda našel skutečnou regresi, nebo jen zastaralý locator či příliš krátké čekání.
Playwright při selhání dokáže vytvořit trace obsahující jednotlivé kroky, stav stránky, screenshoty, síťovou komunikaci a chybové zprávy. AI může tyto informace projít společně s původním testem a aktuální podobou aplikace. Následně může navrhnout například změnu locatoru, delší čekání na data nebo opravu přípravy testovacích údajů.
I zde ale musí existovat hranice. Pokud se změnil pouze technický způsob, jak najít stejné tlačítko, může AI připravit bezpečný návrh opravy. Pokud se změnil očekávaný výsledek business procesu, neměla by sama upravit kontrolu jen proto, aby test znovu prošel. Taková změna vyžaduje rozhodnutí člověka.
Přínos AI proto nespočívá v tom, že každý selhávající test automaticky „opraví“. Dokáže ale výrazně zkrátit cestu od selhání k pochopení jeho pravděpodobné příčiny a připravit návrh řešení, který člověk zkontroluje.
Co si z toho odnést
Testovací pyramida s příchodem AI nezmizela. Jednotkové a integrační testy zůstávají nenahraditelné tam, kde potřebujeme rychlou zpětnou vazbu a přesné určení příčiny chyby. AI ale snižuje část nákladů spojených s vytvářením a údržbou E2E testů, a tím může rozšířit okruh scénářů, které se vyplatí automatizovat.
AI přitom není zdrojem pravdy. Může nám pomoci aplikaci prozkoumat, test vytvořit, spustit a diagnostikovat jeho selhání. O tom, který business scénář je důležitý a jak má správně skončit, ale stále musí rozhodnout člověk.
Pro týmy využívající Power Platform tak podle mě vzniká praktická otázka: které kritické business scénáře dnes netestujeme automaticky jen proto, že vytvoření a údržba E2E testu byly příliš drahé?
