RafaelFerSilva/refinement-agent-skills

Plan de QA

Dérivez le plan de test de base pour une User Story grâce à un examen socratique : conditions de test avec techniques de conception déclarées, résultats attendus assertés uniquement lorsque les spécifications les soutiennent, et questions adressées à la personne capable de résoudre le reste. Vous ne demandez pas "cette histoire est-elle bien écrite ?", cela relève de /refine-story. Vous répondez : qu'est-ce qui peut casser, comment prouver que cela fonctionne, et qu'est-ce qui doit exister pour exécuter cette preuve.

Un ingénieur QA de niveau intermédiaire devrait pouvoir implémenter les tests directement à partir de cet artefact ; un ingénieur QA senior devrait approuver sa priorisation.

US : $ARGUMENTS

Limite en trois couches

Dériver des conditions non écrites est l'essence même du QA, à condition que cela suive des méthodes établies. Par conséquent, la limite ici opère sur trois couches ; le fondement reste requirements-rigor. Chaque condition du plan appartient exactement à une couche :

• [SPÉCIFIÉ : extrait] (pt-BR : [ESPECIFICADO : trecho]) : la condition et le résultat attendu proviennent directement du texte. Citez la source.
• [DÉRIVÉ : technique] (pt-BR : [DERIVADO : técnica]) : la condition découle d'une technique de conception de test appliquée à ce qui a été spécifié. Nommez toujours la technique ; une condition sans technique déclarée est une supposition et ne doit pas entrer. Les résultats attendus ne peuvent être assertés que s'ils découlent logiquement de la spécification.
• [INDÉFINI -> Question n] (pt-BR : [INDEFINIDO → Pergunta n]) : une condition légitime dont le résultat attendu n'est pas défini par la spécification. La condition entre dans la matrice ; le résultat devient une question numérotée.

Test rapide : "Quelle technique a généré cette condition, et de quel extrait provient-elle ?" Si l'une des deux réponses ne peut être donnée, excluez-la du plan.

Avant de commencer

Lisez docs/agents/refinement.md dans l'espace de travail : il définit le mode de fonctionnement (avec ou sans code), la langue (en-US ou pt-BR, par défaut en-US) et les chemins de publication. Le mode dicte qui répond aux questions architecturales : avec code, vous les résolvez en inspectant la base de code ; sans code, l'équipe d'ingénierie les résout via des questionnaires. L'examen socratique et le plan de QA sont rédigés dans la langue configurée. Si le fichier est manquant, demandez /configure-refinement et arrêtez-vous.

Étapes

1. Charger. Lisez la US, CONTEXT.md, les ADR du domaine, TEST-DESIGN.md, et invoquez l'outil Skill pour requirements-rigor. Si .scratch/<slug>/spec.md existe à partir de /refine-story, commencez par celui-ci : les décisions de cette session répondent déjà à de nombreuses questions. Sans ce fichier, traitez la US comme non raffinée, même si Status : indique READY. Terminé quand : le triage de testabilité est énoncé en une seule ligne : TESTABLE (tous les résultats attendus ont un point d'observation et aucune dépendance n'est en attente de confirmation), TESTABLE AVEC RÉSERVES (les conditions peuvent être dérivées, mais au moins un résultat manque de point d'observation ou dépend de dépendances non confirmées), ou NON TESTABLE.

2. Trier. NON TESTABLE (les critères ne décrivent pas un comportement observable : tâches exclusives, ou termes subjectifs sans métriques pour tous les critères) : expliquez ce qui manque, listez 3 à 5 questions minimales et recommandez /refine-story. Arrêtez-vous ici ; analyser du matériel non testable produit des plans de façade. Si la US n'a pas subi de raffinement, indiquez-le et poursuivez, en notant que de nombreuses questions seraient résolues par /refine-story. Terminé quand : le triage est déclaré.

3. Dériver les conditions. Pour chaque critère, appliquez les techniques applicables de TEST-DESIGN.md, en évitant de forcer des techniques inapplicables, et examinez les angles silencieux, en ne rapportant que les angles applicables. Construisez la matrice : condition, origine, résultat attendu ou [INDÉFINI -> Question n], priorité, couche. Les conditions indéfinies restent dans la matrice : une couverture future visible est bien meilleure que des lacunes cachées. Numérotez les questions en une seule séquence combinée PO et DEV, afin que [INDÉFINI -> Question n] soit résolu sans ambiguïté. Les justifications de priorité (une demi-ligne par condition) vont dans une liste dans la section d'analyse des risques, pas à l'intérieur du tableau. Terminé quand : chaque condition a une origine déclarée et chaque [INDÉFINI] a un numéro de question assigné.

4. Chercher des faits avant de demander. Séparez les questions par destinataire. PO : comportement métier indéfini. DEV : architecture, observabilité, couche de test, isolement des dépendances externes, contrôle du temps, provisionnement des données de test, réponse d'erreur API, persistance après échec, idempotence technique. En mode code, envoyez un sous-agent pour répondre aux questions DEV en lisant le code : la notification est-elle synchrone ou asynchrone ? y a-t-il un verrou sur l'approbation ? existe-t-il un mock pour le système externe ? Un fait trouvé devient un résultat attendu ou une couche définie, avec citation de la source. En mode sans code, la recherche est limitée aux fichiers de l'espace de travail sans sous-agents ; si rien n'est trouvé, énoncez-le en une seule ligne en haut du tour 1. Terminé quand : chaque question est marquée comme répondue par une source ou ouverte, avec destinataire assigné.

5. Examiner le PO. Invoquez l'outil Skill pour socratic-examination. Le tour de questions accompagne la matrice actuelle, car les questions font référence à des conditions spécifiques. La frontière se compose des questions PO, d'abord les éléments bloquants (ceux qui débloquent les conditions P1), chacun avec une réponse recommandée lorsque les spécifications fournissent une base ; en leur absence, fournissez "aucune recommandation" (ou "sem recomendação" en pt-BR) et des options. Les réponses du PO mettent immédiatement à jour la matrice. Contestez les termes par rapport au glossaire, mais enregistrez dans CONTEXT.md uniquement ce que le PO résout. Terminé quand : la frontière des questions PO est vide, ou le PO demande la clôture.

6. Synthétiser. Rédigez le plan suivant TEMPLATE.md : matrice, analyse des risques, scénarios P1 en Gherkin avec auto-audit, audit d'automatisabilité, impact de régression basé strictement sur la documentation système existante (sans contexte, listez les questions d'impact pour DEV), questions restantes par destinataire, verdict de couverture. Terminé quand : le fichier existe au chemin défini par docs/agents/refinement.md avec l'avertissement final présent.

7. Router les éléments ouverts. Questions DEV ouvertes en mode sans code et questions PO ouvertes qui n'ont pas pu être répondues : rédigez un questionnaire par destinataire suivant QUESTIONNAIRE.md dans requirements-rigor, en parallèle du plan, et liez les fichiers à partir des questions ouvertes. Terminé quand : aucune question ouverte ne reste sans destinataire ou questionnaire.

8. Rapporter. Verdict, où le plan a été publié, nombre de conditions P1 exécutables, et ce que chaque questionnaire débloque.

Avis final

⚠️ Cette sortie fournit la base analytique d'un plan de test, et non le plan de test final. Les décisions sur la couverture, la priorisation et l'effort appartiennent à l'équipe QA, avec validation du PO (comportements indéfinis) et du Dev (architecture et couches).