Jak vývojový tým použije AI pro návrh testovacích scénářů

AI rozšiřuje pokrytí testů, tým rozhoduje o hodnotě

Otázka, jak může vývojový tým použít AI pro návrh testovacích scénářů, se dobře zodpoví jedním pravidlem: AI nedostává úkol vymyslet testy od nuly, dostává specifikaci a existující sadu testů a úkol najít, co ta sada nepokrývá. Výstup je vždy širší seznam kandidátů na testovací případy, ne hotová sada, kterou lze rovnou zařadit do ostrého pokrytí bez kontroly.

Rozdíl mezi „navrhni testy“ a „najdi mezery v pokrytí“ určuje, jestli výstup vůbec dává smysl zkoumat. Model bez specifikace a bez znalosti existujících testů opakuje to, co je zjevné, a přehlíží hraniční případy, na které se ptá jen někdo, kdo zná systém zevnitř. Model se specifikací a existující sadou dokáže cíleně hledat, co v pokrytí chybí, i když finální rozhodnutí, jestli je nalezený případ důležitý, zůstává na týmu.

Jak zadat úlohu, aby výstup měl cenu

1. Dejte AI specifikaci chování, ne jen název funkce nebo krátký popis úkolu. Čím přesnější je popis očekávaného chování včetně hraničních podmínek, tím lépe dokáže model najít mezeru mezi tím, co je specifikováno, a tím, co je otestováno.
2. Přiložte existující testovací sadu jako referenci, ne jako vzor ke kopírování. Cílem je najít, co sada nepokrývá, ne přepsat testy, které už fungují.
3. Požádejte výslovně o hraniční hodnoty, chybové stavy a kombinace vstupů, které existující sada neřeší. Obecné zadání typu „navrhni testy“ obvykle vrátí případy, které tým už zná a otestoval, protože jsou nejsnáze odvoditelné ze specifikace.
4. Očekávejte, že většina navržených případů bude málo hodnotná, protože duplikuje existující pokrytí, a některé budou o skutečném chování systému vyloženě mylné. Toto očekávání není důvod úlohu nezadávat, je to důvod nikdy výstup nespouštět bez kontroly.

Nejčastější past: test potvrzuje chování kódu, ne požadavek specifikace

Nejzáludnější je testovací případ, který AI navrhne a který i po spuštění projde, ale ne proto, že ověřuje správné chování podle specifikace. Projde proto, že jen zaznamenává chování, které kód aktuálně má, včetně chování, které je ve skutečnosti chybou. Model nemá jinou možnost, jak zjistit „správnou“ odpověď, než buď specifikaci, nebo aktuální výstup systému, a pokud dostane k dispozici i aktuální výstup, má tendenci se o něj opřít, protože vypadá jako jistota.

Tento typ testu je nebezpečnější než test, který zjevně selže. Selhávající test tým zkontroluje, protože ho na sebe upozorní. Test, který tiše potvrzuje chybu jako správné chování, projde do zelené sady testů a od té chvíle brání opravě téže chyby, protože jakákoli budoucí oprava tento test rozbije a bude vypadat jako regrese.

Obrana proti této pasti je jednoduchá, ale musí se dodržovat důsledně: každý navržený test se ověřuje proti specifikaci, ne proti aktuálnímu chování systému. Pokud test ověřuje chování, které specifikace nezmiňuje nebo popisuje jinak, jde o signál, že buď test, nebo aktuální chování kódu neodpovídá tomu, co má systém dělat, a tuto nesrovnalost je potřeba vyřešit dřív, než se test zařadí do sady.

Tabulka: jak roztřídit navržené testovací případy

Po vygenerování kandidátů na testy nikdy nepřidávejte celou dávku do sady najednou. Roztřiďte každý případ podle toho, co s ním má tým udělat.

Poslední kategorie je z hlediska hodnoty nejdůležitější, přestože se do ní typicky zařadí jen malá část výstupu. Právě tyto případy odhalují místa, kde specifikace mlčí nebo kde se realita kódu od specifikace tiše odchýlila.

Co do zadání nepatří: produkční data jako testovací vstup

Aby AI navrhla realistické testovací vstupy, je lákavé vložit do zadání skutečná produkční data, protože nejlépe ukazují, jak vstupy v praxi vypadají. Tento krok má ale vlastní riziko nezávislé na kvalitě generovaných testů: produkční data mohou obsahovat osobní nebo jinak citlivá data, a jejich vložení do AI nástroje je zpracování dat, které je potřeba posoudit zvlášť, ne mimochodem jako součást přípravy testů.

Bezpečnou náhradou jsou syntetická data navržená tak, aby pokrývala stejné hraniční případy a stejné typy vstupů jako produkční data, ale bez vazby na skutečné osoby nebo skutečné záznamy. Pokud si nejste jistí, zda konkrétní sada dat, kterou chcete použít, je bezpečná k vložení do AI nástroje, otázku předejte pověřenci pro ochranu osobních údajů ve vaší firmě dřív, než data někam vložíte.

Pro širší kontext k vkládání firemních dat do AI nástrojů viz je bezpečné vkládat firemní data do ChatGPT a k otázce zpracování osobních údajů obecně gdpr a umělá inteligence. Riziko, že model potvrdí chybu jako správné chování, souvisí s obecnějším jevem popsaným v proč si AI vymyslí halucinace. Širší rámec zavádění podobných postupů do vývojového týmu nabízí zavedení AI ve firmě.

Stav zdrojů a omezení

Rámec NIST pro řízení rizik AI zařazuje hodnocení výstupu systému, tedy funkci Measure, jako samostatný krok oddělený od jeho návrhu, a přesně to dělá čtyřkolonková tabulka výše pro navržené testovací případy. Nařízení GDPR, konkrétně zásady podle článku 5 a požadavky na zabezpečení zpracování podle článku 32, je důvodem, proč článek doporučuje syntetická data místo produkčních, ne konkrétní návod, co přesně smíte nebo nesmíte do AI nástroje vložit. Toto rozhodnutí musí posoudit pověřenec pro ochranu osobních údajů nebo jiná odpovědná osoba ve vaší firmě podle povahy konkrétních dat. Článek neuvádí žádná čísla o pokrytí testů ani o míře odhalených chyb a nedoporučuje žádný konkrétní nástroj ani testovací rámec.