Jak AI pomáhá třídit stovky selhání testů bez skrytí chyby

Po velkém releasu může najednou selhat sto testů, přestože příčiny jsou jen tři: nedostupné testovací prostředí, změna jednoho společného prvku a skutečná chyba v aplikaci. Jazykový model dokáže pomoci podobné výstupy seskupit a připravit hypotézy. Nesmí však bez důkazů rozhodnout, že test je flaky, ani automaticky přepsat test tak, aby výsledek znovu svítil zeleně.

Proč počet červených testů klame

Jedna chyba může spustit řetězec selhání. Když nefunguje přihlášení, selžou scénáře objednávky, profilu i administrace. Naopak dvě selhání se stejnou hláškou Timeout nemusí mít stejnou příčinu: jeden test čekal na pomalé API, druhý hledal prvek, který už na stránce není.

Ruční otevírání každého reportu je pomalé a podporuje zkratky. Tým může opakovaně spustit celý běh, hromadně označit testy za nestabilní nebo zvýšit časový limit. Tím se však příčina pouze odloží. Užitečnější je kontrolovaný tok collect → redact → cluster → hypothesis → human verification: shromáždit podklady, odstranit citlivé údaje, vytvořit skupiny, formulovat hypotézy a nechat člověka ověřit je proti důkazům.

Realistický příklad: 126 selhání po jedné změně

Po nasazení úpravy checkoutu selže noční běh se 126 červenými testy. Jednoduché řazení podle poslední chybové hlášky vytvoří velkou skupinu Timeout, která však míchá několik problémů. Po normalizaci artefaktů AI nejprve navrhne dvě široké skupiny a třináct případů ponechá jako neurčené. Lidská kontrola následně výsledek rozdělí na tři potvrzené skupiny.

První skupina obsahuje 83 scénářů, které se zastavily při přihlášení. Mají stejnou odpověď autentizační služby a začaly selhávat ve stejnou dobu, proto člověk ověří dostupnost služby a jeden reprezentativní test. Druhou skupinu tvoří 21 testů s chybějícími daty po neúspěšném přípravném jobu. Oprava prostředí odstraní obě skupiny bez změny testů.

Třetí skupina má devět checkout scénářů. AI je nejprve přiřadí k obecným timeoutům, ale u každého je síťová odpověď úspěšná a detail trace ukazuje nesprávný součet objednávky. Člověk při kontrole je oddělí jako možnou chybu aplikace. Reprodukce s konkrétními položkami potvrdí chybnou slevu. Kdyby se skupina automaticky označila jako problém prostředí a testy se pouze zopakovaly, skutečná regrese by zůstala skrytá.

Zbývajících třináct selhání nemá dostatek společných důkazů. Zůstanou v kategorii „neurčené“ a dostanou samostatnou kontrolu. Tento výsledek je užitečnější než vynucených 100 % zařazených případů: tým vyřeší dvě hromadné příčiny a přitom neztratí menší skupinu s obchodním dopadem.

1. Collect: shromážděte porovnatelné podklady

Pro každý neúspěšný test uložte alespoň jeho stabilní ID, název buildu a commitu, čas, prostředí, prohlížeč nebo zařízení, chybovou hlášku, stack trace a poslední relevantní kroky. Podle nástroje doplňte síťové a aplikační logy, snímek nebo trace. Playwright Trace Viewer například umožňuje procházet časovou osu kroků, DOM snapshoty, konzoli a síťové požadavky.

Zachovejte také historii výsledků. Jediné selhání neukazuje, zda jde o opakovatelnou regresi, náhodnou nestabilitu, nebo jednorázový výpadek prostředí. Praktické měření rozebíráme v článku Jak měřit flaky testy a odhalit nestabilní scénáře.

Podklady musí mít stejnou strukturu. Pokud jeden test poskytne celý trace a druhý pouze větu „element not found“, model bude skupiny vytvářet také podle rozdílné kvality vstupu, nejen podle příčiny.

2. Redact: odstraňte citlivé údaje ještě před AI

Logy a trace mohou obsahovat přístupové tokeny, cookies, osobní údaje, obsah formulářů, hlavičky požadavků nebo celé odpovědi API. Maskování proto patří před odeslání do modelu, ne až do následné kontroly jeho odpovědi.

Automatická pravidla mohou nahradit tokeny, e-mailové adresy nebo identifikátory konzistentními zástupnými hodnotami. Konzistentnost je důležitá: hodnota <USER_17> v různých souborech stále umožní spojit události jednoho testovacího účtu bez odhalení původní hodnoty. Pravidla je potřeba ověřit na reálných artefaktech, protože tajemství se může objevit také v URL, snímku obrazovky nebo příloze. Výběr modelu, místo zpracování a pravidla uchovávání dat závisí na konkrétním řešení; širší kontext popisuje článek Kam odcházejí vaše data při AI asistovaném testování.

3. Cluster: seskupujte podle více signálů

Nejprve vytvořte deterministický základ: normalizujte stack trace, odstraňte proměnlivé časy a ID a vypočítejte podpis z typu chyby, místa v kódu a posledního kroku. AI potom může doplnit sémantickou podobnost textů, logů a viditelných příznaků.

Výstupem nemá být pouze název skupiny. U každého clusteru potřebujete:

seznam zahrnutých testů a běhů,
společné signály, které spojení podporují,
rozdíly a protidůkazy,
reprezentativní příklad,
míru nejistoty a položky, které se nepodařilo zařadit.

Nutnost zařadit každé selhání do některé skupiny je nebezpečná. Kategorie „neznámé“ je lepší než přesvědčivé, ale nepodložené spojení skutečné chyby s poruchou prostředí.

Výstup musí být kontrolovatelný, ne jen přesvědčivý

Každá skupina potřebuje stabilní identifikátor a stručný název, ale také údaje, ze kterých lze rozhodnutí zpětně posoudit. Výstup může u clusteru uvést dominantní podpis chyby, dotčené testy a buildy, první a poslední výskyt, společné artefakty, výjimky a navrhovaný další diagnostický krok. Odkaz na původní trace je hodnotnější než dlouhé shrnutí bez zdroje.

Oddělte tři různé hodnoty: podobnost, hypotézu příčiny a prioritu. Dva testy mohou být velmi podobné, ale příčina ještě nemusí být známá. Naopak jediné selhání platebního scénáře může mít vyšší prioritu než padesát testů interního reportu. Model může navrhnout všechny tři hodnoty, ale nesmějí se sloučit do jednoho neurčitého skóre „důvěry“.

Uložte také verzi pravidel normalizace, promptu a použité konfigurace modelu. Nejde o reprodukci každého slova odpovědi, ale o možnost vysvětlit, proč se výsledky mezi dvěma běhy změnily. Pokud nová verze začne spojovat širší skupiny, tým má podklad pro porovnání místo dojmu, že AI je tentokrát sebevědomější.

4. Hypothesis: formulujte vysvětlení, ne verdikt

Pro skupinu může model navrhnout například hypotézu: „Testy selhaly po změně společného selektoru přihlašovacího tlačítka.“ Musí k ní připojit důkazy, například stejný commit, DOM snapshot bez původního prvku a konzistentní místo selhání. Má uvést také alternativy: neúplně načtená stránka může vypadat stejně.

Hypotéza nesmí přímo měnit repozitář, zvyšovat timeout, vypnout test ani založit produkční incident bez dohodnutého schválení. Zvláštní opatrnost vyžaduje označení flaky. To potřebuje historii opakovaných běhů za porovnatelných podmínek, ne jen podobnost s minulou nestabilitou.

5. Human verification: člověk ověří příčinu a dopad

Tester nebo vývojář vybere reprezentativní selhání z každého clusteru a projde původní artefakty. Ověří změnu aplikace, reprodukuje scénář nebo jej spustí za kontrolovaných podmínek a porovná chování s hypotézou. U velké skupiny prověří také několik okrajových členů, aby se pod jedním názvem neskrývaly dvě příčiny.

Teprve potom tým přiřadí stav: chyba aplikace, chyba testu, problém dat, prostředí, nebo zatím neurčeno. Opravu provede ve správné vrstvě a následným během potvrdí, že odstranila příčinu bez oslabení ověření. Pokud jde o šířeji poškozenou nebo nedůvěryhodnou sadu, výsledky triage jsou vstupem pro opravu stávající testovací sady, ne její automatickou náhradou.

Rozhodovací hranice, které AI nesmí obejít

Před zavedením určete operace, které zůstávají pod lidským schválením. AI může doporučit další běh, karanténu nebo úpravu selektoru, ale sama nemá vypnout test, změnit očekávaný výsledek, prodloužit timeout ani uzavřít hlášení chyby. Stejně tak nemá zapisovat do produkčních systémů nebo přiřazovat incident bez pravidel, která tým zvlášť schválil.

Označení flaky vyžaduje pozorování střídavého úspěchu a selhání za srovnatelných podmínek a prozkoumání možných rozdílů v datech či prostředí. Ani vysoká podobnost s historickým flaky testem není důkaz. Dočasná karanténa může chránit pipeline před šumem, ale potřebuje vlastníka, důvod, datum další kontroly a zachovaná selhání; jinak se z ní stane trvalé skrytí rizika.

Při nízké kvalitě artefaktů má systém požádat o další podklad nebo ponechat případ neurčený. Bez stack trace, historie a informace o prostředí je bezpečnější říct „nevíme“ než vymyslet konkrétní příčinu z názvu testu.

Jak ověřit, že triage skutečně pomáhá

Před pravidelným použitím připravte menší referenční sadu historických běhů, u kterých lidé znají potvrzenou příčinu. Skryjte tato označení před AI, nechte ji vytvořit skupiny a potom výsledek porovnejte. Sledujte především chybná sloučení odlišných příčin, protože ta mohou skutečný problém skrýt. Příliš mnoho malých skupin spíše snižuje úsporu času, ale bývá snazší je odhalit.

V provozu měřte podíl skupin potvrzených člověkem, počet rozdělených nebo sloučených skupin po kontrole, podíl neurčených případů a čas do nalezení první potvrzené příčiny. Samotný počet automaticky zpracovaných selhání nic nevypovídá o správnosti. Výsledky porovnejte s původním ručním postupem a po větší změně sady, reportéru nebo modelu kontrolu zopakujte.

Užitečný systém postupně snižuje opakovanou práci bez růstu chybných sloučení. Pokud sice vytváří rychlá shrnutí, ale člověk při kontrole musí otevřít každý artefakt od začátku nebo pravidelně nachází skryté odlišné příčiny, je potřeba upravit vstupy, pravidla skupin nebo rozsah AI, ne pouze přeformulovat prompt.

Tento důraz na evidenci, vyhodnocení a lidskou validaci odpovídá obecnému přístupu k řízení rizik generativní AI, který popisuje NIST AI RMF Generative AI Profile. NIST však neurčuje tento konkrétní pětikrokový workflow; ten je praktickým návrhem pro třídění testů.

Co tím získáte

Namísto stovky izolovaných hlášení dostane tým menší počet pracovních skupin s dohledatelnými důkazy. Rychleji najde společnou příčinu, ale zachová viditelnost nejasných a odlišných selhání. Člověk stále rozhoduje o chybě i opravě, takže úspora času nevzniká na úkor důvěryhodnosti sady.

Další krok

Na jednom neúspěšném běhu zaveďte jednotný formát artefaktů a pravidla maskování. Nechte AI pouze navrhnout skupiny a hypotézy, poté ručně ověřte reprezentanta i okrajový případ každé skupiny. Teprve když tento proces opakovaně rozlišuje příčiny bez skrývání chyb, zapojte jej do pravidelného vyhodnocování běhů.