DEV Community: Weiwen Weng

Why YAML Tickets Beat Jira MCP for AI IDEs Like Cursor

Weiwen Weng — Mon, 10 Aug 2026 15:14:29 +0000

Your AI IDE already reads the repo. If tickets are plain-text YAML next to the code, the agent can search the backlog the same way it reads a module — no MCP, no JQL translator, no cloud hop for every ask.

MCP into Jira is the bolt-on path. At a few thousand tickets — or around 10,000 — the gap shows up in latency, hit rate, and junk in the context window.

Native path: tickets as YAML

.gitoza/tasks/tickets/{project}/{ticket-id}.yaml

The ticket id is the filename (without .yaml). With stable keys (status, assignee, priority, type), an agent can answer:

Open bugs in auth assigned to me
What is still open on this release?
Which tickets mention the checkout API?

Retrieval is local — IDE index, grep, or a SQLite-backed app index. You only pay network time for the model, not for fetching every ticket over REST.

Minimal example (AUTH-102.yaml):

---
title: Lockout after failed logins
priority: medium
status: open
type: bug
---

# Lockout after failed logins

## Description

Brief context for the agent and the team.

Point the agent at .gitoza/tasks/tickets/ and ask. Same loop as code review.

Same ask over Jira MCP

Useful when Atlassian must stay the system of record. For day-to-day agent work it adds a chain on every answer: natural language → tool call → JQL → REST → JSON → maybe another call if the first page was wrong.

Fine for one known issue key. Heavy for wide or multi-step backlog questions.

Speed, precision, cost

	YAML in the repo	Jira over MCP
AI access	Native (files the IDE already sees)	Tools + network
Latency	Disk / local index	Network + JQL + paging
Narrow asks	High when keys are consistent	Depends on JQL
Tokens	Ticket text you chose	Schemas + JSON bloat
Quotas	None for local reads	Cloud / MCP caps
Offline	Works	Needs the cloud

Precision caveat: “summarize all 10k tickets” still will not fit one context window. Filter first, then summarize — locally that is search/grep, not “hope the JQL was right.”

Cost direction: local plain text is cheaper per useful answer than tool-shaped round trips. Many checks never need an LLM — a terminal search is enough.

Skip the bridge

If the team already works in an AI IDE, put the backlog where the agent already looks: the repo. Files need no tool schema, no JQL translation, and no second system for “what is open this sprint.”

MCP is a workaround for a backlog trapped in a vendor API. YAML tickets remove that trap — Git is the data plane.

Try it

Gitoza keeps tickets under .gitoza/tasks/tickets/{project}/ (releases beside them; tests under .gitoza/test/ if you want coverage next to the work). Browse in the desktop UI, or open the YAML in Cursor / VS Code and ask.

Manage Tickets in Git as YAML — No Login, No Jira MCP, Works Offline

Weiwen Weng — Sat, 08 Aug 2026 07:46:09 +0000

Driving tickets through MCP into Jira sounds neat until auth, scopes, rate limits, and field mappings eat the day. The IDE still cannot see the backlog unless that glue is perfect.

There is a simpler pattern — closer to Obsidian than to another SaaS hop: keep tickets as YAML files in the repo, then link them locally. No login. No vendor API for every lookup.

Tickets as files

Put tickets under something like:

.gitoza/tasks/tickets/{project}/{ticket-id}.yaml

Releases under .gitoza/tasks/releases/. Links are just paths and IDs:

Ticket ↔ ticket (parent/child, [[TICKET-ID]])
Ticket ↔ release
Ticket ↔ test case in .gitoza/test/cases/

Open the file, follow the link, done. Structured enough for search and agents — not another cloud board.

Why this wins

Offline by default. Source of truth is on disk. Searching a release or following a link does not wait on VPN or a flaky API. Sync to a remote when you want to share; editing does not require that round-trip.

AI already speaks files. Agents in Cursor / VS Code read YAML well. Ask what is open this sprint, which tickets lack cases, what sits on a release — without standing up MCP to a tracker first. Prefer a local model? Same repo, same folders, no ticket payload leaving your machine for a hosted “AI” bolted onto a SaaS board.

One tree for planning and tests (optional):

Area	Path
Tickets	`.gitoza/tasks/tickets/`
Releases	`.gitoza/tasks/releases/`
Cases / runs	`.gitoza/test/`

Try it

Gitoza is built around that layout — browse in Tickets / Releases views, or open the YAML in the IDE.

Download, connect a repo (or Playground).
Add YAML tickets, link a release.
Point your IDE agent at .gitoza/tasks/ and ask something you would have sent through MCP to Jira.

That is the pitch: tickets as files, Obsidian-style links, local speed, AI without a brittle cloud bridge — and no login to start.

YAML Test Cases in Git: What r/QualityAssurance Actually Said

Weiwen Weng — Sun, 02 Aug 2026 16:10:08 +0000

I asked r/QualityAssurance a blunt question: is managing manual test cases as YAML files inside Git a good idea?

The thread got lively. People were not hostile to the idea. Many were already sympathetic to tests as code, a dedicated branch, AI helpers that can actually read the catalog. The pushback was more interesting than the praise. It lined up with problems I had hit building the same workflow for real teams.

Where the room agreed

When you frame cases as plain text in a repo you control, the reaction is usually positive:

No vendor database as the system of record
Diffs and history that look like application code
Collaboration through Git instead of another sync product
AI tools (Cursor, Copilot, and the rest) that already live in the IDE

That part is not controversial anymore. Engineers have watched automation live in Git for years. Manual cases still often sit in a SaaS form or a spreadsheet. Closing that gap feels overdue.

Where people who tried it got burned

Agreement on the idea is not the same as a durable practice.

Commenters who had lived with XML dumps, folder trees, or home-grown markdown catalogs were blunt: without tooling, the suite becomes hard to browse, easy to break, and painful to keep alive. Raw files scale poorly for day-to-day authoring. Someone always ends up maintaining a fragile convention that nobody else wants to touch.

Others were clear they would stay on web tools like Xray (and the Jira orbit around them). Not because YAML is wrong — because managers get dashboards, links, and process they already trust. "Files in Git" sounds like an engineer hobby until it feels like a product.

And then the traceability question: how do you keep cases tied to user stories and bug tickets when you leave the vendor UI? Without a stable id story, file-based QA looks incomplete next to a TMS that speaks Jira natively.

Those are fair objections. Ignoring them is how "test cases in Git" dies after a pilot.

The missing piece was never Git — it was the UI

Plenty of teams have tried putting cases in the repo. Almost nobody ships a local UI that renders and manages those files the way a TMS renders rows in a database.

That gap is the whole story.

Reading YAML in a text editor is not a test management workflow. Browsing suites, editing steps, recording Pass / Fail / Skip, and seeing automation coverage — that is. Once you have a client that treats the files as the source of truth, the day-to-day experience stops being "weird Git experiment" and starts looking like the web tools people already know. In practice, stability and feature coverage land in the same ballpark. Latency often wins: everything is on disk. There is no round trip to a hosted API every time you open a case.

Runs that do not rewrite history when cases change

File-based catalogs usually fail at execution history.

You create a run, add cases, execute. Two weeks later someone edits step 3 on a case that was already in that run. If the run only stores a live path, yesterday's sign-off silently becomes today's wording. Auditors hate that. So do release leads.

Git already has the answer if you use it deliberately. When Gitoza adds cases to a run, it records:

the case path in the repository
the commit SHA at the moment the case was picked (picked_at_sha)

Results attach to that membership. Later edits to the live case file do not rewrite what was executed. You can still open the catalog at HEAD for new work; historical runs resolve content against the SHA they were pinned to. Versioning is not a separate "export a PDF" step — it is how the run is stored.

That is the difference between "we keep YAML in Git" and "runs are evidence."

Traceability without living inside Jira

Vendor TMS tools win on links: story → cases → bugs. File-based setups need the same discipline, just as fields.

In Gitoza case YAML, that usually means:

requirement_id for the user story or requirement key
tags for product area / smoke / risk
optional custom keys under params (for example jira_key) when your tracker needs a second handle
for automation, the case filename as the id, mirrored as a tag on Playwright or Robot specs — see linking manual and automated cases

You do not get magic bi-directional sync with Jira out of a text file. You get stable ids you can filter, export, and review in a PR — and you keep the catalog next to the code those stories shipped.

Managers and testers need different surfaces — same data

This is the split the Reddit thread kept circling.

QA managers lean on Xray, Jira, and similar products because reporting and process live there. That convenience is real.

Testers who write cases all day pay for it in browser forms, slow saves, and UIs that were never designed for long-form authoring. Asking a tester to draft dozens of careful cases in a web TMS is a bit like asking a programmer to write production code in a ticket comment box. Possible. Not the job you want.

Gitoza's bet is simple: keep the data plane in Git (YAML cases and runs you own), and give testers an IDE-shaped client — browse, edit, run, sync — while managers still get review, dashboards, and history without renting the catalog to a vendor database.

If your org will never leave Jira Test Management, stay there. If your pain is authoring speed, ownership, AI access, and audit trails that look like commits, file-based cases with a real UI are no longer a science project.

Try it, poke holes in it

The Desktop app and the VS Code extension are free to start; there is no lock-in beyond files in your own repo. Install Lite from the Marketplace, open a workspace, create a project under .gitoza-lite/test/cases/, and see whether the workflow holds up on a real suite.

Link Manual Test Cases to Playwright and Robot Specs

Weiwen Weng — Wed, 22 Jul 2026 15:44:09 +0000

Most teams already keep Playwright or Robot Framework specs next to the product. Manual cases often live somewhere else — a spreadsheet, a cloud TMS, or a wiki page nobody updates after the first release.

That is why automation coverage is usually a quarterly guess: the catalog and the specs never share an id.

Put both in the same Git repo, give every manual case a stable id, and linking becomes a text match. Any IDE agent can do that if the cases are files it can already see — no custom AI product inside a test tool.

One repo, two layers of the same suite

Manual cases are YAML files under .gitoza-lite/test/cases/ (VS Code / Cursor extension) or .gitoza/test/cases/ (Desktop app). The filename without .yaml is the case id.
Automated tests live wherever your team already puts them — tests/, e2e/, robot/ — in the same repository.
Traceability is a shared id: put that case id on the automation side as a tag (or name), and on the YAML side as automated: true plus a params pointer.

A PR can change the case, the Playwright spec, and the link in one review.

Step 1 — Draft manual cases in the IDE

Open the repo in Cursor or VS Code. Point the agent at a few existing case files so it learns your title style, tags, and step length. Then feed it a user story, a ticket, or a screenshot.

Ask for several cases at once, not one shallow step. A useful prompt looks like:

Read .gitoza-lite/test/cases/shopflow/auth/ for format. From ticket SHOP-184, draft three YAML cases (happy path, invalid password, locked account). Filename = case id. Use tags auth and smoke where it fits.

Save the files under the suite folder. Then open the Gitoza Lite Test Repository tab to browse, edit, and — when you are ready — run them as a manual suite with Pass / Fail / Skip.

The extension does not ship its own model. It keeps cases as plain YAML so whatever assistant you already use can read and write them.

A minimal case:

---
title: Login with valid credentials
priority: high
tags: [smoke, auth]
status: active
---

## Steps
1. Open the login page
2. Enter valid credentials

## Expected result
User is redirected to the dashboard.

If the file is AUTH-001.yaml, the case id is AUTH-001. That string is the join key for everything below.

Step 2 — Put the case id on the automation side

Before coverage can be marked, automation needs a handle that matches the YAML filename.

Playwright — tags must start with @ (or include the id in the test title):

import { test, expect } from "@playwright/test";

test("login with valid credentials", {
  tag: ["@AUTH-001", "@smoke"],
}, async ({ page }) => {
  // ...
});

Robot Framework — use [Tags]:

*** Test Cases ***
Login With Valid Credentials
    [Tags]    AUTH-001    smoke
    Open Login Page
    Submit Valid Credentials
    Dashboard Should Be Visible

Same idea for other runners: one stable token that equals the case id. Prefer the id over a free-text title match — titles drift; filenames should not. When matching Playwright tags to YAML, strip the leading @ so @AUTH-001 maps to AUTH-001.yaml.

Step 3 — Flip `automated` and fill `params`

Once specs carry the case id, close the loop on the YAML side — with Cursor or a small script:

Scan tests/ for Playwright tags matching case ids under .gitoza-lite/test/cases/. For each hit, set automated: true on the YAML case and add params.playwright with the relative spec path. If a case id appears in tags but not in YAML, list the gaps. Do not set automated: true unless the tag and filename match after stripping @.

You end up with something like:

---
title: Login with valid credentials
tags: [smoke, auth]
automated: true
params:
  playwright: tests/auth/login.spec.ts
---

## Steps
1. Open the login page
2. Enter valid credentials

## Expected result
User is redirected to the dashboard.

For Robot, the same field under params might be robot: tests/auth/login.robot. Teams often add a custom key as well — auto_tag: AUTH-001 or suite: 01_user_authentication — so filters and scripts stay boring. params is a free key-value map; agree on a small schema in the repo README and stick to it.

automated: true is the coverage flag. params is the pointer. Tags on the YAML side stay useful for smoke, priority, and feature filters — they do not have to duplicate the automation path.

Treat agent output like any other PR: review git diff before merge. A wrong tag match that flips automated: true is worse than a missing link — catch it in review, or run the same rules in CI so chat is optional.

Why Git beats a TMS link field

In a vendor database, linking is usually a URL paste or a fragile title search. Agents cannot see the catalog unless you build API glue.

In Git, the agent (or a script) reads cases and specs in one workspace, and git diff shows exactly which cases flipped to automated. Coverage is "scan tags ↔ case ids," not "update the spreadsheet after the sprint."

A concrete loop

Feature lands on a branch.
Agent drafts or updates manual YAML under .gitoza-lite/test/cases/…/{CASE-ID}.yaml.
Automation engineer (or the same agent) implements Playwright / Robot and tags the test with {CASE-ID}.
Agent or script sets automated: true and params on the matching case.
Manual testers execute what is still unautomated; Desktop dashboards can show automation rate when you use the full app.

Start with one suite. Do not try to backfill five years of TestRail in a weekend. Ship the next feature with case + spec + link in the same PR.

Try it (free VS Code extension): Gitoza on Marketplace
Full post: gitoza.com/blog/ai-link-manual-automated-test-cases

Stop Using Raw WebDriver in Robot Framework

Weiwen Weng — Thu, 09 Jul 2026 18:14:55 +0000

A lot of Robot Framework projects still look like plain Selenium scripts with .robot file extensions.

Someone imports webdriver, creates driver = webdriver.Chrome(), then calls find_element and send_keys in Python helpers. Robot Framework runs the suite, but readable keywords, shared libraries, and consistent waits never show up in the tests.

If you already use Robot Framework with SeleniumLibrary, you do not need the raw WebDriver API. SeleniumLibrary gives you high-level keywords. The Page Object Model gives you structure. Together they keep tests short and UI changes localized.

We published a small MIT template that shows the layout: rf-seleniumlibrary-pageobject-template. It targets Sauce Demo — clone it, run four tests, fork the folder structure.

What breaks when you mix in raw WebDriver

driver = webdriver.Chrome()
driver.find_element(By.ID, "user-name").send_keys("standard_user")
driver.find_element(By.ID, "password").send_keys("secret_sauce")
driver.find_element(By.ID, "login-button").click()

Fine for a script. Painful in a growing suite.

Locators spread across helpers and test files. Waits become time.sleep(2) in one place and missing in another. You end up maintaining SeleniumLibrary and a parallel WebDriver stack. CI fails on a Tuesday night and you are not sure which path opened the browser.

Before and after

Before	After
`driver.find_element(...).send_keys(...)`	`Login With Valid Credentials ${VALID_USER} ${VALID_PASSWORD}`
Locators in every file	`LoginLocators.USERNAME` in one module
Ad-hoc sleeps	`wait_until_element_is_visible` in `BasePage.click()`
Two browser stacks	One `SeleniumLibrary` instance per suite

Four layers

Layer	Job	Example
Locators	Selectors per screen	`login_locators.py`
BasePage	Shared waits and actions	`click()`, `enter_text()`
Page library	Screen keywords	`LoginPage.login()`
Robot test	Scenario only	`Inventory Should Be Visible`

Folder layout in the repo:

resources/locators/   → selectors
pages/                → Python page libraries
tests/                → thin .robot files

Locators stay in one place

class LoginLocators:
    USERNAME = "id:user-name"
    PASSWORD = "id:password"
    SUBMIT = "id:login-button"

Prefer stable attributes like data-test when the app exposes them.

BasePage owns the waits

def click(self, locator):
    self.seleniumlib.wait_until_element_is_visible(locator)
    self.seleniumlib.click_element(locator)

@property
def seleniumlib(self):
    return BuiltIn().get_library_instance("SeleniumLibrary")

Import SeleniumLibrary once in common.resource. Page objects look up that same instance — no driver argument passed between keywords. If you create driver = webdriver.Chrome() outside SeleniumLibrary, your page keywords will not see that browser.

A thin test

*** Test Cases ***
Valid Login
    Login With Valid Credentials    ${VALID_USER}    ${VALID_PASSWORD}
    Inventory Should Be Visible

No locators. No driver setup. Browser open/close in Test Setup / Test Teardown.

Quick start

git clone https://github.com/gitoza-io/rf-seleniumlibrary-pageobject-template.git
cd rf-seleniumlibrary-pageobject-template
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
robot --pythonpath . --outputdir results tests/

Use --pythonpath . from the repo root so pages.* imports resolve. Four passing tests = layout is wired.

Migrating without a rewrite

Move locators to resources/locators/
Add BasePage with click / enter_text
Wrap login as the first page library
Import SeleniumLibrary once in common.resource
Rewrite one .robot file, delete webdriver imports from its helpers

Repeat screen by screen. Leave the rest alone until you touch that feature.

Playwright and Cypress are valid for greenfield work. Plenty of teams still run RF and SeleniumLibrary in production — for them, dropping find_element for Page Objects is a low-risk upgrade that pays off on the next UI refactor.

Full guide: gitoza.com/blog/robot-framework-seleniumlibrary-page-object-model

Template repo: github.com/gitoza-io/rf-seleniumlibrary-pageobject-template

When Excel Stops Working for Test Case Management

Weiwen Weng — Sun, 05 Jul 2026 13:45:31 +0000

Most teams start with an Excel sheet. One tab per feature, columns for steps and expected results, maybe a status column someone colors green by hand. It is cheap, familiar, and fine for ten cases.

Then the product grows. The sheet does not.

Where the sheet starts to hurt

Excel stores text, not test runs. It does not know what "Pass" means in your release process, who executed a case yesterday, or which build you tested. Run history ends up in another tab, another file, or someone's memory.

File names tell the rest of the story. test-cases-v3-FINAL.xlsx becomes v3-FINAL-John-edits.xlsx on a shared drive. Two people update the same row. Someone sorts a column and IDs no longer match the bug tracker. There is no diff, no reviewer, no clear answer to "who changed step 4 before we shipped."

Meanwhile your app, automated tests, and CI live in Git. Manual cases sit in a file that never rides along with your repo history. When a feature changes, the sheet is usually one sync meeting behind.

Spreadsheets are fine for a one-off checklist. They are a poor system of record once QA is ongoing.

Cases as files in the repo you already have

The usual upgrade path is a cloud TMS. That solves collaboration, but your catalog moves into someone else's database — another login, another export, another place sensitive scenarios live.

A lighter step for many teams is test cases as files in a repository you already control. Each case is a small YAML file: metadata up top, steps and expected results in Markdown below. Git gives you history and review without a separate process. A thin editor on top lets you browse suites, edit cases, and record runs — pass/fail and notes saved as structured files, not colored cells.

That is roughly how Gitoza works. You connect a repo (GitHub, GitLab, or any remote you already use), keep cases on a dedicated branch, and edit from VS Code or Cursor. Testers who do not live in the IDE can use the Desktop app for runs and dashboards. The VS Code extension is free for solo use and open-source projects.

What actually changes

Runs stop living in side tabs. You assign cases, record results, and the history stays next to the cases themselves — on the same branch, versioned with every sync.

When a feature ships, you can see case changes in git commits — who changed what, and when — instead of chasing the latest spreadsheet on a shared drive. Tags, priorities, and links to automation specs are easier to keep consistent when each case is a file, not row 427 in a sheet that someone sorted last Tuesday.

You do not need to rip out Excel tomorrow. If the sheet is fighting you on every release, moving cases into Git is often less painful than another "please use the latest file" email.

More on the file format: Why test cases belong in YAML.

Try it (free VS Code extension): Gitoza on Marketplace

Team / manual testers: Gitoza Desktop

Full post: gitoza.com/blog/excel-test-case-management-alternative

Test Management Compliance: Cloud SaaS vs Local-First

Weiwen Weng — Fri, 03 Jul 2026 16:03:51 +0000

Security sends a forty-question vendor questionnaire. Legal asks whether your test cases contain customer PII or staging screenshots. Procurement forwards next year's per-seat renewal.

The decision is not which UI looks best in a demo. It is whether you can keep sensitive test knowledge off a vendor's cloud — without staffing a server farm.

Test cases are not harmless notes. They hold user stories, credentials in steps, production-like screenshots, and run history. For finance, healthcare, or EU-facing teams, that is operational data — not "just QA."

Cloud SaaS vs local-first at a glance

Question	Cloud SaaS	Local-first (e.g. Gitoza)
Where is the canonical copy?	Vendor cloud DB	Your repo / your storage
Does test data cross vendor boundary?	Yes, by design	No vendor DB; sync via your Git remote or BYO S3
Audit trail	Vendor activity log	Git commit history (author, timestamp, diff)
Typical small-team cost model	Per-seat subscription (hosted data)	Lower per-seat subscription; no hosted TMS DB
Manual tester UX	Web UI	Desktop UI
Exit strategy	Export / API	Files already yours

Planning aid, not legal advice — your security team signs off.

Where cloud TMS friction starts

TestRail, Testmo, Qase, and similar tools store cases in a vendor-operated database. Rollout is fast. Manual testers get web forms without a terminal.

The compliance pitch is usually SOC 2, ISO 27001, and a DPA. That certifies the vendor's operation — not whether your test catalog belongs in their multi-tenant cloud.

Question 12 on a typical security questionnaire: Where is customer data processed? Your cases may include staging screenshots with real-looking records. Meanwhile your cases sit in a US region while your customers are in Frankfurt.

On audit trails: activity logs help, but the system of record is still editable rows. Proving "we tested exactly this before release 4.2" often means trusting vendor retention — not a history your org already controls.

Then there is seat math. Twenty testers at roughly $30–45 per seat per month adds up before renewals. Desktop tools like Gitoza also charge per seat — but you are not paying to host your test catalog in a vendor database.

What about on-prem?

Self-hosted TestRail Server or Jira + Xray behind the firewall can be right at enterprise scale. For a twenty-person QA org without a platform team, six figures all-in is not rare. Many regulated teams end up on cloud SaaS and hope the DPA holds.

Local-first in one paragraph

Local-first keeps the canonical copy in files you control — typically a Git repo — while a desktop app gives manual testers the UI they expect from SaaS.

No vendor database as system of record. You pay a per-seat license for the app — not a recurring fee to store your test catalog in a vendor cloud.

With Gitoza, cases live on a dedicated gitoza branch in a shadow clone; testers do not touch main. Git history is the audit log — every change is a commit with author, timestamp, and diff.

Checklist before you shortlist

Inventory — What sensitive data is in cases and runs today?
Residency — Where must it live? Can US-hosted SaaS meet your contracts?
Canonical copy — If you stop paying, what do you still own without an export project?
History integrity — Can an admin alter past results without a durable trail?
Seat math — Three-year cost at current headcount and +50% growth?
Manual tester path — Can non-engineers run tests without CLI or VPN?
Vendor count — How many new subprocessors does this tool add to annual review?
Migration — Realistic effort to move in and out in one release cycle?

If 2, 3, and 7 are red, cloud SaaS needs a harder look.

Before you pick the dashboard

A vendor's SOC 2 report describes how they run their platform. Your auditor will still ask where your case library lived when release 4.2 shipped — and whether anyone could rewrite that history without leaving a trace.

Those are different questions. Certified cloud TMS vendors serve plenty of regulated customers well. Local-first does not replace legal review or a signed DPA. It just moves custody: the canonical copy sits in your repo, not a vendor row you export at renewal time.

If custody matters in your industry — and for many QA teams it does — answer that on paper before the UI demo wins the room.

Try Gitoza: Desktop download · VS Code extension

Why Manual Test Cases Should Live in YAML

Weiwen Weng — Tue, 30 Jun 2026 18:34:39 +0000

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.

It works less well now.

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

In that world, test cases are data — and the format you choose matters as much as the tool UI.

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

1. AI is good at YAML — and YAML keeps your data yours

LLMs are unusually good at structured text: YAML front matter plus a Markdown body is a sweet spot. Give the model a schema (title, tags, priority, steps, expected result) and a screenshot or user story, and you get a draft case in one pass.

That matters for more than speed:

Boundary cases — ask the model what you might have missed; it can reason about the scenario, not just paraphrase the story.
Consistency — the same format every time makes batch generation and review predictable.

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

2. Manual YAML beside automation makes coverage measurable

When manual cases and automated tests sit in the same repository, a few things become boring in a good way:

Tag a case automated: true and point params at a Playwright or Selenium path — one file, one id.
Automation coverage is a script or an AI pass away: scan specs, match case ids or titles, flip flags, report gaps.
Automation rate stops being a quarterly spreadsheet exercise.

Example — a manual case linked to a Playwright spec:

---
title: Login with valid credentials
tags: [smoke, auth, playwright]
automated: true
params:
  playwright: tests/auth/login.spec.ts
---

## Steps
1. Open the login page
2. Enter valid credentials

## Expected result
User is redirected to the dashboard.

The case filename is the case id. Tags and params give automation a handle without a separate traceability spreadsheet.

3. Git diffs are a review surface, not a workaround

When AI generates cases at volume, git diff is the review UI. You see exactly what changed: new case, edited steps, tag added, automated flipped. PR review works the same as for application code.

Test runs can be YAML too — one file per run, case paths and results inline — so run history is also versioned.

Git's time machine means you can see what you tested three years ago, not what a database happened to retain after a migration.

For QA leads, that is the difference between "we changed the suite" and "here is the diff."

4. Local files, audit trails, and data sovereignty

YAML on disk fits a lot of compliance expectations without extra product features:

Offline / on-prem — no requirement to sync cases or runs to a vendor cloud.
Tamper evidence — commit hashes and (if you use them) GPG-signed commits attach authorship to changes; faking "we always had this test" is harder than editing a row with admin access in a hosted DB.
Data sovereignty — the canonical copy lives in your repo, branch, and backup policy.

A database can be compliant. So can files. The difference is whether compliance is bolted on or native to how the artifact is stored.

5. The UX problem — and why a local renderer matters

The honest drawback: YAML is code. It is precise and diff-friendly; it is not fun to click through for a full-day test run.

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

The workflow that tends to work:

Cases and test runs follow branches — QA reviews case changes in the PR like any other change.
Devs stay in the IDE — open a test repository view, skim cases next to the fix they are working on.
After a bugfix, assign a case to a tester in the same branch and ship case + fix in one PR.

YAML holds the source of truth; the renderer is the lens. Tests as code with a usable surface — not a replacement for thinking about structure.

What I am not claiming

YAML in git is not magic — you still need conventions, CODEOWNERS, and review discipline.
AI-generated cases still need human review — diff-friendly format just makes that cheaper.
This is not "dump TestRail tomorrow" for every org — migration cost and habit matter.

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

Try it

If you want to see this workflow in practice:

Gitoza — the full platform: desktop client, git sync, review workflows, automation pipelines, and dashboards for the whole team.
Gitoza Lite on GitHub — open-source VS Code extension; cases under .gitoza-lite/test/cases/ and runs under .gitoza-lite/test/run/.
Install from the VS Code Marketplace — open a repo, run Gitoza: Open Test Repository, create a project, commit the YAML.

Lite works directly on workspace YAML with no local index. Gitoza Desktop adds sync, dashboards, and a derived SQLite cache under ~/.gitoza/ — still rebuilt from the same files on disk. Both treat YAML in git as the source of truth.

DEV Community: Weiwen Weng

Why YAML Tickets Beat Jira MCP for AI IDEs Like Cursor

Native path: tickets as YAML

Same ask over Jira MCP

Speed, precision, cost

Skip the bridge

Try it

Manage Tickets in Git as YAML — No Login, No Jira MCP, Works Offline

Tickets as files

Why this wins

Try it

YAML Test Cases in Git: What r/QualityAssurance Actually Said

Where the room agreed

Where people who tried it got burned

The missing piece was never Git — it was the UI

Runs that do not rewrite history when cases change

Traceability without living inside Jira

Managers and testers need different surfaces — same data

Link Manual Test Cases to Playwright and Robot Specs

One repo, two layers of the same suite

Step 1 — Draft manual cases in the IDE

Step 2 — Put the case id on the automation side

Step 3 — Flip automated and fill params

Why Git beats a TMS link field

A concrete loop

Stop Using Raw WebDriver in Robot Framework

What breaks when you mix in raw WebDriver

Before and after

Four layers

Locators stay in one place

BasePage owns the waits

A thin test

Quick start

Migrating without a rewrite

When Excel Stops Working for Test Case Management

Where the sheet starts to hurt

Cases as files in the repo you already have

What actually changes

Test Management Compliance: Cloud SaaS vs Local-First

Cloud SaaS vs local-first at a glance

Where cloud TMS friction starts

What about on-prem?

Local-first in one paragraph

Checklist before you shortlist

Before you pick the dashboard

Why Manual Test Cases Should Live in YAML

1. AI is good at YAML — and YAML keeps your data yours

2. Manual YAML beside automation makes coverage measurable

3. Git diffs are a review surface, not a workaround

4. Local files, audit trails, and data sovereignty

5. The UX problem — and why a local renderer matters

What I am not claiming

Try it

Step 3 — Flip `automated` and fill `params`