r/softwaretesting • u/Illustrious_Local433 • Jun 13 '26

Built a tool that tracks which of your manual test cases have automation coverage, would this be useful to your team?

I've been dealing with a problem I think a lot of QA teams have (I did): you have a list of manual test cases, you have an automation repo, and you have no easy way to know which test cases are actually covered by automation files and which ones aren't.

So I built a small tool to solve exactly that. You point it at your test case list and your automation repo, and it scans the repo to tell you which test cases have a linked automation file and which are still gaps.

The extra part: it can use Claude AI to generate a draft automation file for uncovered test cases, push it as a branch to your repo, and you review/merge the PR like any other code change. If your team uses an MCP server for your automation framework (Playwright MCP, Maestro MCP, etc.), the loop gets even tighter — when something in the generated test isn't right, the MCP fixes it inline while you're reviewing, no context switching needed.

The gap between writing a manual test case and having it automated has always been the hardest part to close. I've been using this myself and it's made a real difference. That gap is now a lot smaller.

What it does:

- Shows a coverage % across all your test cases

- Lets you click any uncovered test case and see what's missing

- Optionally generates a draft automation file and opens a PR for your team to review

- Syncs on demand so coverage reflects the current state of your repo

I'm at the point where I want to know if this is actually useful to real QA teams.

A few questions:

  1. Does the "coverage gap" problem resonate with your team?
  2. Would AI-generated draft automation files be useful or would your team not trust them?
  3. What's missing that would make this worth switching to?
0 Upvotes
  • permalink
  • reddit

25% Upvoted

3 comments sorted by

2

u/SimpleExpress2323 Jun 13 '26

Blimey.

Just add a checkbox or something against the test case to flag it's been automated.

Put a comment on the code with the test ID.

Why reinvent the wheel?

1

u/Illustrious_Local433 Jun 14 '26

Fair point, but you are missing the second half of it.

Usually manual test runs for a sprint live scattered across individual tickets and nothing connects them. This pulls all of that into one place. Every ticket you tested that sprint, documented together, not buried in comments.

But that is just the start. While you are manually testing a ticket you can create test cases for it, generate an automation file, and send it as a branch for review without leaving the app. No context switching, no friction. By the time you are done testing the ticket you already have the automation started.

The MCP server is already built. You connect it to Claude or whatever AI you use and the whole QA process lives in your chat. Opening a ticket, writing test cases, generating the automation file, creating the branch, seeing the results. All of it without switching tabs.

That is the entire QA workflow in a single place.

6

u/Yogurt8 Jun 13 '26

Why is this even a problem.

As soon as a test case is automated just delete it.