TestCrunch 2026: Testerům zánik nehrozí. Ale čeká je pořádná jízda.

Zlatý věk testerů, nebo poslední konference s lidmi v sále?

Florian Fieber, prezident German Testing Board a člověk, který se AI v testování věnuje posledních dvacet let, začal svou přednášku jednoduchým průzkumem publika. Ruku vzhůru, kdo používá ChatGPT nebo podobné nástroje každý den. Téměř všechny ruce v sále. A teď — kdo z vás má pocit, že je díky tomu jeho práce zbytečná?

Ticho.

„To byl vlastně můj poslední slide," poznamenal Florian s úsměvem. A pak se pustil do hodiny, která si rozhodně zasloužila ten kofein z coffee breaku.

Tři pohledy na AI v testování

Florian rozdělil téma do tří pilířů, které testeři musí rozlišovat — jinak hrozí, že budou řešit špatný problém:

AI jako testovaný objekt. Deterministické systémy, kde na stejný vstup dostanete vždy stejný výstup, jsou minulostí. LLM a AI komponenty jsou probabilistické — fungují na principu pravděpodobnosti, nikoli jistoty. To vyžaduje nové metriky, nové přístupy k validaci a novou definici toho, co vlastně znamená „správný výsledek."

AI jako nástroj pro testery. Generování testovacích případů, testovacích dat, automatizačních skriptů — to všechno AI zvládá a zvládá dobře. Produktivita roste. Ale pozor: AI do testovacího procesu vnáší nedeterminismus, který tam předtím nebyl. Výstupy se liší, halucinace existují, a kdo je nekontroluje, ten si říká o průšvih.

AI-generovaný kód jako nový normál. S nástupem vibe codingu a AI code generátorů vzniká obrovské množství kódu — kódu, který někdo musí otestovat. Výzkumy ukazují, že tento kód obsahuje více defektů, nikoli méně. Méně syntaktických chyb, ale více logických, koncepčních a architektonických. Zkrátka chyb, které jsou hůř odhalitelné a dráž opravitelné.

„Někdo to musí uklidit. Někteří tomu říkají testeři."

95 % firem nedosahuje pozitivního ROI z GenAI

Jedno ze silnějších sdělení celé přednášky: studie MIT zjistila, že drtivá většina firem, které nasadily GenAI, zatím nevidí pozitivní návratnost investice. Florian to nazval efektem „buy now, pay later" — kódování je rychlejší, ale čas ušetřený při psaní se ztrácí při ladění, validaci a opravách problémů, které AI zanesla.

Tohle není argument proti AI. Je to argument pro to, aby do procesu vstoupil někdo, kdo rozumí rizikům. A to je — překvapivě — tester.

Bottleneck jako feature, ne bug

Jeden z nejprovokativnějších momentů přednášky: Florian obhajoval pomalost lidského testování jako strategickou výhodu. Pokud je QA bottleneck, problém není v testerech — problém je v overproduction upstream.

„Možná je dobře, že tam je nějaký čas, kdy se zastavíme a přemýšlíme, co vlastně děláme. Jinak jednoho dne zmáčkneme tlačítko a za pět minut máme nový SAP systém — a nikdo neví proč."

Fool with a tool is still a fool

Florian si nenechal ujít příležitost zmínit svůj oblíbený nástroj — Claude — na který přešel z ChatGPT. Ale zároveň jasně pojmenoval past, do které padá spousta lidí: jednovětný prompt, vygenerovaný výstup, copy-paste, posláno manažerovi jako hotový testovací plán.

„Nástroj bez kompetence hodnotu nevytvoří. A fool with a tool is still a fool."

Závěr byl jednoznačný: AI nenahrazuje testery. Zvyšuje nároky na to, čím tester musí být — kritický myslitel, strážce kvality, člověk, který rozumí rizikům a umí o nich mluvit s ostatními.

Pokud první přednáška odpovídala na otázku PROČ testeři v éře AI nezmizí, druhá ukázala jak to vypadá v praxi — přímo z IT oddělení Škoda Auto, respektive jeho dceřiné společnosti Green:Code (dříve DigiLab).

Petr Škoda přišel na pódium bez velkých teorií. Přišel s příběhem týmu, který byl chronicky přetížený, prohrával souboj s časem a rozhodl se to změnit.

Ze sedmi měsíců na tři dny. To není magie, to je AI asistent v Jiře.

Stav před: tester jako hasič na konci procesu

Situace, kterou popsal, bude povědomá každému, kdo v QA strávil aspoň pár měsíců. Tester jako reaktivní článek na konci vývojového řetězce. Až 70 % času spolkne manuální provádění testů. Na shift-left — tedy na to, aby se QA zapojilo už na začátku, při psaní požadavků — nezbývá ani čas, ani kapacita.

„Chtěli jsme z toho ven." A tak začali experimentovat.

Cesta k vlastnímu řešení

Začalo to skromně — jeden z členů týmu, Mára, získal GCP certifikát, u toho si pohrál s prvními AI asistenty a tým měl najednou prototyp. Jenže automotive průmysl je regulované prostředí s přísnými pravidly pro nakládání s daty. Obecné AI nástroje dostupné na trhu tam prostě nefungovaly.

Místo vzdání se přišlo pivotování: tým se rozhodl postavit vlastní aplikaci. Rozšíření Jiry, vlastní pluginy, vlastní správa kontextu a citlivých údajů. A jeden z testerů — Kuba — se při tom proměnil v full-stack vývojáře interního nástroje. Přinesl do vývoje to nejcennější: hluboké porozumění tomu, co tester skutečně potřebuje.

Nový workflow: AI jako spolupilot, ne autopilot

Výsledný systém pokrývá celý testovací cyklus jako asistent, ne jako náhrada. Revize zadání ještě před vývojem odhalí nejasnosti a chyby ve specifikaci dřív, než se vůbec začne kódovat. Automatické generování testovacích scénářů ze zadání. Automatizované provádění s možností výběru konkrétního AI modelu podle kontextu projektu. Standardizovaný bug reporting, který konečně vypadá stejně bez ohledu na to, kdo ho píše.

Klíčový důraz: AI dostane kontext — projektový, doménový, regulatorní — a teprve pak generuje. Bez kontextu je výstup průměrný. S kontextem je použitelný. Lidská validace přitom zůstává na každém kroku.

Čísla, která mluví za vše

Automatizace středně velkého projektu, která dříve trvala 7 měsíců, se s novým nástrojem zvládne za 2–3 dny. Celková úspora kapacity projektového týmu: až 13 %. A co je možná důležitější — testeři mají konečně čas dělat to, na co dříve čas nebyl: zapojit se na začátku, ptát se na požadavky, předcházet chybám místo jejich hašení.

Z publika padla otázka, která visela ve vzduchu: Co se stane se senioritou testerů, když rutinní práci přebere AI? Jak si junioři vypracují zkušenosti? Petr Škoda uznal, že jde o reálné riziko. Klíčem není nechat AI rozhodovat — klíčem je nechat AI generovat a člověka validovat a kriticky myslet.

Někdy nejlepší způsob, jak vysvětlit složitou věc, je vyprávět příběh. Petr Fifka si to zjevně dobře uvědomuje — místo snímků plných diagramů a šipek přišel s Lucií a Botíkem. A sál ho za to odměnil nejvyšším hodnocením celého dne.

Lucie je ostřílená testerka, která se pouští do automatizace. Botík je její nový AI agent —copilot, parťák, spasitel. Aspoň zpočátku.

Fáze první: euforie

Lucie zadá Botíkovi manuální testovací scénář. Použije Claude Opus — nejvýkonnější model, který má k dispozici. Botík chvíli přemýšlí a pak vyplivne hotový Playwright test. Vypadá dobře. Dokonce by mohl fungovat.

Lucie je nadšená. „Já tam zadám jenom manuální scénář a on mi vyplodí hotový kód? To je luxus!"

A tak začne Botíkovi důvěřovat čím dál víc. Přestane revidovat výstupy. Přestane kontrolovat detaily. Vždyť to funguje, ne?

Fáze druhá: průšvih

Několik týdnů (nebo měsíců — záleží na týmu) se stane to nevyhnutelné. Produkce nejede. Testy se rozsypaly. Lucie tráví hodiny nad opravami, kterým nerozumí, protože kód psal Botík a ona ho nikdy pořádně nečetla.

Petr Fifka se zastavil u konkrétního příkladu z toho prvního vygenerovaného kódu. Citlivé přihlašovací údaje přímo v testu — hardcoded. Nestabilní selektory. Zbytečné komentáře. Žádné znovupoužití komponent. Žádný Page Object Model.

„Za to nemůže AI. Za to může spíš Lucie."

Tvrdá slova — ale Petr je řekl s pochopením, ne s odsouzením. A pak vysvětlil proč.

„Ten model je jako hyperaktivní junior na třech Red Bullech. Snaží se dodat rychle a správně — ale nikdo mu neřekl, co správně v tomhle projektu znamená."

AI se učí na veřejných repozitářích. A co na nich převládá? Kód, který funguje — ne kód, který je udržitelný. Bez kontextu, bez pravidel, bez příkladů nemůže model vědět, co váš tým považuje za kvalitu.

Fáze třetí: onboarding Botíka

Lucie se nevzdala. Vrátila se na začátek a začala přemýšlet jinak. A nastala přeměna: začala Botíka onboardovat jako nového člena týmu. Napsala instrukční soubor — strukturovaný dokument (~300 řádků, doporučené maximum je 1 000) popisující kdo Botík je a jakou roli má, základní architekturu aplikace, pravidla kvality (Page Object Model povinně, maximální délka funkce, strategie lokátorů, jak zacházet s testovacími daty a citlivými údaji) a konkrétní příklady kódu.

„Ukaž, neříkej" — Petrovo klíčové motto celé přednášky. Obecný pokyn „piš čistý kód" je k ničemu. Konkrétní ukázka čistého kódu změní vše.

Multi-agentní orchestrace: jeden Botík nestačí

Ani perfektní instrukce ale neřeší všechno. Petr ukázal, co se stane, když má jeden agent příliš mnoho pravidel a příliš mnoho úkolů najednou: přetíží se kontext, agent začne ignorovat pravidla nebo si vymýšlet nová.

Řešení? Rozdělit práci mezi specializované agenty s jasnými kompetencemi: E2E orchestrátor řídí celý průběh testování, exploratory agent prozkoumává aplikaci, revizor lokátorů kontroluje stabilitu selektorů, security agent hlídá citlivé údaje.

Playwright MCP: AI, která skutečně vidí prohlížeč

Vrcholem přednášky byla živá demonstrace Playwright MCP — nástroje, který dává AI agentovi přímý přístup k prohlížeči. Botík v reálném čase otevřel testovací aplikaci, proklikal přihlašovací scénář, pořídil screenshoty, vygeneroval report — a navíc identifikoval bug: systém akceptoval nevalidní přihlašovací údaje.

Celý E2E scénář trval pět minut a dvacet sekund.

Z publika přišla přirozená otázka o bezpečnosti a prompt injection. Petr odpověděl s odzbrojující upřímností: „Nejsem security expert. Zajdu za security inženýrem a nechám to vyřešit někoho, kdo na to má."

Závěr: tester se stává architektem

Petrův příběh Lucie a Botíka je příběh o zrání. O tom, že AI euforie je přirozená fáze — ale fáze, ze které se musí vyrůst. Role testera se neruší. Přesouvá se — z exekutora na architekta agentů.

„Než sednete do létajícího auta, naučte se nejdřív řadit."

Moderátor Jiří Charvát uvedl čtvrtou přednášku s mu vlastním humorem. Nejdřív se zeptal sálu, kdo má bordel v šuplíku s ponožkami — tam přece hledáte čtyřikrát déle, než potřebujete.

Úplně stejně jako v testovacím kódu bez struktury, v kódu, který jste psali před půl rokem a který teď vypadá, „jako by ho psal někdo cizí ve tmě, opilý, během ekonomického záchvatu."

A pak dodal pointu: „AI, hezký všechno, hype, super — ale než sednete do létajícího auta, naučte se nejdřív řadit."

Na pódium přišel Konstiantyn Teltov — QA lead, QA architekt, zakladatel QA Guildu a autor více než padesáti článků na Medium. S tématem, které by ještě před třemi lety vyplnilo každou konferenci, ale dnes se za ním stín AI hypu občas přehlédne. Design patterny. Klasika. Fundament.

Gang of Four v testovacím světě: průřez těmi nejužitečnějšími

Konstiantyn prošel klasickými 23 GoF patterny a vybral ty, které mají v testovací automatizaci skutečný smysl — vždy s konkrétním problémem a jeho řešením:

Singleton — jedna instance konfiguračního souboru nebo databázového připojení. Pozor: někteří ho považují za anti-pattern, používat uvážlivě.

Factory Method — abstrakce výběru WebDriveru. Chrome driver natvrdo zakódovaný v testu? Klasická past. „Je to jako kávovar — chcete kávu, to je interface. Jestli latte nebo espresso, to rozhodne podtřída."

Abstract Factory — pro práci s více databázovými providery. Test nezná konkrétní implementaci, pracuje jen s kontraktem. Jeden z Konstiantynových oblíbených.

Builder — řešení pro komplexní datové modely s mnoha parametry. Konstruktor se šesti parametry je anti-pattern. Builder umožňuje Lego-styl skládání objektu. „Váš kód se stane čitelným."

Prototype — klonování podobných objektů bez opakování inicializace.

Facade — jeden vstupní bod do komplexního subsystému. „Ukážete kartu na recepci a dostanete se kamkoliv potřebujete."

A pak test-specifické patterny: Page Object Model, Component Object Model, Lazy Initialization, Dependency Injection (driver nikdy přímo v page objektu!) a Object Pool pro recyklaci WebDriverů.

Overengineering: past, do které spadl každý

Z publika přišla přesná otázka: jak najít rovnováhu mezi robustní architekturou a frameworkem, který zvládnou i junioři?

Konstiantyn odpověděl s odzbrojující upřímností: „Když jsem byl mid-level, overengineeroval jsem. Vždycky, když jsem se naučil něco nového, hned jsem to chtěl aplikovat všude. Tak to děláme všichni — i teď s AI."

Recept: začněte jednoduše. Ptejte se, zda je daný problém skutečně opakující se. Pattern je nástroj, ne dogma.

Design patterny jako kolejnice pro AI

Nejsilnější myšlenka přednášky přišla ke konci. Z publika zazněla otázka: Bude naše závislost na klasických designových vzorech růst, aby strukturovaly AI-generovaný boilerplate? Nebo si AI časem vymyslí vlastní způsoby organizace testovací logiky?

Teltovova odpověď byla jednoznačná: „Doufám, že AI si nic nevymyslí sama. Protože AI není inteligence v lidském smyslu — je to probabilistický systém."

A pak, s přímostí, která dostala největší smích celé přednášky: „ Pokud AI začne přemýšlet za nás — myslím, že to bude konec naší civilizace. Promiňte, vyrůstal jsem na Terminátorovi."

Design patterny tedy v éře AI nezastarávají — naopak. Jasná struktura projektu, explicitní kontrakty a rozhraní jsou přesně to, co AI potřebuje jako „kolejnice", aby generovala kód, který je udržitelný a srozumitelný.

„Pamatujte: jste inženýři a architekti testů. Ne jen automatizátoři."

Pohled zevnitř — ale z druhé strany stolu.

Před třemi lety stál Robin Weiss na stejném pódiu TestCrunch jako QA manager. Letos se vrátil — ale v jiné roli. Jako Product Manager ve Vendavo. Jako člověk, pro kterého QA není kolegou, ale partnerem. A jako někdo, kdo si všiml něčeho znepokojivého.

„Testeři mu přestali volat." uvedl ho moderátor Jiří Charvát. „Jako každý rodič dobře ví — nejdřív je vychováte, pak vám přestanou volat."

Než se Robin ponořil do tématu, navrhl krátký rituál. Pět vteřin ticha — za QA, které jako první v historii přesvědčilo vývojáře, že chyba je chyba, ne záměr. „Nedávno nám tenhle člověk odešel z tohohle světa. Chuck Norris."

Smích v sále. A pak čtyři problémy, které smích rychle utlumily.

Problém #1: Ztráta kontextu — nebo jak jsme přišli o Kláru

Robin popsal svět, který většina v sále zná: na jedné straně manuální QA — analytici, kontextové znalosti, oponenti produktového managera. Na druhé straně automation QA — efektivita, frameworky, rychlost.

„Svět byl celkem v rovnováze. Pak přišla AI."

Diskuze o tom, co testovat a proč, se vytratila. Nahradila ji diskuze o frameworcích, agentech, implementacích. Automation QA mají k AI přirozeně blíže — dostávají příležitosti, pozornost, budget. A kontextová, byznysová strana QA tiše mizí.

Robin to ilustroval příběhem. Klára — jedno z nejlepších QA, které kdy poznal. Přicházela na každý refinement se seznamem připravených otázek, analyzovala dopad na celý systém a pravidelně posílala produktového manažera zpátky za zákazníkem — s tím, že zadání prostě nedává smysl.

„Ona mě dohnala k štěstí. Myslel jsem, že přicházím vždy připravený. Ale často jsem nebyl."

A dnes? Tým se z devíti QAs zredukoval na čtyři. Klára nestíhá. Na refinement přichází bez přípravy. A Robin? „Cítím se skvěle. Nikdo nemá žádné dotazy. Zdá se mi, že díky AI je celý proces hladší."

Jenže ono to tak není. Jen chybí člověk, který by mu to řekl.

Problém #2: Krize juniorů — přerušený řetězec

Málokdo v sále přiznal, že jeho firma v posledním půl roce přijala juniora. Robin to viděl a nebyl překvapen.

Proč by firmy juniory přijímaly? Dřív existoval jasný důvod: regresní testování, procházení backlogu, ověřování bugů. Dnes to zvládne senior s AI nástrojem. Juniorní práce zmizela — a s ní i důvod juniory najímat.

Jenže tím se přerušuje přirozený řetězec: junior → medior → senior → mentor. „Poločas rozpadu každého inženýra je někde mezi dvěma až pěti lety. Ti lidi odejdou — to nezastavíte. A když odejdou, vezmou si s sebou znalosti. Kdo je nahradí?"

Firmy, které dnes šetří na juniorech, si za několik let budou říkat, kde se ztratili senioři.

Problém #3: Shift-right — návrat tam, kde jsme začínali

Klára nemá čas. Juniory nemají. Kdo tedy testuje vlevo? Kdo se zastaví a řekne produktovému manažerovi, že zadání nedává smysl?

Nikdo. A tak se — paradoxně — v éře největší testovací automatizace v historii — vracíme k reaktivnímu testování na konci vývojového cyklu.

„Shift-right. Myslím, že se tam pomalu přesouváme."

Problém #4: Ztráta kontroly — kdo čte patnáctistránkový elaborát?

AI generuje obrovské množství obsahu. Testy, scénáře, architektonické dokumenty, zadání. A nikdo to nečte.

Robin popsal situaci ze své praxe: architekt vezme jeho epiku, prožene ji AI a vygeneruje patnáctistránkový dokument o navrhované architektuře. „Já to nečtu. To nejde. Titulky vypadají dobře, dává to zhruba smysl — odklepnu to."

Na základě odklepu se implementuje. Na základě implementace se generují testy. A chyba, která vznikla hned na začátku v nedomyšleném zadání, se propaguje celým procesem.

„A pak se to ještě zdokumentuje pomocí AI. A máte recept na slušný průšvih."

Závěr: přesvědčujte ty, kdo rozhodují

„Největší hrozbou není to, že nás AI nahradí. Je to, že usneme na vavřínech v domnění, že nás nahradit nemůže."

Happy manager, který z pěti QAs udělal dvě a dostane bonus za úsporu, nevidí horizontem jednoho fiskálního roku. QA musí mluvit jeho jazykem — a přesvědčit ho, než bude pozdě.

Zlatý hřeb dne nebyl oběd. Byl to člověk, který testuje Zemi.

Moderátor Jiří Charvát přiznal, že přednášce nechcěl věřit. Četl anotaci třikrát. Šel si ověřit web, jestli to fakt existuje. A pak ji uvedl odkazem na minisérii Devs od Alexe Garlanda — o stroji schopném simulovat celý vesmír.

„Tohle je totéž, akorát v plenkách."

Na pódium přišel Kristián Kottfer, QA engineer z BAE Systems OneArc — firmy, která vznikla z Bohemia Interactive Simulations a která vytváří grafickou simulaci celé planety Země v měřítku 1:1 pro výcvik armád, policejních složek a záchranářů ve zhruba šedesáti zemích světa.

Proč simulovat planetu místo jít ven? „Protože potřebujeme umět lépe válčit. Nebo se ubránit." Místo plýtvání reální municí vojáci nastoupí do simulátoru a trénují nanečisto. Na libovolném místě planety. Opakovaně. S kompletním záznamem každé sekundy.

Co vlastně testujete, když testujete planetu?

VBS4 s enginem VBS Blue není hra. Cílem není zábava, ale výuková efektivita a shoda s vojenskými doktrínami.

Rendering v reálném čase cílí na 60 snímků za sekundu — každý snímek musí být hotový za 16 milisekund. Engine počítá osvětlení na úrovni každého trojúhelníku, pozici Slunce, atmosférické rozptyly, počasí, částicové efekty. Protože není možné renderovat vše, systém dynamicky rozhoduje — co je daleko, zjednoduší. Co uživatel nevidí, nevykreslí.

Data pipeline je modulární síť vzájemně propojených pluginů — DAG struktura. Přes šedesát biomů, každý s více vrstvami a sezónními variacemi. A pak — nejzajímavější výzva — multimodální senzory. VBS Blue nesimuluje jen to, co vidí lidské oko. Simuluje noční vidění a termovizi — se zcela odlišnými fyzikálními modely. Mokrý asfalt se v termovizi chová jinak. Vzduch s různou vlhkostí ovlivňuje tepelný rozptyl jinak. A všechny tři zobrazovací režimy musí být fyzikálně konzistentní navzájem i vůči realitě.

„Teď víte, jak se cítí naše QA. Když chcete testovat takový systém, může se to občas zdát jako nemožný úkol."

Sedm QA na 21 vývojářů — a systém, na kterém závisí životy

Blue Team má 21 vývojářů enginu a 7 QA. Seniorita je extrémní: někteří lidé jsou v týmu deset až dvacet let. Testovací prostředí není žádný komerční nástroj — je to sada interních aplikací. BlueView je produkční pohled. DiagManager je hluboká konzole pro kontrolu všeho, co engine umí. Dev script slouží pro deterministickou automatizaci testů.

CI/CD pipeline produkuje denní a noční buildy s vizuálními regresními testy — pixel po pixelu, GIF diffy, reporty přes Hub, Sheets a Slack. A tady nastává jeden z nejzajímavějších problémů přednášky: nedeterminismus grafického enginu. Upscaling algoritmy produkují různé výsledky. Mikrostuttery — drobné záseky neviditelné lidským okem — způsobují, že vizuální test selže kvůli změně jediného pixelu.

Nastavit práh tolerance tak, aby nechytalo falešné alarmy a přitom nezameškal reálný regres, je samo o sobě technická výzva.

AI v systému, kde na výstupu závisí životy

Kristián byl v otázce AI přímý a střízlivý. Ve firmě, která pracuje pro obranný průmysl šedesáti zemí, jsou bezpečnostní a compliance požadavky extrémní. Náhodný AI systém s přístupem k interní infrastruktuře nepřichází v úvahu.

Realistický plán: AI jako asistent pro sumarizaci výsledků vizuálních testů, analýzu logů, generování reportů a sdílení změn přes týmy. Ne jako náhrada expertního úsudku v bezpečnostně citlivých částech systému.

„Většina týmů, které začínají s AI, selhává, protože mají příliš velké oči. My začínáme malými kroky a měříme přínos."

Závěrečné slovo dne

Kristián Kottfer zakončil přednášku myšlenkou, která perfektně uzavřela celý TestCrunch 2026: „My jako QA vždy pracujeme s chaosem. A jediný způsob, jak ho zvládnout, je pomalý, stabilní, iterativní přístup — řešit jeden problém najednou, ne hledat řešení, které vyřeší vše."