QA v době AI agentů: jak testovat, když většinu kódu píše AI

📺 Záznam přednášky Madiny Akramovy z Ackee Meets: QA v době AI:

Vývojáři začali psát kód s AI agenty a tempo se zrychlilo natolik, že QA přestalo stíhat proklikávat. Naše řešení bylo drzé přesně v tom, jak je jednoduché: sáhnout po stejných nástrojích jako vývojáři a nechat Claude Code, ať tu manuální část testování odklikává za nás.

📋 TL;DR

• Kód dnes z velké části píše AI agent, a to znamená víc materiálu k otestování za stejný sprint. QA nemá být pomalejší polovina týmu.
• AI nepíše nutně špatný kód, jenom mnohem víc kódu. A má silnou motivaci rozsvítit zelený test – klidně i tím, že padající test tiše smaže.
• Aby byl Claude Code v testování k něčemu, potřebuje QA harness: tools, skills, context, guardrails, memory a integrace přes MCP.
• Testing-notes skill dostane číslo ticketu a odkaz na pull request a vrátí konkrétní checklist, co otestovat.
• Maestro pokrývá end-to-end testy v YAMLu, Proxyman dává kontrolu nad síťovou komunikací. Oba mají MCP server, takže je Claude ovládá sám.
• V demu Claude aplikaci nikdy předtím neviděl – prozkoumal ji přes screenshoty a accessibility, sám si opravil selektor a hotový flow uložil k opakovanému spouštění.
• Manuální testování přestává být manuální, ale QA nemizí. Posouvá se k orchestraci AI agentů, hledání rizik a validaci výstupů.

⏱️ Timeline: od ručně psaného řádku k featuře za odpoledne

V roce 2014 psal vývojář každý řádek sám. Funkce, kterou dnes zvládne za odpoledne, tehdy trvala týdny – a QA mělo díky tomu příjemně předvídatelné tempo. Přijde ticket, otestuje se, jede se dál.

V roce 2022 přišly nástroje jako Copilot a ChatGPT. AI začala doplňovat kód, sprinty se zkrátily a věcí na otestování začalo přibývat.

A v roce 2026 je AI agent běžnou součástí každodenní práce vývojáře. Napíše většinu kódu, vývojář ho směruje, kontroluje a dolaďuje. Výsledek je výrazně víc kódu za sprint než dřív – a pro QA podstatně víc materiálu k otestování.

Skutečná otázka, kterou si nad tím klademe, je jednodušší: jak můžeme používat stejné nástroje jako vývojáři a být stejně rychlí?

🐛 Bugy, které dělá AI agent: rozbité pole se jménem a tiše smazaný test

Rychlost vývoje vystřelila nahoru a s ní i množství bugů. Neznamená to nutně, že AI píše špatný kód. Jenom je toho kódu mnohem víc – a některé chyby mají docela charakteristický tvar.

První klasika: agent napíše aplikaci, vygeneruje k ní krásné testy, pokrytí sto procent, všechno svítí zeleně. A pak přijde uživatel, napíše si do jména emoji a celé to spadne.

Druhá klasika je zákeřnější. AI má silnou motivaci k tomu, aby testy prošly. Když si má vybrat mezi „splnit zadání“ a „rozsvítit zelený test“, sáhne často po té druhé možnosti. Agent se totiž umí pohybovat ve dvou módech: buď vám s naprostým klidem napíše půlku architektury celého systému, nebo tiše smaže test, který padal – protože to bylo jednodušší než ho opravit.

Testy jsou důležité, ale nezachytí všechno – co dělat, aby vás nepříjemné překvapení nenašlo až od uživatele, řeší článek o monitoringu backendu.

🧰 QA harness: co Claude Code potřebuje, aby byl v testování užitečný

Napsat do promptu, ať se chatbot chová jako zkušený tester s padesátiletou praxí, nedělá chyby a nehalucinuje, nám dávno nestačí. Proto jsme se rozhodli používat stejné nástroje jako vývojáři – konkrétně Claude Code.

Aby ale agent reálně pomáhal s naší prací, musíme mu nastavit prostředí. Říkáme mu harness: výbava, kterou má agent kolem sebe.

Uprostřed je samotný agent. Pracuje v cyklu: přemýšlí, jedná, pozoruje výsledek, a znovu. Není to chatbot, který jednou odpoví a tím to skončí – je to nástroj, který pracuje na úkolu, dokud není hotový. A kolem něj šest věcí, na kterých záleží:

• Tools. Claude umí spouštět příkazy, číst a upravovat soubory. Není zavřený v chatu, pracuje přímo v projektu.
• Skills. Specializované postupy pro věci, které děláme často. Místo abychom agenta pokaždé učili od začátku, máme připravený postup.
• Context. Sada instrukcí, která vysvětluje, jak vypadá náš projekt, jak testujeme a co od agenta čekáme. Bez toho odpovídá obecně, s tím konkrétně k našemu projektu – včetně odkazu na repozitář se zdrojovým kódem.
• Guardrails. Hranice, které agent nesmí překročit. Co nesmí číst, co nesmí měnit, kam nesmí psát.
• Memory. Dlouhodobá paměť napříč úkoly. Když mu jednou vysvětlíme, jak fungujeme, nemusíme to příště vysvětlovat znovu.
• Integrations. Napojení na reálné nástroje přes MCP server – ticketovací systém, GitLab, Slack a nástroje, které používáme při testování: Maestro, Proxyman, Postman.

📝 Testing-notes skill: z ticketu a pull requestu vypadne checklist

Dřív to fungovalo tak, že vývojář po dokončení pull requestu napsal testing notes – co je potřeba otestovat. Znělo to logicky, kód psal on, takže nejlíp věděl, co se změnilo.

Dneska to děláme jinak. Claudovi pošleme číslo ticketu a odkaz na pull request. On si sám stáhne zadání, projde změny v kódu a vrátí konkrétní checklist, co otestovat – ve formátu, na jaký jsme zvyklí. Je to skill, který používám na denní bázi.

📱 Maestro: end-to-end testy v YAMLu, které za vás napíše agent

Maestro slouží na end-to-end testování mobilních aplikací, iOS i Android. Testy se v něm píšou v YAMLu, takže test vypadá jako srozumitelný seznam kroků: otevři aplikaci, klikni sem, napiš tohle, zkontroluj, že se objeví tamto. Přečte to i člověk, který nikdy neviděl kód.

A hlavně – Maestro má MCP server. To znamená, že se na něj Claude umí přímo napojit. Nemusíme YAML testy psát ručně: řekneme agentovi, co chceme otestovat, on test napíše, spustí ho na reálném zařízení nebo simulátoru a vrátí výsledek. My ho jen zkontrolujeme.

Na přednášce jsem to ukazovala na mobilní aplikaci, kterou v Ackee vyvíjíme pro BoxNow. Vlevo byla konverzace s Claudem, uprostřed takzvaný Maestro viewer se všemi příkazy, které agent poslal do Maestra, a vpravo zrcadlení obrazovky reálného Android zařízení. Zadání znělo: prozkoumej aplikaci a vytvoř end-to-end flow pro odeslání zásilky do výdejního boxu.

Výsledný flow je pak čitelný seznam kroků – zkráceně vypadal takhle:

- launchApp
- assertVisible: "Send parcel"
- tapOn: "Send parcel"
- assertVisible: "Sender country"
- tapOn: "${output.PARCEL_SIZE}"
- tapOn: "Continue"
- assertVisible: "Recipient contact details"
- inputText: "${output.LOCKER_SEARCH}"
- tapOn: "${output.LOCKER_NAME}.*"
- tapOn: "Choose this locker"
- inputText: "${output.RECIPIENT_PHONE}"
- hideKeyboard
- tapOn: "Continue"

Na záznamu je vidět, jak agent postupuje: prozkoumá obrazovku, udělá si screenshot, aby viděl, co na ní je, vybere velikost zásilky. Jeden příkaz se mu nepovedl, ale dokázal se poměrně rychle opravit sám – stačilo přepsat selektor, aby vybral správný element.

Podstatné je, že Claude vůbec nevěděl, jak aplikace vypadá. Zkoumal ji poprvé a měl k dispozici jen základní popis projektu a přístup do repozitáře. Samotný průzkum dělal přes screenshoty a accessibility, takže postupoval dost naslepo. Prvních pár minut proto zabralo víc času, než by dalo ruční proklikání. Čím víc testů ale v projektu bude, tím lepší přehled o aplikaci agent získá.

🌐 Proxyman: kontrola nad síťovou komunikací a mockování odpovědí

Třetí nástroj v naší výbavě je Proxyman, HTTP debugging proxy. Vidíme v něm přesně, co mobilní aplikace posílá na backend a co dostává zpátky. Používáme ho na mockování requestů a responsů: donutíme backend vrátit odpověď, kterou potřebujeme, a koukáme, jak se aplikace zachová. A stejně jako Maestro má i Proxyman MCP server.

Na tomhle příkladu Claude ověřoval negativní scénář. Měl při odeslání zásilky zadat telefonní číslo ve špatném formátu – bez mezinárodní předvolby – a zkontrolovat, že se to nikam neprotlačí. Aplikace ho zastavila u kroku s příjemcem a pole s telefonem zčervenalo s inline chybou. Na straně serveru pak Proxyman zachytil, že validační endpoint odpověděl kódem 422 Unprocessable Entity.

Celé to agent zvládl kombinací Maestro MCP a Proxyman MCP: spustil správné kroky v mobilní aplikaci a v síťovém provozu k nim našel příslušnou chybovou zprávu.

🔗 Tři nástroje, jeden agent: co z toho dělá MCP

Když to dáme dohromady, vyjde z toho docela úsporná sestava.

Maestro nám pokrývá testování mobilních i webových aplikací, Proxyman dává kontrolu nad síťovou komunikací. A protože oba mají MCP server, umí je Claude ovládat sám. My nemusíme být uprostřed každého kroku.

🔍 Co jsme si u toho ověřili: halucinace, náklady a lidská kontrola

Nebudu předstírat, že je to bezešvé. Pár věcí se ukázalo hned.

Halucinace se objevily – konkrétně u testing-notes skillu, kde mi agent vymyslel scénář, který se zadaného ticketu vůbec netýkal a nebylo potřeba ho testovat. U Maestra a Proxymanu jsem na to zatím nenarazila, ale ty používáme kratší dobu.

Stoprocentní pokrytí flows to taky není. U nových featur si výsledek vždycky ještě projdu ručně. Nejlíp se to zatím osvědčilo na věcech, které se opakují: smoke testy a regresní flow, kde je rychlost největší výhra.

A náklady? Používala jsem Opus v rámci firemního týmového plánu a při testování jsem svůj limit nepřekročila. Maestro i Proxyman jsme měli v placené verzi, kterou platí firma. Detailní cost-benefit analýzu, tedy kolik přesně nás ta zvýšená produktivita stojí, jsme zatím neudělali – a je fér to říct nahlas.

🔄 Manuální testování přestává být manuální. QA nekončí

A přesně tady se mění to slovo „manuální“. To, čemu jsme dřív říkali manuální testování – proklikávání, ověřování, porovnávání – manuální být přestává. Testování zůstává, jen ten manuální krok dělá za nás Claude.

Pozor, neznamená to, že QA mizí. Znamená to, že se posouváme. Místo abychom čtyřikrát do týdne klikali stejný regresní flow, věnujeme čas věcem, které agent neumí: ptáme se, jestli to dává smysl, hledáme rizika, validujeme výstupy. V podstatě orchestrujeme práci AI agentů.

❓ FAQ

Dají se Maestro testy rozdělit do víc souborů, třeba přes page object model?

Částečně. Maestro umí přes příkaz runFlow zavolat samostatný YAML soubor jako podflow, takže se dá sdílená posloupnost kroků vytáhnout do vlastního souboru a použít opakovaně. U nás ale agent zatím generoval spíš samostatné, ploché flow soubory bez týhle podflow struktury.

Jak může Claude testovat aplikaci, kterou nikdy neviděl?

Má přístup do repozitáře, takže se může podívat na kód. Samotnou aplikaci pak zkoumá přes Maestro: dělá si screenshoty a čte accessibility strukturu obrazovek. První průzkum je proto pomalejší, další už staví na tom, co zjistil.

Jaký model je na testování potřeba?

Na tomhle testování jsem používala Opus v rámci firemního týmového plánu. Svůj limit jsem při tom nepřekročila.

Kolik stojí testování s AI agentem?

Claude, Maestro i Proxyman jsme používali v placených verzích, které hradí firma. Detailní cost-benefit analýzu, která by porovnala zvýšenou produktivitu s náklady, jsme zatím neudělali.

Halucinuje agent i v testovacích scénářích?

Ano, stalo se to. U testing-notes skillu vymyslel scénář, který se se zadaným ticketem vůbec nepotkal. Proto výstup pořád někdo čte.

Nahradí AI manuální QA?

Podle mě nebude „manual QA“, bude jen QA. Manuální část za nás odklikají nástroje, ale rozhodování, priorizace a poslední kontrola zůstávají člověku.

🎯 Co si odnést

AI agenti nezpůsobili, že by kód byl horší. Způsobili, že ho je mnohem víc – a tím posunuli úzké hrdlo z vývoje do testování. Odpovědí na to není testovat rychleji rukama, ale postavit agentovi stejné prostředí, jaké má vývojář: harness s tools, skills, contextem, guardrails, memory a integracemi přes MCP.

Prakticky to znamená tři věci. Skill na to, co děláte pořád stejně, ať už je to testing-notes nebo cokoli jiného. Nástroje s MCP serverem, aby je agent uměl řídit sám – u nás Maestro na end-to-end testy a Proxyman na síťovou komunikaci. A pak lidská kontrola tam, kde jde o úsudek: co je riziko, co je priorita a co vlastně klient chtěl.

Jestli vás zajímá, jak podobný posun vypadá na straně vývoje, mrkněte na srovnání Cursoru a Claude Code nebo na to, jak si QA tým postavil vlastní aplikaci na evidenci testovacích zařízení.

Celý příběh i s dotazy z publika najdete v záznamu přednášky. Termíny dalších Ackee Meets sledujte na Eventbritu a přihlaste se k newsletteru – příští takový obsah vám přijde přímo do schránky.