Trace coverage

Every other screen in the Hub asks what the sync did to a field. Trace coverage asks what it did to the trace matrix.

That question needs its own screen because a sync reports itself as a success whether or not anyone traces what it brought in. Fifty requirements arriving from Jira is a successful cycle on Activity and on Sync history, and fifty holes in the matrix.

Reading it

Choose a project and four figures appear:

• Items linked externally — how many of the project’s items have a twin in another tool.
• Appear in a trace link — how many of those are traced, and what share that is.
• In no trace link at all — the finding, and the only figure ever highlighted.
• Of those links are suspect — how many of the trace links touching synced items are currently suspect.

Below them, the untraced items are listed by their external key and traceunified ID — for example KAN-19 and PMS-TC-004 — with each link’s state. A link whose item no longer exists is shown as such, because it is untraced for a different reason. When the list is longer than the screen shows, it says so, and the rest are found the same way in the trace matrix.

An item counts as traced if it appears in a trace link in either direction.

What these figures do not establish

The screen states its limits beside its findings, not behind a disclosure:

• A trace link records that it is suspect and when, but not what made it so. The suspect count describes the state of the synced items; it is never attributed to the sync.
• Attachment links are not traces, and are excluded — exactly as they are from suspect propagation.
• This is one intersection, not the trace matrix. Whether one item type must trace to another is still the matrix’s question.

Who can open it

Trace coverage is available to organisation administrators, quality managers and project managers, and each sees only the projects they can read.