Traçabilité

L’Idée

Le cycle en V pose une question simple à chaque exigence : qu’est-ce qui la réalise, et qu’est-ce qui la prouve ? Sinra y répond par trois liens explicites, tous facultatifs, tous lisibles depuis la fiche d’une issue.

Une spécification dit quoi vérifier. Un plan, facultatif, dit comment. Une tâche la réalise. Un testing dit qu’on l’a vérifiée.

Spécification ──► Plan (facultatif) ──► Tâche      (chaîne de conception)
      │
      └──────────► Testing → Accepted / Rejected    (vérification)

Bug hors capability ···► Capability concernée       (informatif)

Tout se passe à l’intérieur d’une capability, dont la page se lit donc d’un seul tenant : exigences, réalisation, tests.

La Chaîne de Conception

Un plan a pour parent une spécification, une tâche a pour parent un plan ou une spécification. Les bugs et les spécifications n’ont pas de parent. Trois niveaux au plus, pas de sous-tâches.

• Le parent est facultatif : une tâche sans parent est valide.
• Parent et enfant sont toujours dans la même capability.
• Supprimer un plan fait remonter ses tâches à la spécification. Une spécification qui a encore des enfants ne peut pas être supprimée.

Sur la fiche d’une spécification, vous voyez ses plans, puis les tâches sous chaque plan, puis les tâches rattachées directement, chacune avec son statut. Vous voyez aussi les tâches terminées sur le total, et la réalisation de la spécification : Not started, In progress ou Done, calculée à partir de ses tâches.

La génération assistée garde la chaîne pour vous : le plan généré depuis une spécification a cette spécification pour parent, et les tâches générées depuis un plan ont ce plan pour parent.

Les Tests qui Vérifient une Spécification

Un testing peut dire quelle issue il Verifies : une spécification ou un bug de sa capability. Le lien est facultatif, un testing peut toujours couvrir la capability entière.

• La fiche d’une spécification liste les testings qui la vérifient, avec leur état (accepté ou non), et propose Add a test.
• Sur la page de la capability, chaque spécification indique son nombre de tests, ou No test yet.
• Le widget des trous de couverture du tableau de bord du testeur liste les spécifications actives sans aucun testing.

Une spécification est comptée comme testée dès qu’un testing la désigne, accepté ou non. Son statut de rédaction ou sa réalisation ne comptent jamais comme couverture : seuls les testings comptent.

Pour que le lien reste vrai, une issue vérifiée par au moins un testing ne peut pas être supprimée, ne peut pas quitter la capability de ses tests, et ne peut pas être changée, via l’API, vers un type non testable. Le message indique le nombre de tests concernés.

Les Bugs Après Livraison : Concerns

Un bug trouvé après la livraison ne peut pas retourner dans la capability livrée : il prendrait sa release, déjà passée, et compterait dans son avancement. Il reste donc sans capability, et déclare la capability qu’il Concerns.

• Le lien n’a aucun effet sur la release du bug, ni sur l’avancement, la charge, la phase ou la capacité de la capability.
• La page de la capability liste ces issues à part, sous Concerned issues, avec type, statut et release.
• Un bug qui concerne une capability peut être vérifié par un testing de cette capability : c’est ainsi que l’on écrit le test de non-régression d’un bug post-livraison.
• Une issue n’a jamais à la fois une capability et une capability concernée. Choisir une capability vide l’autre champ.

Où les Liens Apparaissent

Les issues et les testings existants n’ont aucun lien tant que vous n’en posez pas : Sinra ne devine jamais un lien à partir des noms ou des dates.