sinraQue sont les Testings ?
Les testings sont des cas de test QA attachés aux capabilities. Au lieu de maintenir un outil séparé comme TestRail, votre équipe QA crée et exécute des cas de test directement dans Sinra, liés à la fonctionnalité qu’ils valident.
Créer un Cas de Test
N’importe quel utilisateur avec accès Reporter ou supérieur peut créer un testing sur une capability :
- Ouvrir la capability
- Cliquer sur “Ajouter un Testing”
- Définir le nom du test, la description et le résultat attendu
- Assigner à un utilisateur QA
- Facultativement, choisir l’issue qu’il Verifies
Le fil d’Ariane d’un testing affiche sa capability : Home, capability, testing.
Vérifier une Spécification ou un Bug
Un testing peut dire quelle issue il vérifie. Le champ ne propose que les spécifications et les bugs de la capability du testing, ainsi que les bugs sans capability qui la Concern. Les plans et les tâches ne se testent pas, et les modèles jamais. Le lien est facultatif : un testing peut toujours couvrir la capability entière.
- La fiche du testing affiche l’issue vérifiée, cliquable.
- La fiche d’une spécification ou d’un bug liste les testings qui la vérifient, avec leur état, et propose Add a test avec la capability et l’issue déjà renseignées.
- Sur la page de la capability, chaque spécification indique son nombre de tests, ou No test yet.
- Rejeté ou non, un testing qui désigne une spécification la fait compter comme testée.
Une issue vérifiée par au moins un testing ne peut pas être supprimée, déplacée vers une autre capability, ni changée via l’API vers un type non testable, tant que les testings ne sont pas supprimés ou détachés. Le message donne le nombre de tests.
Exécuter des Tests Pendant un Cycle
La vue /testings/current affiche tous les cas de test en cours pour la release active. Le QA exécute chaque test et le marque :
| Résultat | Signification |
|---|---|
| Accepté | Test réussi, la fonctionnalité est validée |
| Rejeté | Test échoué, l’issue liée doit être rouverte ou un bug créé |
Les tests rejetés remontent immédiatement dans la vue capability, donnant aux développeurs et aux responsables produit un statut QA en temps réel.
Traçabilité
Les testings connectent la capability à la validation :
Capability → Spécification → Testing → Accepté / Rejeté
Quand une release est livrée, vous pouvez revoir quelles capabilities avaient tous les tests acceptés vs lesquelles avaient des rejets qui ont été ignorés ou reportés. Cette piste d’audit est préservée dans la rétrospective de la release.
Trous de Couverture
Le widget des trous de couverture du tableau de bord du testeur liste les spécifications actives qui n’ont aucun testing, avec leur capability et leur release, à côté des deux indicateurs existants. Seuls les testings comptent : une spécification marquée terminée reste un trou si rien ne la vérifie. Les testings existants n’ont aucun lien tant que vous n’en posez pas, donc les spécifications existantes apparaissent d’abord comme non testées.
Voir Traçabilité pour la chaîne complète.
Pourquoi un QA Intégré est Important
Passer entre un outil de tickets et un outil QA séparé crée des problèmes de synchronisation : les bugs trouvés dans TestRail doivent être créés manuellement dans Jira. Sinra élimine ce transfert. Un cas de test rejeté est directement lié à la capability et au cycle où la correction appartient.