{"slug": "why-manual-test-cases-should-live-in-yaml", "title": "Why Manual Test Cases Should Live in YAML", "summary": "A developer argues that manual test cases should be stored as YAML files in version control rather than in SaaS databases. The approach leverages AI for case generation, enables PR-based review via git diff, and provides native compliance and data ownership. The YAML format allows cases to be linked to automated tests and versioned alongside application code.", "body_md": "Most teams still treat manual test cases as rows in a SaaS database. That worked when cases were written slowly, reviewed rarely, and automation lived in a separate silo.\n\nIt works less well now.\n\nAI can draft cases from screenshots and user stories in minutes. Automation lives next to application code. QA and dev share the same PRs. Auditors ask where test data lives and who changed what.\n\nIn that world, test cases are data — and the format you choose matters as much as the tool UI.\n\nThe durable direction is **tests as code**: plain YAML files in version control, with a thin local layer for humans to browse, run, and review. Not because databases are evil, but because git + YAML matches how we already work with code, AI, and compliance.\n\nLLMs are unusually good at structured text: YAML front matter plus a Markdown body is a sweet spot. Give the model a schema (`title`\n\n, `tags`\n\n, `priority`\n\n, steps, expected result) and a screenshot or user story, and you get a draft case in one pass.\n\nThat matters for more than speed:\n\nThe deeper point is **data ownership**. Cases in a vendor DB are convenient until they are not: export limits, API friction, another system to secure, another place sensitive scenarios live. Local YAML in your repo is trivial for AI to read (including Cursor, Copilot, or whatever you use next), diff, and update — without shipping your test catalog to a third party. For many teams, that is a real security and efficiency win — not ideology.\n\nWhen manual cases and automated tests sit in the same repository, a few things become boring in a good way:\n\n`automated: true`\n\nand point `params`\n\nat a Playwright or Selenium path — one file, one id.Example — a manual case linked to a Playwright spec:\n\n```\n---\ntitle: Login with valid credentials\ntags: [smoke, auth, playwright]\nautomated: true\nparams:\n  playwright: tests/auth/login.spec.ts\n---\n\n## Steps\n1. Open the login page\n2. Enter valid credentials\n\n## Expected result\nUser is redirected to the dashboard.\n```\n\nThe case filename is the case id. Tags and params give automation a handle without a separate traceability spreadsheet.\n\nWhen AI generates cases at volume, **git diff is the review UI**. You see exactly what changed: new case, edited steps, tag added, `automated`\n\nflipped. PR review works the same as for application code.\n\nTest runs can be YAML too — one file per run, case paths and results inline — so run history is also versioned.\n\nGit's time machine means you can see what you tested three years ago, not what a database happened to retain after a migration.\n\nFor QA leads, that is the difference between \"we changed the suite\" and \"here is the diff.\"\n\nYAML on disk fits a lot of compliance expectations without extra product features:\n\nA database can be compliant. So can files. The difference is whether compliance is bolted on or native to how the artifact is stored.\n\nThe honest drawback: YAML is code. It is precise and diff-friendly; it is not fun to click through for a full-day test run.\n\nThat gap is real. It is also why file-based test management tends to ship a **local UI** that reads and writes the same YAML files on disk. The goal is not \"no database anywhere\" — it is **no hosted database as the system of record**. A desktop client may keep a derived SQLite index or shadow clone under local app data for fast search and navigation; that cache is rebuildable from the files and never replaces what is committed in git. A VS Code extension can go further and touch only the workspace files — no separate index at all. Browse suites, edit cases, execute runs; YAML in the repo stays the source of truth.\n\nThe workflow that tends to work:\n\nYAML holds the source of truth; the renderer is the lens. Tests as code with a usable surface — not a replacement for thinking about structure.\n\nI am claiming that if you want AI-assisted authoring, shared repos with automation, PR-based review, and strong auditability, file-based YAML cases age better than another hosted test database.\n\nIf you want to see this workflow in practice:\n\n`.gitoza-lite/test/cases/`\n\nand runs under `.gitoza-lite/test/run/`\n\n.Lite works directly on workspace YAML with no local index. Gitoza Desktop adds sync, dashboards, and a derived SQLite cache under `~/.gitoza/`\n\n— still rebuilt from the same files on disk. Both treat YAML in git as the source of truth.", "url": "https://wpnews.pro/news/why-manual-test-cases-should-live-in-yaml", "canonical_source": "https://dev.to/gitoza-labs/why-manual-test-cases-should-live-in-yaml-223k", "published_at": "2026-06-30 18:34:39+00:00", "updated_at": "2026-06-30 18:48:51.057175+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "large-language-models", "ai-agents"], "entities": ["YAML", "Playwright", "Selenium", "Cursor", "Copilot", "Git", "VS Code", "SQLite"], "alternates": {"html": "https://wpnews.pro/news/why-manual-test-cases-should-live-in-yaml", "markdown": "https://wpnews.pro/news/why-manual-test-cases-should-live-in-yaml.md", "text": "https://wpnews.pro/news/why-manual-test-cases-should-live-in-yaml.txt", "jsonld": "https://wpnews.pro/news/why-manual-test-cases-should-live-in-yaml.jsonld"}}