Testovací běhy a QA záznam

QA plán

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 (<journey-key>#<step>): 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 <id> 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ěží

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

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 -- <test command> 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-<id> z checkoutu, jinak na průběžném epicu projektu Unplanned runs. --results <path> přeskočí hledání; --dry-run testy spustí a složí, vypíše manifest a nic nepublikuje.

Co umí složit

Manifest běhu

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 <manifest.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

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 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

Ruční testování vytvoří stejný záznam. Člověk nebo agent se skillem /vitrinka:usertest (capture skilly) 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.

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.