Skip to main content

Requirements and coverage

A requirement in Sekee is a thin reference row: usually a Jira issue, with its title, status and priority cached locally, occasionally a statement typed by hand. It deliberately has no status of its own.

Why it has no status​

Because a status would have to be maintained, and a maintained status is a status that goes stale. Instead, everything the Requirements screen tells you is derived on every read from the evidence underneath it.

How coverage is worked out​

Three inputs, per linked test case:

  1. The latest verdict on that case from bug hunt runs — hidden hunt copies excluded, because a case taken out of a hunt is not something that hunt says about it
  2. Open bugs raised against the case — Open or In progress
  3. The last result of any automated test linked to the case

Then: worst wins, and "passing" means every linked test says so. One failing case, or one open bug, is enough to stop a requirement reading as covered.

Nothing anywhere stores a coverage word. There is no cache to invalidate and no job to re-run.

:::tip The most common cause of a requirement reading as uncovered A test case that was written for it and never linked to it. Coverage is derived from links, so an unlinked case contributes nothing. This is the failure the default AI rule exists to prevent, and what Test case review is for catching. :::

Adding a requirement​

Requirements → Link requirement.

  • From Jira — search your connected instance and pick the issue. The key, title, status and priority are cached on the row and refreshed on demand or by webhook.
  • By hand — give it a one-line title and, optionally, a rich text description so the row can be the actual record of the requirement rather than a label.

If Jira is not connected, the picker says so and tells you who can connect it — and a key typed in the meantime is kept until then.

Linking test cases​

Link from either side: from the requirement, or from a test case's Requirements section. A case can prove several requirements and a requirement can be proved by several cases.

Automated tests are linked to test cases, not to requirements directly. That is the chain: requirement → test case → automated test → last CI result.

Reading the screen​

Each row shows the requirement, its cached Jira state, the cases linked to it, and the derived coverage. The standard toolbar filters by coverage, by project and by source.

What flows back to Jira​

If the integration is connected and link syncing is on, Sekee writes a remote issue link on the Jira issue for each linked test case — one per pair, updated rather than duplicated — with the case name and a one-line summary of the evidence. See Jira.