Testy píše AI. Ne každé zelené fajfce se dá věřit.

Rychlost, kterou QA nestíhá

Vývoj zrychlil. AI pomáhá psát kód, release cykly se zkracují a změn přibývá. Klasické QA s ručně psanými testy a manuální regresí v tomhle tempu dopadne jedním ze dvou špatných způsobů.

• Stane se úzkým hrdlem a vývoj čeká na testování.
• Odbude se. Rychlost vyhraje nad jistotou a kvalita tiše klesá.

Nabízí se nechat psát testy taky AI. Tady ale začíná skutečný problém. Vygenerovaný test, který projde naoko, protože má prázdnou aserci nebo kontroluje špatnou věc, je horší než žádný test. Tváří se jako jistota a není.

‍

Položili jsme si proto jinou otázku. Jak prokázat, že funkce opravdu funguje? A jak poznat, že změna v jedné části nerozbila jinou, o které nikdo neví?

První generace nechala všechno na AI

V lednu jsem psal, kam chceme QA s pomocí AI a agentů posunout. Když jsme to začali stavět, byla naše první verze přímočará. Agenti četli zadání, sami procházeli aplikaci v prohlížeči, psali testy a hledali na stránce prvky, na které má test klikat. Výsledky nás rychle vystřízlivily.

• 63 % selhání byly špatně odhadnuté lokátory. Model hádal, kde na stránce co je.
• Úspěšnost u stejné funkce skákala mezi verzemi z 71 % na 76 % a pak na 7 %.
• Jeden běh stál 31 až 73 dolarů a trval kolem hodiny a půl.

Ta skákající čísla mě naučila to nejdůležitější. Pass rate je špatná metrika. Když se stejná funkce jednou „otestuje“ na 76 % a podruhé na 7 %, vypovídá to jen o generátoru testů. O aplikaci se z toho nedozvíte nic.

‍

Druhou generaci jsme proto postavili obráceně. AI rozhoduje tam, kde je potřeba úsudek, tedy u rizik, scénářů a psaní testů. Prohlížeč ovládá deterministický kód. Prvky na stránce změří, takže je model nemusí hádat. A o tom, co se bude testovat, rozhoduje člověk.

Jak funguje QA Control Center

Systém začíná tam, kde začíná každý tester, u aplikace a u zadání. Nejdřív si sám zmapuje web. Projde stránky, rozpozná šablony a funkce a sestaví z nich mapu toho, co se dá testovat. U konkrétní funkce pak tester klikne na „Zpracovat“.

Ze zadání a z JIRA systém navrhne rizika a akceptační kritéria, tedy ověřitelné podmínky nutné pro to, aby funkce fungovala. U každého rizika tester rozhodne, jestli se bude testovat, je mimo rozsah, nebo ho vědomě akceptuje. Z kritérií vzniknou scénáře psané jazykem testera. Prvky na stránce, na které bude test klikat, změří kód a tester je podepíše. Teprve potom vzniknou spustitelné Playwright testy. Projdou statickou kontrolou kvality a poběží proti živé aplikaci.

‍

Každý scénář skončí v jednom ze čtyř stavů.

• PASS. Důvěryhodný test prošel a chování je prokázané.
• FAIL. Důvěryhodný test opakovaně selhal a potvrdil chybu v aplikaci. Pro QA je to úspěch, test našel bug.
• MANUAL. Scénář se vědomě neautomatizuje.
• BLOCKED. Technická blokace s konkrétním důvodem.

Tester mezi jednotlivými kroky nemusí sedět u počítače. Na schvalovacím kroku může systém klidně týden čekat a pak pokračuje tam, kde skončil.

Hlavní metrikou je důvěra

Hlavní metrika QA Control Center je podíl scénářů, které skončily v důvěryhodném stavu. Patří mezi ně i FAIL, pokud odhalil skutečnou chybu. Podíl zelených testů mě zajímá málo. Zajímá mě, jestli test říká o aplikaci pravdu.

‍

Co to znamená v praxi? Zpřísnili jsme pravidlo: zelený test, který tvrdí nějakou změnu nebo hodnotu, ale nemá jedinou kontrolu hodnoty, už nepočítáme jako PASS. U jedné z našich testovaných funkcí by tak ze 14 zelených testů vypadlo 5, tedy 36 %.

‍

Pro mě je to přesně ten druh čísla, kvůli kterému systém stavíme. Raději vím, že víc než třetina zelené by byla jen barva, než abych se na ni spoléhal.

‍

Důvěru proto měříme ve dvou osách.

• Věrnost (fidelity). Testuje test opravdu to, co říká scénář? Tohle systém garantuje.
• Pokrytí (coverage). Pokrývají scénáře všechno, na čem u funkce záleží? Systém to měří proti akceptačním kritériím. Jestli je sada kritérií úplná, ale rozhoduje člověk.

Úvodní číslo aplikace je pak pokrytí × důvěra. Plyne z toho jedno poučení. 100 % PASS neznamená funkci bez chyby. Znamená, že všechny napsané scénáře jsou věrně otestované.

Kdy ověření přestává platit

Ověření neplatí navždy. Funkce, která v pondělí prošla, může být ve středu po nasazení změny rozbitá. Pondělní zelená fajfka by pak dál potvrzovala něco, co už neplatí. QA Control Center proto u každé funkce ukazuje, čím je ověřená a od kdy ověření přestalo platit. Rozhodují tři situace.

• Změnil se zdrojový kód funkce. Důkaz z minula už neplatí. Váha funkce v úvodním čísle klesne na nulu, dokud ji nový běh znovu nepřeměří.
• Změnilo se schválené zadání nebo plán. Systém si vyžádá nový podpis testera. Podpis platí jen pro to, co tester opravdu viděl.
• Zpřísnila se pravidla. Funkce ověřená podle starší laťky si důkaz ponechá, protože ho nikdo nevyvrátil. Nese ale výhradu a v úvodním čísle se počítá poloviční vahou.

To poslední je můj vědomý kompromis. Kdybych výhrady v čísle ignoroval, vypadala by funkce lépe, než odpovídá novým pravidlům. Kdybych je počítal jako neověřené, popřel bych důkaz, který existuje. Poloviční váha je řešení, za kterým si dokážu stát před vývojem i před klientem.

Na čem stavíme a kde hledáme první projekty

QA Control Center jsme vyladili na vlastních funkcích a teď ho chceme nasadit na prvních klientských projektech.

• O úplnosti rozhoduje tester. Systém ověří, že test věrně testuje scénář. Jestli scénáře pokrývají všechno důležité, posoudí člověk, a výsledky to tak i označují.
• Nejlépe funguje na webech s testovacími atributy. Kde aplikace nemá stabilní identifikátory prvků, systém víc měří a tester víc podepisuje. Funguje to i tam, jen to stojí víc času.
• Každý projekt přináší nové situace. Jiné weby a jiní testeři narážejí na případy, které jsme na vlastních funkcích nepotkali. Systém je pak hlídá sám.

Pod kapotou

• 16 specializovaných AI agentů, od směrovacího přes analytika rizik a autora scénářů až po autora a recenzenta testů. Žádný z nich neovládá prohlížeč. Agenti jen čtou a píšou podklady.
• Tři úrovně modelů. Levný model na směrování a rešerši, střední na rozhodování a nejsilnější na rizika, scénáře a psaní testů. Výměna modelu je jeden řádek v konfiguraci.
• Deterministický runner. Řídí běh, hlídá schvalovací kroky, ukládá výsledky a po přerušení naběhne tam, kde skončil.
• Playwright pro testy a měření prvků na stránce, napojení na JIRA a Figmu a webová „tabule“ pro testery.
• Přes 4 000 automatických testů samotného systému. Nástroj na měření důvěry musí být sám důvěryhodný.
• Etnetera Agentic. QA Control Center stavíme na Etnetera Agentic, naší platformě pro agentní systémy.

Zelená je jen barva

AI dokáže práci v testování obrovsky zrychlit. Pokud ale budeme měřit jen počet zelených testů, budeme rychleji vyrábět falešný pocit jistoty. QA Control Center proto stavíme na jednoduchém rozdělení rolí. AI navrhuje, tester rozhoduje a kód měří. U každé funkce je poctivě zapsané, čím je ověřená a od kdy už ne.

‍

Tohle je první díl série. V dalším se podíváme hlouběji pod kapotu, jak přidělujeme modely šestnácti agentům a proč žádný z nich nesmí do prohlížeče.

‍

Chcete vědět, kolika testům na vašem projektu se dá opravdu věřit? Napište nám a probereme to.

‍

‍