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
Top comments (0)