Requirements, plans, cycles and incidents

The paper trail: how the RTM and cycle report are derived and what an incident is.

Requirements and coverage

Requirements have a key, a priority (must, should, could) and a status. Link test cases to them on the test design page. The traceability matrix reads each requirement's linked cases and their latest execution: verified when the latest run passed, failing when it failed, untested when no run exists, uncovered when no case is linked.

Plans and cycles

A plan groups test cases. Running a plan creates a cycle: cases with recorded steps replay with no model calls; cases without recorded steps are recorded as inconclusive with the reason, so the report says what was not tested rather than hiding it.

Incidents

A failed execution opens exactly one incident carrying the first failing step's message, a link to the run and its evidence. Incidents have a severity and a status, and export to Jira Cloud as an issue once a connection is configured under Settings → Integrations.

The cycle report

Derived on read from execution rows: verdict, counts, per-execution status, duration, model calls and cost, the failure message and incident, and the requirements the cycle covered. It downloads as Markdown.

Heal audit

The Heals page lists every locator heal proposal in a window: the recorded locator, the one the replay ran with, the similarity, and whether it was approved. Publish it with the release.