Workflow de révision TC
Table des matières
- Liste de progression
- Discipline
- La loi de fer
- Refus d'abord (porte de précondition)
- Étape 1 — Charger les deux sources textuellement [liberté moyenne]
- Étape 2 — Construire la matrice de traçabilité [liberté moyenne]
- Étape 3 — Vérification de la qualité des lignes [liberté moyenne]
- Étape 3b — Parcours des sources avant 'demander au PO / rapporteur' (obligatoire) [faible liberté]
- Étape 4 — Rapport Bon vs À améliorer [liberté moyenne]
- Étape 5 — Notifier le canal TC-review du projet [faible liberté]
- Clôture QA (obligatoire avant 'terminé') [faible liberté]
- Composition de la compétence
- Hors de portée
- DOIT / NE JAMAIS
- Fichiers à lire obligatoirement
- Dépendances
Juger un document de cas de test que quelqu'un a déjà écrit — ce workflow ne conçoit ni ne modifie les cas de test lui-même. Il répond à une seule question : ce document, tel qu'il est rédigé, prouve-t-il que les AC/EC et les règles métier du ticket seront vérifiés ?
Raccourci de commande slash (pour les runtimes prenant en charge les commandes) : /tc-review → commands/tc-review.md.
Liste de progression
Copiez ce bloc dans votre réponse au démarrage et cochez chaque ligne au fur et à mesure. Un échec de la porte vous renvoie à l'étape indiquée dans sa ligne Revenir à : — décochez à partir de là.
Progrès de la révision TC :
- [ ] Refus d'abord (porte de précondition)
- [ ] Étape 1 — Charger les deux sources textuellement
- [ ] Étape 2 — Construire la matrice de traçabilité
- [ ] Étape 3 — Vérification de la qualité des lignes
- [ ] Étape 3b — Parcours des sources avant 'demander au PO / rapporteur' (obligatoire)
- [ ] Étape 4 — Rapport Bon vs À améliorer
- [ ] Étape 5 — Notifier le canal TC-review du projet (demander uniquement le fil)
- [ ] Clôture QA (obligatoire avant 'terminé')
Discipline
Suivez shared-preamble.md et shared-must-never.md.
La loi de fer
PAS DE CONSTATATION SANS UNE SOURCE CITÉE DES DEUX CÔTÉS
Chaque constatation compare deux choses qui ont été réellement ouvertes lors de cette session : le texte propre du document TC et le texte propre des AC/EC/règles métier du ticket (ou une source de conception telle que Figma/PRD, seulement après avoir été réellement ouverte). « Le TC semble incomplet » basé sur un sentiment général de qualité, sans le libellé propre du ticket cité à côté, n'est pas une constatation — lisez le ticket, puis jugez. Une affirmation de source de conception (texte de copie exact, état UI exact) sans source réellement ouverte lors de cette session n'est pas non plus une constatation — dites « non vérifié — impossible d'ouvrir {source} » au lieu de deviner.
C'est la même discipline que catch-ai-workflow applique en général pour le travail terminé ; ce workflow en est une instance spécifique aux TC, exécutée avant l'exécution plutôt qu'après.
Refus d'abord (porte de précondition)
NE DOIT PAS démarrer sans les deux éléments suivants :
- le document TC — une feuille de calcul, un CSV ou un fichier Markdown, accessible et lisible lors de cette session ;
- le ticket associé — une clé ou une URL de ticket Jira contenant AC/EC (ou une source de spécification équivalente que l'utilisateur nomme explicitement).
🔴 ARRÊT — l'un des deux manque, stoppez en un seul message selon skill-rules-style.md.
Ticket inter-organisation / inter-site : si le ticket se trouve sur un site Atlassian auquel le MCP connecté n'a pas obtenu l'accès, dites-le et demandez à l'utilisateur d'accorder l'accès (ou de coller les AC/EC directement) — ne devinez jamais un identifiant cloud, ne vous rabattez jamais sur une connexion navigateur pour le lire.
Étape 1 — Charger les deux sources textuellement [liberté moyenne]
- Document TC — lisez-le tel qu'il est réellement ; ne retapez pas, ne résumez pas, ne « nettoyez » pas le libellé pendant le chargement. Notez la source exacte (identifiant de la feuille + onglet/gid, chemin de fichier ou URL) afin que chaque citation ultérieure puisse y renvoyer.
- Ticket — récupérez les AC, EC et toute section de règles métier / liste de re-vérification dans les propres champs du ticket (description, champs personnalisés — certains projets conservent le contenu en dehors de
description; vérifiez les deux). Citez les étiquettes AC/EC et le texte exactement tels qu'écrits ; ne paraphrasez jamais de mémoire d'un ticket similaire. Aucun AC/EC trouvé dans l'un ou l'autre endroit → arrêtez selon la porte de refus d'abord. Texte de spécification trouvé mais ses éléments ne portent pas d'étiquettes AC/EC → 🔴 ARRÊT — montrez le texte trouvé et demandez à l'utilisateur comment le numéroter avant l'étape 2 ; n'inventez jamais d'étiquettes. Le ticket ou le document TC génère une erreur de récupération, expire ou renvoie un contenu partiel (texte tronqué, champs manquants, onglets qui ne se chargent pas) → dites à l'utilisateur l'erreur exacte ou ce qui manque, ne construisez pas la matrice à partir d'AC/EC partiels ou d'un document TC partiel, confiez l'échec àsuperpowers:systematic-debugging, et reprenez l'étape 1 uniquement une fois le texte complet chargé. - Si une source de conception (Figma, PRD) est liée et que l'utilisateur souhaite une vérification croisée, ouvrez-la lors de cette session. Si elle ne peut pas être ouverte (pas de session, pas d'accès, lecture seule sans contenu rendu), enregistrez-le clairement — cela devient une note « non vérifié » à côté de toute constatation connexe, jamais un saut silencieux.
Étape 2 — Construire la matrice de traçabilité [liberté moyenne]
Pour chaque AC et EC sur le ticket, listez quelle(s) ligne(s) TC prétend(ent) le ou les couvrir :
| AC/EC | Revendiqué par | Statut |
|---|---|---|
AC_01 | TC_003 | couvert |
AC_05 | — | aucun TC — lacune |
AC_02 | TC_007 | mal étiqueté — TC_007 Résultat attendu correspond à AC_04 |
EC_01 | TC_010, TC_011 | étiquette incohérente — le TC_012 frère teste le même élément sans étiquette |
Le statut est une liste fermée — utilisez exactement une de ces quatre valeurs par ligne, en nommant les identifiants comme indiqué :
couvert · aucun TC — lacune · mal étiqueté — <TC> correspond à <AC/EC> · étiquette incohérente — <ids TC>.
Une ligne avec plusieurs problèmes prend le premier qui s'applique dans cet ordre après couvert. Un trou dans la propre liste AC du ticket est une lacune au niveau de la spécification, pas une ligne de matrice — signalez-le sous À améliorer comme une question de spécification (voir DOIT / NE JAMAIS).
Les AC/EC barrés ne comptent pas. Une ligne que le ticket a barrée (ex. -AC_07-, souvent marquée comme doublon) est hors de portée : laissez-la hors de la matrice et hors du rapport entièrement. Ne la mentionnez pas, même pas comme « correctement non couvert ».
Les règles métier et les commentaires de ticket sont du contexte, pas des AC supplémentaires. Lisez-les pour comprendre ce que signifie un AC/EC, et utilisez-les pour juger si un TC teste la bonne chose. Signalez un élément de règle métier ou de commentaire uniquement lorsqu'il entre en conflit avec un AC/EC, et nommez l'AC/EC avec lequel il est en contradiction. Une règle ou un commentaire qui n'a pas de TC mais ne contredit aucun AC/EC n'est pas une constatation. Laissez-le hors de À améliorer, et n'ajoutez pas de section « notes de spécification » pour cela.
Signalez, avec les identifiants de ligne/AC nommés :
- un AC/EC avec zéro TC ;
- un TC dont le Résultat attendu correspond vérifiablement à un différent AC que celui avec lequel il est étiqueté ;
- le même thème (ex. un élément UI partagé) étiqueté de manière incohérente entre des lignes frères — certains portent un AC, d'autres n'en portent pas, sans raison indiquée.
Étape 3 — Vérification de la qualité des lignes [liberté moyenne]
Appliquez tc-quality-standards.md à chaque ligne, en lisant pour ces formes d'échec spécifiques à la révision (distinctes de la qualité de rédaction — il s'agit ici d'un document écrit par quelqu'un d'autre, donc la question est de savoir si on peut lui faire confiance, pas s'il est élégant) :
| Signal | Pourquoi c'est important |
|---|---|
| Les étapes n'atteignent pas l'état revendiqué par le titre. Une ligne intitulée « L'apprenant voit X » dont les étapes s'arrêtent à la page principale n'ouvre jamais réellement X. | Le cas ne peut pas vérifier ce qu'il prétend vérifier. |
| Le Résultat attendu est la propre phrase de l'AC, copiée textuellement, sans décomposition. Lorsque le ticket liste plusieurs sous-éléments concrets (champs, états, variantes de bouton) sous cet AC, un Résultat attendu qui se contente de répéter la phrase de l'AC ne donne rien au testeur à vérifier ligne par ligne. | La réussite/échec devient une supposition. |
| L'AC énumère des cas/états nommés (ex. « cas 1–6 », états « chargement / vide / filtre ») et le document a une ligne générique pour tous. | La plupart des états énumérés ne sont pas testés même si la ligne est marquée comme terminée. |
| Les Données de test n'ont pas de valeur concrète là où l'AC en a besoin (un nombre limite, une relation de date spécifique, une option de filtre nommée). | La ligne ne peut pas être exécutée telle qu'écrite — le testeur devrait inventer la valeur manquante. |
| La ligne teste une condition différente du libellé de l'AC. L'AC dit « déjà fait défiler au-delà » mais la ligne utilise « regardé jusqu'à la fin ». L'AC dit « uniquement les éléments publiés » mais le Résultat attendu ne vérifie jamais le statut. | La ligne peut réussir alors que la propre condition de l'AC reste non testée. |
| Le Résultat attendu est plus vague que ce que les Données de test de la ligne permettent. Les Données de test donnent toutes les entrées nécessaires pour calculer la réponse (scores, décomptes, une formule), mais le Résultat attendu dit seulement « trié correctement ». | Le testeur doit trouver la valeur attendue en cours d'exécution, donc un mauvais ordre peut encore être marqué comme réussi. |
| Les colonnes de la ligne se contredisent. La Précondition dit « 4 éléments » mais les Données de test en listent 3. Le titre dit « statut » mais le Résultat attendu vérifie uniquement l'ordre. | Quelle que soit la colonne que le testeur suit, l'autre est erronée. |
| Une Précondition de ticket manque dans chaque ligne (ex. « l'utilisateur est connecté »). | Chaque ligne hérite d'une étape de configuration non énoncée. |
| La configuration nomme une méthode sans la fournir (« il existe un moyen de faire échouer la demande », « préparer suffisamment de données »). | Deux testeurs la configureront de deux manières différentes. |
Ne signalez pas les choix de style de cas de test qui n'affectent pas la confiance dans le cas (convention de nommage, ordre des colonnes, étiquettes de priorité) sauf si l'utilisateur demande explicitement une révision de style. Cela remplace tc-quality-standards.md ici : ignorez son attribut Priorité et sa ligne de porte de révision « Priorités attribuées » sauf si l'utilisateur demande une révision de style.
Étape 3b — Parcours des sources avant « demander au PO / rapporteur » (obligatoire) [faible liberté]
Ce workflow ne décide jamais d'un verdict produit, mais il soulève des lacunes et des questions au niveau de la spécification. Avant qu'une constatation ne devienne « demander au PO / rapporteur » ou « spécification peu claire », exécutez le parcours des sources dans la couche 14 de result-quality-gate.md : le code produit sur la branche par défaut avec path:line, ses commentaires en ligne et git log -L / blame ; le ticket principal et chaque commentaire ; les tickets environnants (parent / epic, liés, frères sur le même écran ou API, et les tickets nommés dans les messages de commit) ; les résultats de régression ; et le nœud de conception. Citez ce qui a été lu à côté de la constatation. Une question à laquelle les sources répondent déjà est une constatation avec sa source, pas une question.
Clone produit manquant ou illisible (la vérification {MONOREPO} dans dependencies.md échoue) : n'arrêtez pas la révision et ne sautez pas silencieusement la couche de code. Écrivez code non vérifié — aucun clone à côté de chaque question à laquelle la couche de code aurait répondu, continuez le parcours avec les sources restantes, et ne présentez jamais une telle question comme parcourue complètement — elle va à l'étape 4 en portant cette note.
Sortie par élément : la constatation (ou la question restante) + la source citée avec son emplacement (path:line, clé de ticket + commentaire, ligne de régression, nœud de conception), ou la note code non vérifié — aucun clone lorsque la couche de code n'a pas pu s'exécuter.
Revenir à : Une question à laquelle le parcours répond retourne à l'étape 2 ou 3 comme une constatation sourcée ; seule une question à laquelle aucune source ne répond va à l'étape 4 comme « confirmer avec le dev/PO ».
Étape 4 — Rapport Bon vs À améliorer [liberté moyenne]
Deux listes courtes, chaque puce ancrée à un identifiant de ligne, un identifiant AC ou un texte cité — jamais une opinion non ancrée.
**Bon**
- {constatation, avec id TC/AC ou citation}
**À améliorer**
- {constatation, avec id TC/AC ou citation}
→ Suggestion : {comment le corriger}
Chaque puce À améliorer porte une ligne « → Suggestion : » qui dit comment la corriger. Un problème sans correctif laisse l'auteur TC deviner. Chaque suggestion doit provenir d'une source, jamais d'une valeur inventée :
- Calculée à partir des propres données de la ligne : lorsque les Données de test contiennent déjà les entrées, calculez la valeur et donnez-la (ex. l'ordre attendu avec chaque score calculé). Montrez les nombres pour que l'auteur puisse les vérifier.
- Tirée du libellé AC/EC : ex. remplacez la condition erronée par la propre phrase de l'AC, ou ajoutez la clause manquante du Résultat attendu en utilisant le propre texte de l'AC.
- Aucune source ne donne la valeur (un seuil, un décompte ou un timing que le ticket ne précise jamais) : suggérez d'ajouter la valeur et dites qui la confirme (« confirmer le décompte avec le dev/PO »). N'inventez jamais un nombre.
Gardez chaque puce concise. La suggestion dit quoi changer, pas une ligne réécrite. Si l'utilisateur demande de réduire la portée (ex. « laissez tomber tout ce qui concerne X »), régénérez la liste à partir des étapes 2–3 avec cette catégorie supprimée — ne modifiez pas la prose réactive à la main, car la même catégorie refera surface autrement libellée la prochaine fois.
Langue : par défaut, utilisez la langue du ticket / document TC. Mixte = les AC/EC du ticket et le document TC sont rédigés dans des langues différentes → demandez une fois à l'utilisateur dans quelle langue rédiger la révision. Les menus Helix et les questions de prise en charge restent en anglais selon user-communication.md ; le contenu de la révision lui-même suit la langue du document de destination, la même exception que ce document porte déjà.
Publiez la révision dans le chat avant l'envoi de l'étape 5 — un message externe ne peut pas être annulé comme un message de chat. La question de fil de l'étape 5 est le feu vert ; n'ajoutez pas une question « l'envoyer ? » séparément.
Étape 5 — Notifier le canal TC-review du projet [faible liberté]
Chaque exécution envoie la révision terminée au canal TC-review
…
[Le contenu a été tronqué pour la traduction — poursuivez avec le reste si nécessaire]