Test Cases That Link Themselves

Most QA teams keep two lists.

One is the list of things worth testing: the test cases, living in a tracker or, more honestly, a spreadsheet. The other is the list of tests that exist: Playwright specs in git. The two lists drift apart the day after you set them up, because keeping them aligned is a manual sync job nobody owns. Coverage reviews turn into archaeology.

The fix is not a better spreadsheet. The fix is deleting the sync job.

The model

Donobu already organizes execution: suites group tests, and tests produce runs. The new Test Cases layer, now in beta, sits above both. It is the inventory of testable product behaviors. The denominator of your coverage.

Each case carries a readable ID, a title, a markdown description, a module, a priority from low to critical, and an external ID if you are migrating from an existing tracker.

The mechanic: the ID is a tag

Here is the part that removes the sync job. A test case's ID doubles as a Playwright tag.

Create a case with the ID checkout-guest. Tag any test @checkout-guest, the way you already tag tests today. They link automatically on the next sync. No import wizard, no browser extension, no "remember to update the tracker after you merge."

• Auto links exist as long as the tag matches. Rename a case's ID and its tag links re-point at the next sync.
• Manual links cover one-off connections you want to make by hand, and each link is labeled with how it was made.
• Every linked test shows its recent pass rate over the last 14 days, so a case answers "is this behavior protected, and is the protection working?" at a glance.
• Connect Linear or Jira, and known bugs link to the case for the behavior they break, so the ticket and the coverage live side by side.

Automate a case with your coding agent

A case nobody automates is still just a row in a list. So every case page hands you a prompt written for that case, ready to paste into the coding agent you already use. The agent reads the case, writes the Donobu test for it, runs it, and tells you what happened. You review a pull request instead of writing a spec from scratch.

• Run npx donobu skills install once in your test repo, so your agent knows Donobu.
• Copy the prompt from the case page and paste it into your agent.
• The spec it writes carries the case ID as a tag, so the link makes itself.

Coverage becomes a query

Once cases and tests link themselves, questions that used to be quarterly audits become filters:

• Which critical cases have no linked test?
• Which module's cases fail the most?
• What did we ship last sprint that has no case at all?

Search across IDs, titles, and descriptions. Filter by module and priority. Select a batch of cases and edit or delete them together. The tracker stops being a document you maintain and becomes a view derived from the suite you already run.

In beta now

Test Cases is rolling out in beta on team accounts, alongside the new dashboard and Test Runs views. If you want your two lists to become one, book a walkthrough and we will set it up with your suite.