Traceability

The Idea

The V-Model asks a simple question of every requirement: what builds it, and what proves it? Sinra answers with three explicit links, all optional, all readable from the issue page.

A specification says what to verify. A plan, optional, says how. A task builds it. A testing says it was verified.

Specification ──► Plan (optional) ──► Task        (design chain)
      │
      └──────────► Testing → Accepted / Rejected   (verification)

Bug outside a capability ···► Capability it concerns   (informative)

All of it happens inside one capability, so the capability page reads as a whole: requirements, their implementation, their tests.

The Design Chain

A plan has a specification as parent, a task has a plan or a specification as parent. Bugs and specifications have no parent. Three levels at most, no sub-tasks.

• The parent is optional: a task without a parent is valid.
• Parent and child always belong to the same capability.
• Deleting a plan moves its tasks up to the specification. A specification that still has children cannot be deleted.

On a specification page, you see its plans, then the tasks under each plan, then the tasks attached directly, each with its status. You also see the tasks done out of the total, and the realization of the specification: Not started, In progress or Done, calculated from its tasks.

The assisted generation keeps the chain for you: the plan generated from a specification has that specification as parent, and the tasks generated from a plan have that plan as parent.

Tests that Verify a Specification

A testing can say which issue it Verifies: a specification or a bug of its capability. The link is optional, a testing can still cover the whole capability.

• A specification page lists the testings that verify it, with their state (accepted or not), and offers Add a test.
• On the capability page, each specification shows how many tests it has, or No test yet.
• The coverage-gap widget of the tester dashboard lists active specifications without any testing.

A specification counts as tested as soon as a testing points at it, accepted or not. Its writing status or its realization never count as test coverage: only testings do.

To keep the link true, an issue verified by at least one testing cannot be deleted, cannot leave the capability of its tests, and cannot be changed, through the API, to a type that cannot be tested. The message gives the number of tests involved.

Bugs After Delivery: Concerns

A bug found after delivery cannot go back into the capability that shipped: it would take its release, already delivered, and count in its progress. It stays without a capability, and declares the capability it Concerns instead.

• The link has no effect on the release of the bug, nor on progress, load, phase or capacity of the capability.
• The capability page lists these issues apart, in Concerned issues, with type, status and release.
• A bug that concerns a capability can be verified by a testing of that capability: this is how you write the regression test of a post-delivery bug.
• An issue never has both a capability and a concerned capability. Choosing a capability empties the other field.

Where the Links Show Up

Existing issues and testings keep no link until you set them: Sinra never guesses a link from names or dates.