Test Management for Cypress: History, Reporting, and Traceability

Test management for Cypress means connecting your Cypress runs to a test management system (TMS) so results gain history, traceability to manual cases, and a single coverage view — none of which Cypress provides on its own without paying for its cloud service. Cypress is an excellent test runner, but it is not a system of record.

This guide explains where Cypress's built-in reporting falls short, why run history pushes you toward a paid cloud, and how a TMS fills those gaps using the Mochawesome report your Cypress suite can already produce.

Where Cypress's built-in reporting falls short

Cypress is great at running tests. Reporting on them over time is a different story, and teams hit the same three limitations:

• No native "after all" reporter. Cypress has no built-in hook that fires once after an entire run completes, so there is no clean way to collect and publish whole-run results out of the box. Teams end up wiring together Mochawesome and plugins to get a usable JSON report at all.
• History means paying for the cloud. Cypress's local reporters show a single run. To get historical dashboards, flakiness trends, and run-over-run history, Cypress steers you to Cypress Cloud — whose free tier is capped on recorded runs, after which run history becomes a paid feature billed by usage. For many teams, "just keep our test history" turns into a recurring cost.
• No link to manual tests or requirements. A Cypress report knows nothing about your manual test cases or the requirements they verify. Automated and manual coverage stay split across separate tools, so nobody has the full picture.

A test management system sits on top of Cypress and addresses all three: persistent history, traceability to manual cases and requirements, and one combined coverage view — without metering your run history. We cover the broader idea in what a test management system is.

What a TMS adds to a Cypress workflow

When Cypress results flow into QAM Hub, each run becomes durable, searchable data instead of a CI log that disappears on the next build:

• Run history and trends — pass rate, flakiness rate, a stability score, average duration, and trend sparklines across a 7–90 day window, so you can see whether your suite is actually getting healthier.
• Per-test detail — every test with its status, error message and stack trace, retries, and a screenshot of the failure point.
• Cross-run intelligence — automatic detection of regressions (passed last run, failing now), chronic failures (failing every run), top failing tests, and per-run flakiness.
• Traceability to manual cases — automated results link back to your manual test cases, so manual and automated coverage live side by side.
• CI context (optional) — each run can carry branch, commit SHA, commit message, environment, build URL, and who triggered it — if your pipeline passes them when it submits the report.

What the Cypress integration handles specifically

QAM Hub reads the Cypress Mochawesome JSON report (from cypress-mochawesome-reporter or standard Mochawesome). On top of the general capabilities, the Cypress integration takes care of the things that usually make Cypress reporting misleading:

• Embedded screenshots from the report are captured and stored with each failed test.
• All skip types handled correctly — whether a test was .skip()-ed, skipped at runtime, or aborted by a failing hook — so your totals are never inflated or wrong.
• Honest flaky detection — a test that only passed after a retry is marked flaky, not counted as a clean pass.
• Flexible manual-case linking — via the TC-<number> convention in test titles, and a single Cypress test can cover several manual cases at once.

How to connect Cypress to QAM Hub

Because Cypress has no native after-run reporter, QAM Hub's integration builds on Mochawesome. Setup is three steps: enable Mochawesome, then submit the report either automatically from an after:run hook or via a CLI command in CI.

Step 1 — install and enable Mochawesome

npm i -D @qamadness/qam-cypress-reporter cypress-mochawesome-reporter mochawesome

Register the reporter in cypress/support/e2e.js:

import 'cypress-mochawesome-reporter/register';

And configure it in cypress.config.js so it writes a JSON report:

const { defineConfig } = require('cypress');

module.exports = defineConfig({
  reporter: 'cypress-mochawesome-reporter',
  reporterOptions: {
    reportDir: 'cypress/reports',
    overwrite: false,
    html: false,
    json: true,
    saveJson: true,
    embeddedScreenshots: true,
    inlineAssets: true,
  },
  e2e: {
    setupNodeEvents(on, config) {
      require('cypress-mochawesome-reporter/plugin')(on);
      return config;
    },
  },
});

Step 2 (Option A) — submit automatically from an after:run hook

This is the fully automatic route — results submit when cypress run finishes, with no extra script:

const { submitToQAM } = require('@qamadness/qam-cypress-reporter');

module.exports = defineConfig({
  // ...reporter options above...
  e2e: {
    setupNodeEvents(on, config) {
      require('cypress-mochawesome-reporter/plugin')(on);

      on('after:run', async () => {
        await submitToQAM({
          apiUrl: process.env.QAM_API_URL,
          projectId: process.env.QAM_PROJECT_ID,
          runName: `CI Run ${process.env.CI_BUILD_NUMBER ?? new Date().toISOString()}`,
          // apiToken is read from QAM_API_TOKEN by default
        });
      });

      return config;
    },
  },
});

Then just run npx cypress run and results submit automatically.

Step 2 (Option B) — submit from CI with the CLI

If you prefer to keep submission as an explicit pipeline step, use the bundled CLI after the run:

{
  "scripts": {
    "cy:run": "cypress run",
    "cy:submit": "qam-submit-cypress",
    "cy:test": "npm run cy:run && npm run cy:submit"
  }
}

The CLI reads QAM_API_URL, QAM_PROJECT_ID, and QAM_API_TOKEN from the environment (store the token as a CI secret). Generate the token in QAM Hub under Profile → API Tokens. This is also where your pipeline can attach optional CI metadata — branch, commit, environment, and build URL — to the run.

Alternative — upload the report manually

You can also drag-and-drop the Mochawesome JSON file into QAM Hub's automation section. The framework is detected automatically, so there is no separate Cypress-versus-Playwright setup on upload. This is a useful fallback while you wire up CI — though a manual upload won't include the CI metadata a pipeline would attach.

Linking Cypress tests to manual cases

To connect an automated result to its manual test case, prefix the Cypress test title with TC-<number> matching the case in QAM Hub:

it('TC-17: adds item to cart', () => {
  // ...
});

QAM Hub then builds a live bridge between the automated execution and the manual case — and a single Cypress test can cover several manual cases at once. From a manual case, you can trace straight to its automated execution history, which is what makes your coverage picture honest during the move from manual testing to automation. We cover that journey in manual to automation: what to automate first.

Seeing whether your automation is trustworthy

Once runs flow in, QAM Hub's Test Explorer answers the questions a raw Cypress report cannot: is the suite green, is it stable, and is it actually covering the cases you care about. You can drill into any test for a run-by-run timeline and duration trend, quarantine flaky tests so they stop polluting your health metrics, and slice by suite, framework, branch, or environment. Tied to requirements traceability, this connects your Cypress suite back to what the release needs to deliver — see the requirements traceability matrix.

Frequently asked questions

Does Cypress need a separate test management tool?

Cypress runs tests but does not store history, link results to manual cases, or show coverage on its own — and its historical dashboards live in the paid Cypress Cloud. A TMS adds persistent history, traceability, and combined manual-plus-automated coverage without metering your run history.

How do Cypress results get into the TMS?

Through the Mochawesome JSON report. You can submit it automatically from an after:run hook, run a CLI command in CI, or drag-and-drop the JSON file in the UI. The framework is detected automatically.

Do I still need Cypress Cloud?

Not for test history and reporting. A TMS keeps your run history, flakiness trends, and per-test detail independently of Cypress Cloud, so history is not a metered, paid feature.

How are flaky tests and skips handled?

A test that only passes after a retry is marked flaky rather than a clean pass, and all skip types — .skip(), runtime skips, and tests aborted by a failing hook — are counted correctly, so your totals stay accurate.

Where does the branch and commit info come from?

From your pipeline. CI metadata — branch, commit SHA and message, environment, build URL, and who triggered the run — is optional: QAM Hub stores and displays it when your CI passes it along with the report. On a manual JSON upload through the UI, these fields are usually empty.

Can one Cypress test cover several manual cases?

Yes. Using the TC-<number> convention in the test title, a single Cypress test can link to multiple manual test cases at once.

Summary

Cypress is a strong test runner, but its built-in reporting is thin and real run history is a paid cloud feature. Connecting Cypress to a test management system gives those runs persistent history, honest flakiness and skip handling, traceability to manual cases, and one combined coverage view — built on the Mochawesome report your suite can already produce.

QAM Hub is a test management system built by QA Madness, a software testing and QA automation company. It ingests Cypress and Playwright results, links them to manual cases, and reports coverage and trends in one workspace — built by QA engineers who automate testing every day.