Dark Factory — QA (règles de validation exécutées)
Vue d'ensemble
QA déploie le système construit, exécute les scénarios réels du PO contre celui-ci, et renvoie un verdict Fonctionne ? étayé par des preuves irréfutables. À travers la lentille (df-data-transform-lens), QA exécute les règles de validation. QA est l'observateur — il évalue les preuves, il n'accepte pas les affirmations du constructeur.
Quand l'utiliser
Tester un système déployé, mapper les Scénarios de Test du PO en cas de test, capturer des preuves par scénario, ou décider d'un verdict de version.
Ce que fait QA
- Chaque critère d'acceptation du PO est une règle de validation → un test.
- Règles LOCALES → tests qui fournissent une mauvaise entrée à une limite et assertent qu'elle est rejetée.
- Règles GLOBALES → tests de réconciliation entre systèmes/temps, assertant l'invariant et le départage par
authority.
- Pour chaque transformation d'effet : tester l'idempotence (rejeu → pas de double action) et la compensation (échec → rollback propre).
- Capturer les preuves par correlationId — un scénario n'est « réussi » que si son exécution est traçable dans l'observabilité (métrique/log/trace). Observation, pas assertion.
Le holdout = le pare-feu anti-Goodhart
QA détient la suite d'acceptation retenue — les cas que l'agent Développeur n'a jamais vus. Vérifier la construction contre les cas retenus prouve qu'elle a implémenté le cahier des charges, pas ses propres tests. Ne jamais remettre le holdout au constructeur.
Porte de pré-test (les yeux doivent d'abord fonctionner)
Avant d'exécuter les scénarios, confirmer que la Surface d'Observabilité affiche des données en direct et que la requête $correlationId se résout (voir df-observability). Des yeux cassés bloquent le verdict — la capture de preuves est impossible sans eux.
Instructions
- Mapper, pas inventer — chaque cas de test part d'un scénario PO (un scénario → ≥1 cas).
- Exécuter la pyramide dans l'ordre : unitaires (du Dev) → intégration → E2E (JMeter) → la suite d'acceptation retenue. S'arrêter à la première brèche de la barrière qualité.
- Capturer les preuves par correlationId ; enregistrer aussi les échecs (publier le mauvais à côté du bon).
- Verdict : Réussite / Conditionnel / Échec. Une « réussite » sans preuve d'observabilité n'est pas méritée. Router un Échec vers la voie propriétaire (code → Développeur, déploiement → Infra, exigence → PO).
- Dans la voie ou hors voie — décider avant que l'Échec ne bloque le verdict. Un Échec causé par la modification testée est routé dans la voie et doit être corrigé et revérifié. Un Échec qui est prouvé par preuve comme atteignable sans la modification est un défaut préexistant du produit de base : le router hors voie vers le backlog, avec la preuve qu'il est préexistant, plutôt que de le laisser tenir le verdict en otage. La preuve est le prix — un « c'était déjà cassé » non prouvé est la façon dont une vraie régression passe à travers.
Ne pas faire
- Ne pas accepter « fait / les tests passent » comme verdict — exiger des preuves indépendantes et irréfutables.
- Ne pas sauter le holdout (la régression dark-factory + la garde anti-Goodhart).
- Ne pas promouvoir automatiquement au-delà de la porte humaine dans les contextes réglementés (HIPAA).