u/Alternative-Try7044 — reddlx

People asked how I link tests to tickets — I just put both in the repo as files

A lot of the comments on my post Managing test cases as YAML files inside Git were about traceability. fair. “Test cases in YAML is cute, but how do you link them to tickets?”

So I decided to put the tickets in the repo as YAML too — and it works great for me. I’ve been working on an app called Gitoza anyway: a desktop tool to manage test cases and test runs as YAML, and use git to sync with the team. Adding tickets the same way was the natural next step.

Same idea as test cases: plain files in git. Tickets, releases, test cases, test runs — all local. Once they’re files next to each other, linking feels like jumping between notes in Obsidian. No export dance, no three SaaS tabs hoping the IDs match.

That’s what Gitoza is for: browse and edit locally on that YAML-in-git layout. I use it across a Mac mini and a Windows laptop.

It’s a local desktop app, same idea as Obsidian: your data is files on disk, not a hosted SaaS. Free for personal use; if a company wants to use it, there’d be a commercial license. No lock-in either way — everything is still just YAML in git.

Curious what people think — would tickets next to test cases in the repo work for you, or is that a hard no?

https://gitoza.com

u/Alternative-Try7044 — 9 days ago

▲ 0 r/QualityAssurance

Could storing test cases in Git solve the test run snapshot problem?

Following up on my last post about keeping test cases as YAML in Git. one huge benefit of this setup is how cleanly it handles historical test runs.

If test cases live in Git, a test run just stores the file path and the exact Git commit SHA.

Pair that with a nice UI that handles the Git stuff under the hood, and you get 100% immutable runs out of the box. Even if a case gets renamed or deleted, past execution logs stay completely untouched. Plus, you get diffs and full version history for free without needing any custom snapshot logic.

What do you think? Any hidden bottlenecks with this approach?

reddit.com

u/Alternative-Try7044 — 17 days ago

▲ 3 r/tauri

What do you use for manual test cases on side projects? Built a local-first Tauri app for it

Curious what other people do for manual test cases on their own projects.

Do you write them at all, or only keep automation? Browser TMS UIs are slow, and they're awkward to use with Cursor/Copilot — you can't just let the agent draft or edit cases in-repo.

I built a desktop app with Tauri + Rust instead:

- cases and runs are YAML in your Git repo

- sync across machines/teams via Git, no account

- SQLite index so search stays fast with large suites

- personal use free, no ads, no feature locks

Happy to answer questions about the Tauri rust side too.

Download: https://gitoza.com

u/Alternative-Try7044 — 24 days ago

▲ 2 r/QualityAssurance

Managing test cases as YAML files inside Git — a good idea?”

I’ve been trying out managing test cases as plain YAML files right inside our Git repos.

The whole point is treating manual tests just like code. Everything is local-first so there’s no web vendor lock-in, and team collaboration happens smoothly by pushing updates to dedicated test branches instead of messing with heavy third-party syncs. Also, since it's all plain text, using Cursor or other AI tools to write, search, and clean up test cases turns out to be super handy.

Anyone else tried keeping QA cases in Git like this?

Just to clarify based on the comments—I totally agree that reading raw YAML isn't the goal. What makes this setup actually usable is a lightweight local UI to render, edit, and execute cases cleanly (so it feels like a real test management tool), while keeping everything Git-native under the hood.

reddit.com

u/Alternative-Try7044 — 29 days ago