Private beta · Hosted · Jira optional

Modern test case management

generic test case manager keeps your test cases and the results of every run, whether it came from CI or from a tester working through the steps by hand. It works on its own or connected to Jira.

In a private beta. It doesn't need Jira.

Runners we have examples for, with the JUnit reporter each one needs

Automated results from CI

Point the reporter at your JUnit file. Each test becomes an execution with a status, the failure output and a duration. Tests are matched to cases by classname::name. A test with no match gets a new test case in Draft status with the automated label, which is how most teams end up with their automated suite catalogued without typing anything in.

Manual runs with per-step results

Test cases have steps with expected results. A tester marks each step Pass, Fail or Blocked. Any failed step fails the run. If none failed but one is blocked, the run is blocked. Once every step has passed, the run passes, and the record shows who ran it and when.

Flaky test list

A test's flakiness score is the number of result changes between consecutive runs divided by the total runs, and the overview page lists the highest scores. There's no time window yet. The score covers every recorded run, so a test that was fixed months ago can still rank until enough new runs dilute it.

Jira integration

Test cases, cycles and executions as Jira Cloud issues

Connect generic test case manager to Jira Cloud and each of those becomes a custom issue type in your project. Stories link to the test cases that cover them, and failed executions link to the bugs they produced. Jira's own workflows and permissions apply, because they're Jira issues.

It also works on its own, with no Jira at all; then the test data stays in generic test case manager. The web app and the reporters are the same either way.

  • Provisioning creates three issue types and four link types, and skips any that already exist.
  • Jira Cloud only. Data Center isn't supported.

CI integration

Send a JUnit file after your tests

Any runner that writes JUnit XML works: Vitest, Playwright, Jest, pytest, Go, Gradle, Maven and .NET. Your CI posts the file with curl and a report-only API key, along with the branch, commit and job URL. generic test case manager's own CI reports into a generic test case manager instance.

  • Each cycle name makes one cycle, so main #4812 gives you one per build, finished as soon as its results are in.
  • Test cases are created the first time a test reports, and later runs add to their history.
  • Sending a test to the same cycle again, as when a job is retried, replaces its result instead of adding a second one.
  • A project key that doesn't exist is refused, so a typo can't start a new project.
# any runner
$ npx playwright test
$ curl -sS $GTCM_URL/api/v1/test-executions/junit \
    -H "X-Gtcm-Key: $GTCM_API_TOKEN" \
    -F file=@test-results/junit.xml \
    -F project_key=NAS -F "cycle=main #4812"
{"cycle_key":"NAS-231","executions_created":212,"cases_created":3,"errors":[]}

Import

Import test cases from a spreadsheet, an export or a document

Export from your current tool and upload the file. A language model (Claude Sonnet by default, configurable) proposes which columns or sections hold what. You see the mapping and a preview of the first cases before anything is written to your project. Original IDs are kept as labels, and uploading the same export again won't create a second copy. The file's contents are sent to the model provider through Vercel AI Gateway, so don't upload an export you can't share with it.

What the importer does with each file type
FileHow it's read
CSV, XLSXColumns are mapped to fields. Handles one row per case, or one row per step with the case repeated. The mapping is editable before import.
XML, JSONExports from other test tools. The model identifies the structure and a deterministic parser does the import, so the model can't invent cases.
Word, PDF, textTest plans written as prose. Here the model does extract the cases and steps itself. You review each one before it's saved.

MCP server

generic test case manager includes an MCP server for Claude Code and other agents. Its tools search cases, read cycle summaries and the flaky list, and create or update cases and executions. It talks to the API with the same keys and scopes a person would use, so a read-only key makes it a read-only agent.

Join the private beta

generic test case manager is in a private beta and accounts are by invitation. Tell us who you are and what you test, and we'll get back to you.

We use these details only to reply about the beta. Privacy notice