A feature's Testing tab
The readiness verdict for one feature — coverage against its acceptance criteria, traceability, warnings, CI results and sign-off.
Open a feature and switch to its Testing tab. Where the project's Testing tab answers "what is the state of the suite?", this one answers a narrower and more useful question: is this feature ready to sign off?
Everything on the tab is an input to that question. The tab answers it directly rather than leaving you to assemble it.
The verdict
The card at the top states one of five things:
| Verdict | What it means |
|---|---|
| Not ready to sign off | Something is a known defect or an untested criterion — a failing linked case, or a criterion with no case at all |
| Signable, with caveats | Nothing is failing or uncovered, but the picture is imperfect — ambiguous criteria, or a QA analysis that predates the current spec |
| Ready to sign off | No reason found against it |
| Coverage looks clean, but not all cases are loaded | The linked-case list is paginated and incomplete, so a clean reading cannot be trusted yet |
| Nothing to test against yet | No acceptance criteria have been parsed from the specification |
It also lists why, in the order worth acting on:
- failing cases — a known defect
- uncovered criteria — an unknown
- ambiguous criteria — untestable as written
- missing QA analysis — none has ever been generated
- stale QA analysis — it predates the current specification
Failing outranks uncovered deliberately. A criterion nobody wrote a case for is an unknown; a criterion whose case fails is a known defect, and a known defect is the more urgent of the two.
Staleness is never dropped from the list, even when everything else is green. It is the reason a page that looks clean can be describing a specification that no longer exists.
Coverage
The coverage figure counts acceptance criteria, not cases. Ten cases written against one criterion is not coverage; it is ten cases against one criterion, and a percentage over case count would call that a finished feature. The ring shows how many criteria have at least one case covering them, and the line under it says how many still have none.
The linked-case count is shown separately, and says so when not all of them are loaded.
Traceability
Each acceptance criterion, and the cases covering it. A criterion with nothing against it is marked Not covered.
Below it, two lists that exist because coverage can fail in both directions:
- Not mapped to a criterion — cases linked to this feature that no criterion claims. Usually fine, sometimes a case that outlived the criterion it was written for.
- Automated tests not tracked — tests your CI is genuinely running that match no case in Fabric. They do not count towards coverage: Fabric will not credit you for a test it cannot tie to a requirement. Create a case and the next sync links it.
The matrix can be exported.
Under-specified criteria
Criteria the QA analysis flagged as too ambiguous to test reliably.
A criterion nobody can write a reliable case for will produce cases that pass while the requirement goes unmet. Clarify it in the Full Specification before trusting the cases drafted from it.
Drafting
Two buttons, and a line saying which ordering this project uses.
- Generate QA analysis / Refresh QA analysis — reads the current specification and produces the coverage, traceability and warnings above. If the spec has changed since the last run, the tab says so and the verdict keeps flagging it until you refresh.
- Draft cases — drafts cases from the acceptance criteria. Drafted cases arrive as Proposed; nothing joins the suite unasked.
The ordering line reads either "Standard ordering: test cases are drafted after the feature is reviewed" or "TDD ordering: test cases are drafted from the acceptance criteria and reviewed before implementation." That switch changes what the feature review is allowed to read — see Test-driven and standard ordering.
If the project has test-case generation switched off, the buttons say so rather than failing when pressed.
If the project's depth is set to Light, only functional coverage and warnings are produced — no integration, end-to-end, security or accessibility analysis. That is the tier working as configured, not an incomplete run. Change it in Testing settings.
Cases drafted from an older version
When the specification moves under cases that were drafted from it, those cases appear in their own section rather than silently going stale. Nothing is discarded and nothing is rewritten for you — you decide what to keep.
This section renders nothing when nothing has drifted, so its presence always means there is something to decide.
CI results and history
On wide screens these sit in a right-hand rail beside the matrix; on narrow ones they stack underneath.
- Pipeline results — the CI runs that touched this feature's cases.
- History — every QA analysis and every drafting run over this feature, newest first, so you can see what produced the current picture. The dialog behind it lists them as QA analyses.
Sign-off
If your project requires approvals, the sign-off section collects them here, next to the evidence they are about.
It renders nothing when the project requires no approvals — an empty approvals section would imply a step that does not exist.
Next steps
Test Cases
Author test cases with ordered steps, sync them to your PM tool, group them into plans, link them to the work they verify, and let the project AI use them as context.
CI Test Results
Pull automated test results from GitHub Actions, GitLab CI, and Azure DevOps into Fabric, link them to your test cases, and see what broke without opening your CI dashboard.