What is a test management tool?
A test management tool is the system of record for everything a QA team knows about testing: the test cases themselves, the runs those cases go into, the results that come back, and the link from all of that to the features and issues being shipped.
The category has a working definition that buyers and analysts agree on. Four criteria decide whether a tool qualifies:
Repository-like structure
Stores and organizes test assets in a repository-like structure.
Multiple test types
Supports more than one type of testing.
Reports and metrics
Produces reports and metrics on quality.
Integrations with development platforms
Integrates with the development platforms where the code actually lives.
M00N Report is an AI-native test management platform. Author test cases, run manual executions, track releases, stream automated results, and let AI agents manage everything over MCP.
It meets all four of those requirements. The four sections after the next one state exactly how, one criterion at a time, without hedging.
Four generations of test management
The way we see it, the category has moved through four generations. Knowing which one a tool belongs to explains most of its behaviour.
- First generation - spreadsheets and Confluence pages. Free, universally understood, and completely unable to tell you anything about last night’s run.
- Second generation - the manual-first standalone TMS. Tools like TestRail, PractiTest and qTest gave test cases a real home, a stable numbering scheme and a run history, but treated automation as an import job that arrives after the fact.
- Third generation - the Jira-native add-on. Tools like Xray and Zephyr solved traceability by moving test cases inside the issue tracker, at the cost of living and dying with Jira.
- Fourth generation - AI-native. The repository is still the source of truth, but it is readable and writable by agents, it ingests automated results as they happen rather than as a nightly upload, and it treats the model in your editor as a first-class user alongside the QA lead.
M00N Report is a fourth-generation test management tool. It keeps everything the second generation got right about the repository, adds the real-time automation layer the second generation never had, and does not require you to buy Jira to get it.
A repository for every test asset
M00N Report stores and organizes test assets in a repository-like structure: an enforced folder and suite tree where nothing floats loose in an untitled list.
Folders and suites
Folders group by feature, area or team. Suites hold the cases, and a case always lives in exactly one suite.
Test cases
A rich-text document, not a row in a grid: numbered steps with expected results, attachments, tags, priorities, statuses, custom fields defined by your organization, and dependencies on other cases. Each case carries a stable per-project number, TC-142, plus a field-level history of who changed what and when.
Test Collections
Reusable, named sets of cases that deliberately cut across the folder structure: a smoke pack, a regression pack, a payments-only pack. Assemble a collection once and pull it into run after run; changing the collection changes every future run that uses it.
Existing material comes in through CSV import. Folders and releases that have served their purpose are archived rather than destroyed, so history stays intact.
Every one of those operations - create a folder, create a suite, author a case, move it, bulk-update a hundred of them - is available to an AI agent over MCP, the same operations a person would otherwise click through in the UI.
Support for multiple types of testing
A test management tool has to cover more than one type of testing. M00N Report covers manual and automated testing in one repository, under the same cases, with one set of results.
Manual testing
Runs through first-class Manual Test Executions. Create an execution from a whole collection, an entire suite, or a hand-picked set of individual cases. Assign testers, set an environment and a date window, then record per-step results with notes and attachments as you work through it.
Automated testing
Streams in live from CI. Unit, integration, API, end-to-end and cross-browser suites all report through the same ingest contract, and results appear in the UI while the run is still going rather than when it finishes. An automated test can be linked to the manual case it descends from, including before that automated test has ever run, so a single case shows both its manual execution history and its automated pass rate.
Releases
Sit above both. A release aggregates the manual executions and the automated launches that belong to a version, so release readiness is judged on the whole picture instead of on whichever half of the suite happens to be visible in whichever tool.
Cases are snapshotted into the execution at the moment it is created, so editing a case next month never quietly rewrites what a tester actually saw last month. That is the difference between a run history and a run record.
Reports and metrics on quality, not just pass rate
The third requirement is reports and metrics. This is where a test management tool that also receives raw automation output can say things a case repository alone cannot.
The basics are all there:
- Live dashboard: run activity, pass rates, failure hotspots and per-project health.
- Trend charts: compare launches over time and surface regressions.
- Flaky test detection: identified by counting how often a test flips between pass and fail across recent runs, rather than by waiting for someone to tag it.
- Per-case execution history: manual and automated together, so you can read the last twenty outcomes of one case in one place.
- Tag-based slicing: across features, components and teams.
- Exportable reports: for the people who will never log in.
Two metrics are specific to the fourth generation:
Coverage gap analysis
Runs in both directions: it finds test cases with no automation behind them, and it also finds automated tests appearing in recent launches that no test case owns. That second one is the shadow suite, and a classic TMS structurally cannot compute it, because it never sees raw automation output.
Composite health score
Condenses a project into a single number from 0 to 100, weighted 50% automation stability, 30% coverage and 20% manual execution discipline, broken out into per-dimension sub-scores with a prioritized list of what to fix first.
Coverage in M00N Report means Jira issue linking plus that bidirectional automation gap analysis. There is no requirements entity and no traceability matrix. If a formal requirements-to-tests matrix is a hard procurement requirement, raise it early and we will tell you straight whether we fit.
Integrations with your development platform
The fourth requirement is integration with the platforms where development actually happens. A test management tool that does not reach into them becomes a second place to update things.
Jira
Two-way. Test cases, launches and releases link to issues, and the links come back the other way as remote links on the Jira issue itself. A Jira issue-panel app puts test evidence inside the issue, where the developer already is. For teams on Jira, Feature Scan reads an epic, story or bug and returns its linked test cases, its automated and manual results, its coverage gaps and a feature risk score in a single report; it requires a connected Jira instance.
CI and beyond
Results stream in from GitHub Actions, GitLab CI, Jenkins, TeamCity or anything else that can run a reporter, and jobs on all four of those platforms can be triggered from inside M00N Report, so a QA lead can re-run a suite without a pipeline console. Slack carries the alerts. Identity is handled by OIDC and SAML single sign-on, including group-to-project JIT mapping, so a new joiner lands in the right projects on first login without an admin ticket.
Any language, any runner: five reporters and an OpenAPI contract
Most test management tools publish a fixed list of supported frameworks. If your stack is not on it, your stack does not report.
Five official reporters are published and maintained on the registries their ecosystems actually use:
- Playwrightnpm
- Jestnpm
- pytestPyPI
- NUnitNuGet
- JUnit 5Maven Central
Install one, add a few lines of configuration, and runs stream in.
The part that matters for everyone else is the contract underneath them. The ingest API is specified as OpenAPI 3.0.3 and published at /api/ingest/v2/openapi.json. The official reporters are not privileged clients: they speak exactly the same documented HTTP contract that anything else can.
Go, Rust, Ruby, PHP, Swift, Kotlin, a shell script wrapping a twenty-year-old runner, or a proprietary in-house harness can all report into the same test management tool.
Hand the spec to a code generator or to an AI assistant and a working reporter is an afternoon’s work rather than a quarter’s roadmap negotiation.
The OpenAPI contract covers reporting results into the platform. Managing test cases, executions and releases is done in the UI and over MCP: there is no public REST API for test management itself.
An agent gets the same surface a person does
AI-native here means the agent works the repository directly, not through a chat box bolted onto a dashboard. M00N Report ships an MCP server with 50 tools: 24 read-only and 26 that change state.
That read-and-write surface is what makes M00N Report ready for agentic AI. A business’s own agent reads every project’s health, trends and coverage gaps over MCP, reports back which projects are lagging, and then acts on it: files the missing case, flags the flaky suite, updates the release.
It is the customer’s own agent, not one we run. There is no built-in executive dashboard: run_health_check is scoped to one project, so a portfolio view is one the agent assembles itself. Nothing is sent to a separate AI service and there are no AI credits.
How agents connect, the full tool list, the write-cycle example and the governance model are on the MCP server page.
How it compares to TestRail, Xray and Zephyr
M00N Report is a peer in this category, not a replacement for it. The useful question is which generation of tool your team needs.
If your testing is entirely manual, your requirements live in a formal matrix, and nothing runs in CI, a second-generation TMS will serve you well, and we will say so.
If every artifact your organization owns already lives in Jira and always will, a third-generation add-on has an advantage we do not try to match.
The case where a real automation suite and a real manual process have to be governed together, where results should be visible during the run rather than after it, and where an AI assistant is expected to do actual work rather than summarize a dashboard.
We publish side-by-side comparisons with TestRail, Xray, Zephyr, qTest, PractiTest, ReportPortal and Allure TestOps. Each is fact-checked against the vendor’s own documentation and pricing page, with the dates we verified them and the cases where the other tool is the better fit stated plainly. Read them on the compare hub.
The same entities, under different names
Almost everything M00N Report does has an exact counterpart in the tool you use today. The names just differ, and the planning vocabulary diverges most, which is the real reason people sometimes conclude it cannot plan. It can. Here is the translation.
| M00N Report | TestRail | Xray | Zephyr Scale | qTest |
|---|---|---|---|---|
| Test Case | Test Case | Test (a Jira issue) | Test Case | Test Case |
| Suite | Section | Test Repository folder | Folder | Module |
| Test Collection | no equivalent | Test Set | no equivalent | no equivalent |
| Execution | Test Run, grouped by a Test Plan | Test Execution, grouped by a Test Plan | Test Cycle, grouped by a Test Plan | Test Suite in a Test Cycle |
| Release | Milestone | Jira fix version | Jira version | Release |
| Launch | An automated run, which in every one of these tools arrives as a file uploaded after the run. In M00N Report it is a live entity you watch stream in. | |||
A Test Plan does two jobs. The scoping job, deciding which cases are in an effort, belongs to reusable Test Collections. The rollup job, one readiness number across everything, belongs to a Release. Split across two nouns, both jobs are covered, so "weaker planning" is a vocabulary difference, not a missing capability.
Cloud or self-hosted, with the controls procurement asks about
Procurement asks about the same handful of controls every time:
- Tenant isolation: enforced in the database itself through PostgreSQL row-level security, not by a WHERE clause someone might forget.
- Role-based access: four roles, including a read-only Guest that costs nothing per seat, so stakeholders who only ever read a release report do not consume a licence.
- Single sign-on: OIDC and SAML with group-to-project JIT mapping.
- MCP keys: rate-limited per key, with every agent action written to an in-app audit log.
The same product runs in our cloud or on your infrastructure. Self-hosted deploys via Docker Compose or Kubernetes, behind your firewall, with the identical feature set: the same repository, the same executions, the same reporters, the same MCP server.
Pricing is per seat and identical either way, and the free plan is the full product with team-size limits rather than a crippled demo.
Questions, answered
What is a test management tool?
A test management tool is the system of record for a QA team's testing work. It stores and organizes test assets in a repository-like structure, supports more than one type of testing, produces reports and metrics on quality, and integrates with the development platforms where code and issues live. M00N Report does all four.
Is M00N Report a test management system or a test reporting dashboard?
It is a test management system. It has a folder and suite repository for test cases with steps, attachments, custom fields and tags, reusable Test Collections, first-class Manual Test Executions with assignees and per-step results, and Releases that aggregate manual and automated evidence. Real-time reporting of automated results is one pillar of the product, not its definition.
Does M00N Report support manual testing?
Yes. Manual Test Executions are a first-class entity. You build an execution from a collection, a suite or individual cases, assign testers, set an environment and a date window, and record per-step results with notes and attachments. Cases are snapshotted into the execution when it is created, so later edits to a case never change the record of what was actually run. There is no separate exploratory-session module today; manual execution is structured and case-driven.
Can AI create and manage test cases in M00N Report?
Yes. The MCP server exposes 50 tools, 26 of which change state, so an assistant can create folders and suites, author test cases from Markdown, tag and link them to Jira, build collections, create and populate manual executions, manage releases and link automated tests to manual cases. Your own model does the writing; M00N Report supplies project-aware scaffolding and then persists the result into the repository with real IDs, history and role-based permissions.
Which languages and test frameworks can report results?
Five official reporters are published: Playwright and Jest on npm, pytest on PyPI, NUnit on NuGet and JUnit 5 on Maven Central. Everything else uses the documented OpenAPI 3.0.3 ingest contract at /api/ingest/v2/openapi.json, which the official reporters themselves speak, so any language and any runner can report into the same platform.
Can I migrate from TestRail, Xray or Zephyr?
Test cases can be brought in today via CSV import, which covers the export format every major tool offers. Dedicated vendor-specific importers are on our backlog rather than shipped, so for a large migration we will look at your export with you before you commit.
Can I run M00N Report on my own infrastructure?
Yes. The self-hosted edition deploys with Docker Compose or Kubernetes behind your firewall and carries the same feature set as the cloud version, including the MCP server, all five reporters and SSO. Pricing is per seat and the same either way.
Is there a free plan?
Yes. The free plan is the full product with team-size limits rather than a feature-limited trial, and the read-only Guest role is not billable, so stakeholders who only read reports never consume a paid seat.
Start with one project
The fastest way to evaluate a test management tool is to put one real feature area into it. Create a project, import or author a dozen cases into a folder and a suite, build a collection, run one manual execution against it, point one CI job at a reporter, then open the coverage gap report and see what your automation has been doing that nobody wrote down. That takes an afternoon, it costs nothing on the free plan, and it answers more than any feature matrix will. Pricing, including the self-hosted option, is published in full.