Každá úroveň testování má v rámci vývoje softwaru svou roli a odpovídá na jinou otázku:
Unit testy - „Změnila se funkce, která měla zůstat beze změny?“ Testují nejmenší izolované části kódu (jednotlivé funkce nebo metody) nezávisle na zbytku systému. (Podrobný rozbor unit testů najdete v samostatném článku na blogu.)
Integrační testy - „Fungují komponenty po změně stále správně společně?“ Testují skutečné propojení modulů (například databáze + servisní vrstva + API), nikoli jen izolované funkce. Odhalí situace, kdy jednotlivé části samostatně projdou, ale po spojení selžou.
E2E (End-to-End) testy - „Funguje systém tak, jak ho zažije skutečný uživatel?“ Simulují kompletní uživatelské scénáře (přihlášení → akce → výsledek) přes skutečné UI nebo API. Zachytí regrese, které unit ani integrační testy odhalit nedokážou, protože se projeví teprve v reálném průchodu aplikací.
(Existují samozřejmě i další typy testování, například *Smoke testy**, zátěžové nebo bezpečnostní testování, které jsou mimo rozsah tohoto článku.)*
Všechny úrovně automatizovaného testování mají společný cíl: ověřit, že se nerozbila funkcionalita mimo rozsah právě řešeného úkolu. Úkol může být podle zadání splněn dokonale, a přesto může jako nezamýšlený vedlejší efekt rozbít něco jiného. Bez testovací vrstvy, která sahá za hranice konkrétní změny, si toho nikdo nevšimne, dokud problém v produkci nenahlásí uživatel.
Nezastupitelná role ručního testování
Navzdory pokročilé automatizaci a nasazení AI si ruční testování udržuje nezastupitelnou a primární roli. Lidský tester přináší skutečný úsudek, intuici a schopnost zachytit jemné nuance či nečekané chování UI, které automatizované skripty snadno přehlédnou. Ruční ověření bylo, je a vždy bude to, co dává vývojovému týmu 100% jistotu, že je aplikace připravená pro skutečné uživatele.
Vývoj s AI a kompenzace „slepoty“
V éře vývoje s pomocí AI je automatizovaná testovací vrstva ještě důležitější. AI agent nevnímá celý systém najednou, a proto jsou vedlejší efekty pravděpodobnější než u vývojáře, který nese celý kontext a historii dřívějších rozhodnutí. Testy slouží jako mechanismus, který tuto slepotu vůči systému systematicky vyrovnává dříve, než kód dorazí ke konečnému schválení člověkem.
Praktický dopad: výzvy E2E testování s AI
Vytváření E2E testů je pro AI obzvlášť složité. Nejde jen o napsání samotného testovacího skriptu, ale především o přípravu vhodných testovacích dat, aby je software mohl použít (často jen pro malou část testu). Příprava těchto dat je velmi náročná.
Představte si zdánlivě jednoduchou akci: kliknout na rozbalovací seznam a vybrat parametr (například typ dokumentu Faktura). Pokud test selže nebo se nedokončí, je zásadní zjistit přesnou příčinu. Mohlo nastat hned několik situací:
- AI se ztratila a nenašla prvek rozbalovacího seznamu v UI (přestože tam je).
- Test narazil na dřívější chybu na cestě a nedokázal se zotavit.
- Rozbalovací seznam existuje, ale neobsahuje očekávaná data k výběru.
- AI sáhla po JavaScriptu (neviditelném obejití) a hodnotu úspěšně nastavila programově, zatímco pro skutečného uživatele zůstala neviditelná.
Kolem jediného rozbalovacího seznamu může vzniknout řada problémů. Klíčové je, zda AI (nebo vyhodnocující systém) dokáže odlišit skutečnou chybu od kaskádového selhání způsobeného něčím jiným. Samotné úspěšné uložení dat nezaručuje, že vše funguje správně.
Behaviorální přístup a pokrytí testy
Proto by se testy měly vždy zaměřovat na behaviorální stránku systému a testovat to, co skutečně očekáváme:
Happy Path (~90 % případů): Hlavní pozornost patří tomu, co uživatelé budou dělat naprostou většinu času.
Kritické okrajové případy: Hraniční situace, které nenastávají často, ale jsou životně důležité pro integritu systému.
Další méně pravděpodobné kombinace se předem netestují. Pokud nastanou v produkci, opraví se za chodu nebo se jim předejde softwarovými omezeními a validacemi (například zablokováním navigace, dokud nejsou vstupy platné).
E2E testování v AITM
V AITM je E2E testování výslovnou a povinnou fází pipeline u úkolů, které se dotýkají UI (určeno typem/záměrem úkolu). Není to volitelný doplněk, který lze při blížícím se termínu vynechat - pipeline bez něj nelze označit za dokončenou.
Pokud E2E test chybí nebo prostředí není dostupné, build ve výchozím stavu selže (s vzácnými výjimkami, kdy je neúspěšnému E2E povoleno pokračovat). Každé spuštění E2E navíc pořizuje snímky obrazovky, které jsou vidět ve výsledcích úkolu.
Jak E2E funguje nyní:
- Před spuštěním testů je zaručeno, že build je úspěšný a běží ve vlastním izolovaném worktree.
- Stav databáze se připraví se speciálními testovacími daty vedle výchozích záznamů.
- Testování se zaměřuje výhradně na Happy Path (nepokrývá všechny možné scénáře).
Plánovaný vývoj E2E:
- Mapy toků (Flow Maps) - Systém sestavuje mapu cest k jednotlivým prvkům přímo propojenou s business logikou (v AITM už je integrováno).
- Autonomní navigace - Testy čtou živou mapu cest a přesně vědí, kam kliknout, co zadat a co ověřit (nyní ve fázi testování).
- Porovnání stavů (Visual Diffing) - Každý krok se zaznamenává se snímky obrazovky před úpravou kódu a po ní, aby se potvrdilo, že očekávané prvky a data odpovídají očekáváním v DB nebo UI.
- Ověřování business logiky - Automatická kontrola očekávaných výstupních dat (např. ověřené součty faktur - nyní ve vývoji).
- Noční integrační běhy - End-to-end integrační testy se budou generovat automaticky ze stavů kroků a požadavků na software a poběží přes noc. Jakékoli selhání vytvoří úkoly nebo vyžádá lidské ověření (AI se může mýlit a potřebuje schválení člověkem).
- Pokročilé scénáře - Budoucí verze přinesou vkládání neplatných parametrů, testování souběhu více instancí a simulace okrajových případů.
Shrnutí základních principů E2E
Podstata efektivního E2E testování spočívá v práci s mapami a vztahy mezi datovými entitami. U 90 % softwaru se vše sbíhá ke standardnímu životnímu cyklu:
#AITM #Validace vstupních dat #E2E #Integrační test #AI TESTING