# Testovací běhy a QA záznam (https://docs.vitrinka.ai/cs/qa/runs) ## QA plán [#plan] Testovací plán funkce je úkol typu `qa` pod jejím epicem a každá uživatelská cesta pod ním je úkol typu `journey`. **Flow** cesty je seznam kroků. Každý krok má druh — `act`, `verify` nebo `wait` — a říká, co udělat; volitelně také kde (`at`), co to dokazuje (`see`), lokátor a `next`. `next` ukazuje na jinou cestu nebo na některý její krok (`#`): tak se flow větví nebo vrací zpět. Checklist, který tester odškrtává, se z flow odvozuje, takže nikdo nedrží dva seznamy. Server plán kreslí jako jeden živý diagram shora dolů: pruh pro každou roli, cesty jedné role vedle sebe, kroky každé cesty zleva doprava a jen hrany, které vytvoří `next` a vazby `blocks`. Nad limitem velikosti se cesty složí zpátky do jednotlivých uzlů, aby se i velký plán vykreslil. * **Upravujte na místě** — klikněte na uzel kroku a cesta se otevře s tímto krokem zaměřeným v editoru flow (kind · do · at · see · next). Agenti mění totéž přes `edit_journey_node` nebo `update {kind: "task"}` nad poli cesty. * **Plán je jeho nástěnka** — panel úkolu `qa` ukazuje jeho nástěnku jen ke čtení, přizpůsobenou plánu; `vitrinka task qa-board ` tu nástěnku založí nebo vrátí, se sekcí Plan a jednou sekcí za každou cestu. * **Všechny plány na jednom místě** — **Record › QA** projektu vypisuje každý plán s verdiktem, pokrytím (prošlé cesty ze všech), počtem cest a tím, zda ho zrovna prochází agent, nad sezeními, běhy a hlášeními chyb, které ho naplnily. ## Vitrinka čte, váš runner běží [#law] Týmy si nechávají Playwright, Appium, Selenium, Cypress, Maestro nebo vlastní harness beze změny. Vitrinka čte, co po sobě běh nechá, a nikdy nespouští prohlížeč ani neřídí zařízení; integrace runneru je formát souboru, ne plugin, a ve vaší sadě testů se kvůli ní nemusí nic měnit. ## Jeden příkaz [#run] ```bash vitrinka qa run -- bun x playwright test vitrinka qa run --task 412 --pr acme/shop#42 -- bun x wdio run wdio.conf.ts ``` `vitrinka qa run -- ` spustí váš příkaz doslova, s několika proměnnými, které může respektovat kterýkoli reporter: `VITRINKA_RUN_ID`, `VITRINKA_RUN_DIR`, `VITRINKA_RUN_STARTED_AT` a `VITRINKA_SHOTS=always`. Když skončí, CLI najde, co běh zanechal — nejdřív runnery deklarované v repozitáři (`vitrinka setup --runners` je zapíše do `vitrinka.config.json`), jinak nejnovější výsledky zapsané od startu — složí je do jednoho manifestu běhu a publikuje ho. Návratový kód testovacího příkazu je návratový kód CLI: neúspěšná publikace nikdy nezakryje padající test a naopak. Běh přistane na `--task` (úkol qa, cesta, story nebo epic), jinak na funkci větve `vt-` z checkoutu, jinak na průběžném epicu projektu **Unplanned runs**. `--results ` přeskočí hledání; `--dry-run` testy spustí a složí, vypíše manifest a nic nepublikuje. ## Co umí složit [#formats] | Formát | Co vitrinka čte | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | JUnit XML | JUnit reporter Playwrightu, Jestu, wdio, Go a většiny dalších — sám pokryje Selenium, Cypress, Maestro, Detox, TestCafe i vlastní harness. Snímky jedou jako řádky `[[ATTACHMENT\|…]]` nebo jako soubory zapsané pod `VITRINKA_RUN_DIR`. | | Playwright JSON | Soubor JSON reporteru i s přílohami. | | allure | Adresář `allure-results`. | | wdio | Soubory `@wdio/json-reporter`. | | Manifest běhu | Manifest v1, který už zapsal runner nebo `vitrinka qa usertest`. | ## Manifest běhu [#manifest] Ať je formát jakýkoli, z běhu se stane jeden manifest v1. Runner ho může zapsat i sám a publikovat přes `vitrinka qa run publish `: ```json { "version": 1, "runId": "20260909-093000-ab12", "runner": "playwright", "app": "web", "branch": "vt-410-checkout", "sha": "7a3da39", "pr": "acme/shop#42", "specs": [ { "key": "checkout", "file": "e2e/checkout.spec.ts", "title": "Checkout", "cases": [ { "title": "pays with a saved card", "verdict": "fail", "ms": 4210, "shots": ["shots/checkout-1.png"], "error": "Expected total 42.00" } ] } ] } ``` Verdikt případu je `pass`, `fail` nebo `skip`. Cesty ke snímkům jsou relativní k adresáři manifestu a manifest pojme nejvýš 200 specifikací a 500 případů na specifikaci; případ nese libovolný počet snímků. ## Co přistane v záznamu [#record] Jedny dveře, `POST /api/v1/tasks/{id}/run` (MCP `publish_run`), promění manifest v QA záznam funkce — bez publikujícího agenta a bez ručně psaných komentářů. * **Plán vznikne sám** — pokud úkol `qa` chybí, založí se pod epicem funkce s jednou cestou za každou specifikaci. Cesty se párují podle klíče, pak podle názvu; nové se připojí na konec. * **Verdikty se skládají po cestách** — všechny případy prošly je `pass`, jakékoli selhání je `fail`, úspěchy s přeskočenými jsou `partial`, vše přeskočené nebo žádné případy je `untested`. Pokrytí plánu se sčítá z jeho cest. * **Důkazy na qa nástěnce** — sekce každé cesty nese callout běhu, případy jako checklist a mediální kartu za každý snímek. Opakovaná publikace téhož běhu jeho karty nahradí; nový běh se připojí pod něj. * **Reference tam, kam patří** — běh na úkolu qa i na epicu, sekce nástěnky a snímky na každé cestě, log na úkolu qa, pull request na epicu. * **Chyba za každý neúspěšný případ** — `--bugs intake` (výchozí) založí přes [příjem](/cs/pm/intake) draft chyby, který blokuje svou cestu; `direct` založí živou chybu pod story nebo epicem cesty; `none` nezaloží nic. ## Průzkumné testování jako běh [#usertest] Ruční testování vytvoří stejný záznam. Člověk nebo agent se skillem `/vitrinka:usertest` ([capture skilly](/cs/dev/skills/capture#usertest)) otevře session, pro každou zkoušenou věc otevře případ, nasnímá do něj obrazovky a uzavře ho verdiktem; `finish` session složí do manifestu — jedna cesta za každý případ — a publikuje ho stejnými dveřmi. ```bash vitrinka qa usertest start --task 412 --platform web vitrinka qa usertest case "Platba uloženou kartou" vitrinka board capture web --file cart.png --viewport 1440x900 --route /cart --note "Kupon uplatněn" vitrinka qa usertest verdict fail --note "Součet ignoruje kupon" vitrinka qa usertest finish ``` Každé `vitrinka board capture` mezi `case` a `verdict` se připojí k otevřenému případu a poznámka neúspěšného případu se stane prvním řádkem jeho draftu chyby.