qa360 2.2.1 → 2.2.7

package/docs/QA360_TESTING_PHILOSOPHY.md

@@ -1,769 +0,0 @@
-# QA360 Testing Philosophy
-## Le Guide de Référence des Best Practices de l'Industrie
-
-**Version** : 1.0  
-**Date** : Janvier 2026  
-**Auteur** : QA360 Core Team  
-
----
-
-## 🎯 Vision
-
-> **"Quality is not an act, it's a habit."** — Aristote
-
-QA360 n'est pas simplement un outil d'exécution de tests. C'est une **plateforme de confiance** qui incarne les meilleures pratiques de l'industrie du testing, validées par Google, Netflix, Microsoft et les leaders mondiaux du développement logiciel.
-
-Ce document établit les **principes fondamentaux** que QA360 promeut et implémente pour permettre à n'importe quel membre d'une équipe IT de créer et maintenir des suites de tests professionnelles.
-
----
-
-# PARTIE A : Les 7 Piliers du Testing Moderne
-
-## Pilier 1 : La Pyramide de Test (Google)
-
-### Le Principe
-
-```
-                    ┌─────┐
-                    │ E2E │  10% — Lents, coûteux, fragiles
-                   ─┴─────┴─
-                  │Integration│  20% — Équilibre confiance/vitesse
-                 ─┴───────────┴─
-                │   Unit Tests   │  70% — Rapides, isolés, nombreux
-               ─┴─────────────────┴─
-```
-
-**Source** : Google Testing Blog, Software Engineering at Google (Chapter 14)
-
-> *"It is critical for longer-term health to move toward the test pyramid within the first few days of development by building out unit tests."*
-
-### Application QA360
-
-QA360 **ne remplace pas** les frameworks de unit tests (Jest, Vitest, pytest). QA360 **orchestre et certifie** les résultats de tous les niveaux de la pyramide :
-
-| Niveau | Framework | Rôle QA360 | Statut |
-|--------|-----------|------------|--------|
-| Unit | Jest, Vitest, pytest | Ingestion des résultats, preuve | ⚠️ **v2.2** |
-| Integration | Playwright API, Supertest | Exécution native via adapters | ✅ Disponible |
-| E2E | Playwright UI | Exécution native via adapters | ✅ Disponible |
-
-### Roadmap Ingestion Unit Tests (v2.2)
-
-```yaml
-# pack.yml - Ingestion résultats Jest/Vitest
-gates:
-  unit-tests:
-    adapter: vitest  # ou jest, pytest
-    config:
-      results: ./test-results/vitest-results.json
-      coverage: ./coverage/coverage-final.json
-      thresholds:
-        statements: 80%
-        branches: 70%
-```
-
-**Effort** : 1 semaine  
-**Impact** : ⭐⭐⭐⭐⭐ (Ouvre 90% du marché)
-
-**Métrique QA360** : Le rapport de run inclut une analyse de distribution pour guider l'équilibre de la pyramide.
-
----
-
-## Pilier 2 : Séparation Données / Comportement
-
-### Le Principe
-
-> *"Improve test readability by separating test data from test logic. Enable easy management of different data scenarios across your test suite."*
-> — Playwright Best Practices
-
-Les tests maintenables séparent **trois préoccupations** :
-
-```
-┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
-│   TEST DATA     │     │   PAGE OBJECTS  │     │   TEST SPECS    │
-│   (fixtures/)   │     │   (pages/)      │     │   (specs/)      │
-├─────────────────┤     ├─────────────────┤     ├─────────────────┤
-│ users.yml       │     │ LoginPage.ts    │     │ auth.spec.ts    │
-│ products.json   │     │ CartPage.ts     │     │ checkout.spec.ts│
-│ environments.yml│     │ CheckoutPage.ts │     │ search.spec.ts  │
-└─────────────────┘     └─────────────────┘     └─────────────────┘
-       │                        │                       │
-       └────────────────────────┼───────────────────────┘
-                                │
-                         COMBINAISON
-                                │
-                    ┌───────────┴───────────┐
-                    │   TEST EXÉCUTABLE     │
-                    │   (maintenable)       │
-                    └───────────────────────┘
-```
-
-### Pourquoi c'est crucial
-
-| Sans séparation | Avec séparation |
-|-----------------|-----------------|
-| Données hardcodées dans les tests | Données dans fichiers dédiés |
-| Changer un email = modifier 50 fichiers | Changer un email = modifier 1 fichier |
-| Tests illisibles | Tests auto-documentés |
-| Seul l'auteur comprend | Toute l'équipe comprend |
-
-### Application QA360
-
-QA360 supporte nativement les **fixtures de données** :
-
-```yaml
-# fixtures/users.yml
-testUsers:
-  buyer:
-    email: buyer@acme.test
-    password: Buyer123!
-    role: buyer
-  admin:
-    email: admin@acme.test
-    password: Admin456!
-    role: admin
-```
-
-```yaml
-# pack.yml
-fixtures:
-  - ./fixtures/users.yml
-
-gates:
-  login-buyer:
-    adapter: playwright-ui
-    config:
-      data: $fixtures.testUsers.buyer
-```
-
----
-
-## Pilier 3 : Page Object Model (Playwright/Selenium)
-
-### Le Principe
-
-> *"Page Object Model helps write clean, maintainable tests by separating page interactions from test logic. It reduces code duplication, improves readability, and makes large test suites easier to manage."*
-> — Playwright Documentation
-
-Un **Page Object** encapsule :
-- Les **sélecteurs** d'une page (locators)
-- Les **actions** possibles sur cette page (méthodes)
-- La **logique de navigation**
-
-```typescript
-// pages/LoginPage.ts
-export class LoginPage {
-  readonly page: Page;
-  
-  // Locators centralisés
-  readonly emailInput = () => this.page.locator('#email-signin');
-  readonly passwordInput = () => this.page.locator('#password-signin');
-  readonly submitButton = () => this.page.locator('button[type="submit"]');
-  readonly errorMessage = () => this.page.locator('.error-alert');
-
-  constructor(page: Page) {
-    this.page = page;
-  }
-
-  // Actions réutilisables
-  async login(email: string, password: string) {
-    await this.emailInput().fill(email);
-    await this.passwordInput().fill(password);
-    await this.submitButton().click();
-  }
-
-  async expectError(message: string) {
-    await expect(this.errorMessage()).toContainText(message);
-  }
-}
-```
-
-### Pourquoi c'est crucial
-
-| Sans POM | Avec POM |
-|----------|----------|
-| `page.click('#login-btn')` répété 100x | `loginPage.submit()` |
-| Sélecteur change = 100 modifications | Sélecteur change = 1 modification |
-| Tests = code spaghetti | Tests = documentation vivante |
-| Onboarding : 2 semaines | Onboarding : 2 heures |
-
-### Application QA360
-
-QA360 supporte **deux approches** pour les Page Objects :
-
-**Approche 1 : Import TypeScript (recommandé)**
-
-```yaml
-gates:
-  e2e-checkout:
-    adapter: playwright-ui
-    config:
-      pageObjects:
-        import: ./pages/*.ts
-        runtime: node
-      tests:
-        - use: LoginPage
-          call: login
-          args: [$data.email, $data.password]
-        - use: CartPage
-          call: addProduct
-          args: [$data.product.sku]
-```
-
-**Approche 2 : Déclaration YAML (sans TypeScript)**
-
-```yaml
-gates:
-  e2e-checkout:
-    adapter: playwright-ui
-    config:
-      pageObjects:
-        LoginPage:
-          url: /signin
-          selectors:
-            email: "#email-signin"
-            password: "#password-signin"
-            submit: "button[type='submit']"
-          methods:
-            login:
-              - fill: [email, $data.email]
-              - fill: [password, $data.password]
-              - click: submit
-      tests:
-        - use: LoginPage
-          call: login
-```
-
-**Choix de l'approche** :
-- **TypeScript** : Pour équipes avec expertise dev, meilleure maintenabilité
-- **YAML** : Pour équipes non-dev, onboarding rapide
-
----
-
-## Pilier 4 : Factory Pattern pour la Génération
-
-### Le Principe
-
-> *"Factory Method: Instead of calling the constructor directly to create a page object, the Factory Method is called to get an instance. This is useful if the creation process is complex or needs to be repeated."*
-> — Design Patterns in Testing
-
-Le **Factory Pattern** permet de :
-- Générer des structures de test **consistantes**
-- Standardiser l'organisation du code
-- Faciliter l'onboarding des nouveaux membres
-
-```
-qa360 ai generate --factory=e2e-auth --site=https://example.com
-                           │
-                           ▼
-           ┌───────────────────────────────┐
-           │   FACTORY: e2e-auth           │
-           │   ─────────────────────       │
-           │   Template standardisé pour   │
-           │   l'authentification E2E      │
-           └───────────────────────────────┘
-                           │
-                           ▼
-    ┌──────────────────────────────────────────────┐
-    │ tests/                                       │
-    │ ├── fixtures/                                │
-    │ │   └── auth.fixture.ts   ← Factory auth    │
-    │ ├── pages/                                   │
-    │ │   ├── LoginPage.ts      ← Page Object     │
-    │ │   └── RegisterPage.ts   ← Page Object     │
-    │ ├── data/                                    │
-    │ │   └── users.json        ← Données séparées│
-    │ └── specs/                                   │
-    │     └── auth.spec.ts      ← Tests propres   │
-    └──────────────────────────────────────────────┘
-```
-
-### Application QA360
-
-Les factories QA360 disponibles :
-
-| Factory | Génère | Usage |
-|---------|--------|-------|
-| `smoke` | Tests de smoke basiques | Validation rapide |
-| `e2e-auth` | Suite authentification complète | Login, register, reset |
-| `e2e-crud` | Suite CRUD complète | Create, Read, Update, Delete |
-| `a11y` | Suite accessibilité | WCAG 2.1 compliance |
-| `security` | Suite sécurité | OWASP Top 10 |
-
----
-
-## Pilier 5 : Test Isolation (Playwright/Google)
-
-### Le Principe
-
-> *"Test isolation is critical for ensuring that test results are reliable and not influenced by other tests. A common mistake is creating test data in one test and deleting it in another."*
-> — Playwright Best Practices
-
-Chaque test doit être :
-- **Indépendant** : Peut s'exécuter seul
-- **Idempotent** : Produit le même résultat à chaque exécution
-- **Isolé** : N'affecte pas les autres tests
-
-```
-❌ ANTI-PATTERN                    ✅ BEST PRACTICE
-─────────────────                  ─────────────────
-Test 1: Create user               Test 1: Create user → use → delete
-Test 2: Use created user          Test 2: Create user → use → delete
-Test 3: Delete user               Test 3: Create user → use → delete
-        │                                 │
-        ▼                                 ▼
-Fragile, ordre dépendant          Robuste, parallélisable
-```
-
-### Application QA360
-
-Chaque **gate** QA360 est isolée par design :
-- Contexte navigateur frais
-- Pas de state partagé entre gates
-- Setup/Teardown explicites via hooks
-
-```yaml
-gates:
-  test-a:
-    hooks:
-      before: [setup-user]
-      after: [cleanup-user]
-    # ...
-  
-  test-b:
-    hooks:
-      before: [setup-user]  # Indépendant de test-a
-      after: [cleanup-user]
-    # ...
-```
-
----
-
-## Pilier 6 : Preuves Cryptographiques (QA360 Exclusif)
-
-### Le Principe
-
-> *"Trust, but verify."* — Proverbe russe
-
-Les rapports de test traditionnels peuvent être **falsifiés**. Un fichier HTML ou JSON peut être modifié après coup. Dans les contextes réglementés (santé, finance, aérospatial), cela pose un problème légal.
-
-QA360 résout ce problème avec des **preuves cryptographiques** :
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│                    PREUVE QA360                             │
-├─────────────────────────────────────────────────────────────┤
-│  Run ID        : run-1768175039928-muhzvtb1p                │
-│  Timestamp     : 2026-01-12T15:30:39.928Z                   │
-│  Gates         : 9/9 passed                                 │
-│  Trust Score   : 100/100                                    │
-│                                                             │
-│  ┌─────────────────────────────────────────────────────┐   │
-│  │  SHA-256 Hash                                       │   │
-│  │  a7f3b2c8d9e1f0a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8  │   │
-│  └─────────────────────────────────────────────────────┘   │
-│                                                             │
-│  ┌─────────────────────────────────────────────────────┐   │
-│  │  Ed25519 Signature                                  │   │
-│  │  Base64: xK9mN2pQ3rS4tU5vW6xY7zA8bC9dE0fG1hI2jK3l  │   │
-│  └─────────────────────────────────────────────────────┘   │
-│                                                             │
-│  ✅ Vérifiable offline : qa360 verify proof.json            │
-│  ✅ Valeur juridique   : Conforme FDA 21 CFR Part 11        │
-│  ✅ Infalsifiable      : Toute modification invalide la     │
-│                          signature                          │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### Conformité Réglementaire
-
-| Standard | QA360 Status | Concurrent typique |
-|----------|--------------|-------------------|
-| FDA 21 CFR Part 11 | ✅ Conforme aux exigences de traçabilité | ❌ Non conforme |
-| ISO/IEC/IEEE 29119 | ✅ 85% conforme | ⚠️ Partiel |
-| SOX (Finance) | ✅ Audit trail complet | ❌ Pas de preuve |
-| RGPD Art. 30 | ✅ Traçabilité | ⚠️ Variable |
-
-**Note juridique** : Les preuves QA360 constituent une **preuve technique probante pour audits** grâce aux signatures Ed25519 et hash SHA-256. Pour une valeur juridique complète dans un contexte spécifique, consultez votre service juridique.
-
-### Application QA360
-
-Chaque run génère automatiquement une preuve :
-
-```bash
-qa360 run pack.yml
-# → .qa360/runs/run-xxx-proof.json
-
-qa360 verify .qa360/runs/run-xxx-proof.json
-# → ✅ Signature Ed25519 valide
-# → ✅ Hash SHA-256 intact
-# → ✅ Conforme FDA 21 CFR Part 11
-```
-
----
-
-## Pilier 7 : Résilience et Chaos Engineering (Netflix)
-
-### Le Principe
-
-> *"Chaos Engineering is a discipline that focuses on testing the limits and vulnerabilities of a system by intentionally injecting chaos. The goal is to uncover weaknesses before they impact real users."*
-> — Netflix Engineering
-
-Netflix a créé **Chaos Monkey** pour tester la résilience de ses systèmes en production. Ce principe peut s'appliquer aux tests :
-
-- **Latency Injection** : Que se passe-t-il si l'API répond en 5 secondes au lieu de 200ms ?
-- **Error Injection** : Que se passe-t-il si 10% des requêtes échouent ?
-- **Timeout Testing** : L'application gère-t-elle correctement les timeouts ?
-
-### Application QA360 (Roadmap)
-
-```yaml
-gates:
-  resilience-test:
-    adapter: chaos-basic
-    config:
-      target: https://api.example.com
-      scenarios:
-        - type: latency
-          inject: 2000ms
-          endpoints: ["/api/checkout"]
-        - type: error-rate
-          inject: 10%
-          endpoints: ["/api/products"]
-      thresholds:
-        success_rate: 95%
-        p95_latency: 3000ms
-```
-
-**Note** : Cette fonctionnalité est avancée et sera disponible dans QA360 v3.x.
-
----
-
-# PARTIE B : Implémentation QA360
-
-## 🎯 La Différenciation QA360
-
-QA360 se distingue par **trois axes** :
-
-```
-                    ┌─────────────────────────────────┐
-                    │       CONFIANCE ABSOLUE         │
-                    │   Preuves cryptographiques      │
-                    │   Ed25519 + SHA-256             │
-                    │   Valeur juridique              │
-                    └─────────────────────────────────┘
-                                   │
-              ┌────────────────────┼────────────────────┐
-              │                    │                    │
-              ▼                    ▼                    ▼
-┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
-│  STRUCTURE NATIVE   │ │  AUTOMATISATION     │ │  ORCHESTRATION      │
-│  ─────────────────  │ │  INTELLIGENTE       │ │  UNIFIÉE            │
-│  • Data Fixtures    │ │  ─────────────────  │ │  ─────────────────  │
-│  • Page Objects     │ │  • AI Generation    │ │  • Multi-adapters   │
-│  • Factory Pattern  │ │  • Factory Templates│ │  • API + UI + Perf  │
-│  • Test Isolation   │ │  • Smart Retry      │ │  • Security + A11y  │
-└─────────────────────┘ └─────────────────────┘ └─────────────────────┘
-         │                       │                       │
-         └───────────────────────┼───────────────────────┘
-                                 │
-                    ┌────────────┴────────────┐
-                    │    MAINTENABILITÉ       │
-                    │    LONG TERME           │
-                    │    ─────────────────    │
-                    │    N'importe quel       │
-                    │    membre de l'équipe   │
-                    │    peut contribuer      │
-                    └─────────────────────────┘
-```
-
----
-
-## 📋 Features à Implémenter
-
-### Sélection Prioritaire
-
-Basé sur l'analyse des best practices, voici mon **jugement** sur ce qui doit être implémenté :
-
-| Feature | Priorité | Impact Maintenabilité | Impact Unicité | Effort | Verdict |
-|---------|----------|----------------------|----------------|--------|--------|
-| **Unit Tests Ingestion** | 🔴 P0 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | 1 sem | ✅ **v2.2** |
-| **Data Fixtures** | 🔴 P0 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | 3 jours | ✅ **v2.2** |
-| **Page Object Reference** | 🔴 P0 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | 5 jours | ✅ **v2.2** |
-| **Factory Templates AI** | 🟠 P1 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | 1 sem | ✅ **v2.3** |
-| **Test Distribution Score** | 🟢 P2 | ⭐⭐⭐ | ⭐⭐ | 2 jours | ⏳ Quick win |
-| **Chaos Testing** | ⚪ P3 | ⭐⭐ | ⭐⭐⭐⭐ | 2+ sem | ❌ Reporté v3.x |
-
----
-
-### Feature 1 : Data Fixtures System
-
-**Objectif** : Séparer les données de test de la logique
-
-**Spec** :
-
-```yaml
-# fixtures/b2b-shop.yml
-environments:
-  staging:
-    baseUrl: https://staging.b2bshop.com
-  production:
-    baseUrl: https://b2bshop.lovable.app
-
-users:
-  buyer:
-    email: buyer@acme.test
-    password: Buyer123!
-    role: buyer
-  admin:
-    email: admin@acme.test
-    password: Admin456!
-    role: admin
-
-products:
-  laptop:
-    sku: "LAPTOP-PRO-15"
-    name: "Laptop Pro 15"
-    price: 1299.99
-  mouse:
-    sku: "MOUSE-WIRELESS"
-    name: "Wireless Mouse"
-    price: 49.99
-```
-
-```yaml
-# pack.yml
-version: 2
-name: b2b-shop-tests
-
-fixtures:
-  - ./fixtures/b2b-shop.yml
-
-gates:
-  buyer-login:
-    adapter: playwright-ui
-    config:
-      baseUrl: $fixtures.environments.staging.baseUrl
-      login:
-        email: $fixtures.users.buyer.email
-        password: $fixtures.users.buyer.password
-```
-
-**Bénéfices** :
-- ✅ Changer d'environnement = 1 ligne
-- ✅ Modifier un utilisateur = 1 fichier
-- ✅ Tests lisibles et auto-documentés
-- ✅ Onboarding simplifié
-
-**Effort** : 3 jours
-
----
-
-### Feature 2 : Page Object Reference
-
-**Objectif** : Permettre de référencer des Page Objects TypeScript/JavaScript depuis YAML
-
-**Spec** :
-
-```typescript
-// pages/LoginPage.ts
-import { Page, Locator } from '@playwright/test';
-
-export class LoginPage {
-  readonly page: Page;
-  readonly emailInput: Locator;
-  readonly passwordInput: Locator;
-  readonly submitButton: Locator;
-
-  constructor(page: Page) {
-    this.page = page;
-    this.emailInput = page.locator('#email-signin');
-    this.passwordInput = page.locator('#password-signin');
-    this.submitButton = page.locator('button[type="submit"]');
-  }
-
-  async navigate() {
-    await this.page.goto('/signin');
-  }
-
-  async login(email: string, password: string) {
-    await this.emailInput.fill(email);
-    await this.passwordInput.fill(password);
-    await this.submitButton.click();
-  }
-
-  async expectDashboard() {
-    await this.page.waitForURL('**/dashboard');
-  }
-}
-```
-
-```yaml
-# pack.yml
-gates:
-  e2e-login:
-    adapter: playwright-ui
-    config:
-      baseUrl: $fixtures.environments.staging.baseUrl
-      pageObjects: ./pages/
-      
-      tests:
-        - name: "Buyer can login"
-          steps:
-            - use: LoginPage
-              call: navigate
-            - use: LoginPage
-              call: login
-              args: [$fixtures.users.buyer.email, $fixtures.users.buyer.password]
-            - use: LoginPage
-              call: expectDashboard
-```
-
-**Bénéfices** :
-- ✅ Sélecteurs centralisés
-- ✅ Réutilisation entre packs
-- ✅ IntelliSense / autocomplétion
-- ✅ Tests lisibles comme de la documentation
-
-**Effort** : 5 jours
-
----
-
-### Feature 3 : Factory Templates AI
-
-**Objectif** : L'IA génère des structures de test complètes, pas du code "plat"
-
-**Spec** :
-
-```bash
-qa360 ai generate --factory=e2e-auth --site=https://b2bshop.lovable.app/
-```
-
-**Output généré** :
-
-```
-✅ Analyse du site terminée
-   • 2 formulaires d'auth détectés
-   • Login: /signin
-   • Register: /signup
-
-📁 Structure générée :
-
-b2bshop-tests/
-├── fixtures/
-│   └── users.fixture.yml     # Utilisateurs de test
-├── pages/
-│   ├── LoginPage.ts          # Page Object Login
-│   ├── RegisterPage.ts       # Page Object Register
-│   └── DashboardPage.ts      # Page Object Dashboard
-├── data/
-│   └── test-users.json       # Données dynamiques
-├── specs/
-│   └── auth.pack.yml         # Pack QA360 prêt à l'emploi
-└── README.md                 # Documentation
-
-🚀 Pour exécuter :
-   cd b2bshop-tests && qa360 run specs/auth.pack.yml
-```
-
-**Factories disponibles** :
-
-| Factory | Description | Génère |
-|---------|-------------|--------|
-| `smoke` | Tests de base | 1 pack, pas de POM |
-| `e2e-auth` | Authentification | POM + fixtures + 5 tests |
-| `e2e-crud` | CRUD complet | POM + fixtures + 8 tests |
-| `e2e-checkout` | Parcours achat | POM + fixtures + 6 tests |
-| `a11y-audit` | Accessibilité | Pack A11y WCAG 2.1 |
-| `security-scan` | Sécurité | OWASP Top 10 |
-
-**Bénéfices** :
-- ✅ Structure professionnelle dès le départ
-- ✅ Best practices appliquées automatiquement
-- ✅ Pas besoin d'être expert testing
-- ✅ Différenciateur majeur vs concurrents
-
-**Effort** : 1 semaine
-
----
-
-## 🏆 Positionnement Final
-
-### Message Principal
-
-```
-╔═══════════════════════════════════════════════════════════════════╗
-║                                                                   ║
-║   QA360 — Quality as Cryptographic Proof                          ║
-║   ──────────────────────────────────────                          ║
-║                                                                   ║
-║   La seule plateforme de testing qui combine :                    ║
-║                                                                   ║
-║   ✅ PREUVES CRYPTOGRAPHIQUES                                     ║
-║      Ed25519 signatures — Valeur juridique                        ║
-║      Conforme FDA 21 CFR Part 11                                  ║
-║                                                                   ║
-║   ✅ BEST PRACTICES INTÉGRÉES                                     ║
-║      Data Fixtures — Page Objects — Factory Pattern               ║
-║      Maintenabilité garantie à long terme                         ║
-║                                                                   ║
-║   ✅ AUTOMATISATION INTELLIGENTE                                  ║
-║      AI-powered generation avec structure professionnelle         ║
-║      N'importe qui peut contribuer aux tests                      ║
-║                                                                   ║
-╚═══════════════════════════════════════════════════════════════════╝
-```
-
-### Tableau Comparatif
-
-| Critère | Playwright (seul) | Cypress | QA360 |
-|---------|-------------------|---------|-------|
-| Exécution E2E | ✅ | ✅ | ✅ |
-| Exécution Unit Tests | ❌ (autre outil) | ❌ (autre outil) | ⚠️ **Ingestion v2.2** |
-| Page Object Model | ⚠️ Manuel | ⚠️ Manuel | ✅ **Guidé/Généré** |
-| Data Fixtures | ⚠️ Manuel | ⚠️ Manuel | ✅ **Natif YAML** |
-| Multi-adapter | ❌ UI only | ❌ UI only | ✅ **API+UI+Perf+Sec** |
-| Preuves crypto | ❌ | ❌ | ✅ **Ed25519** |
-| Conformité FDA | ❌ | ❌ | ✅ **Traçabilité conforme** |
-| AI Generation | ❌ | ❌ | ✅ **Factory-based** |
-
----
-
-## 📚 Références
-
-### Sources Officielles
-
-1. **Google**
-   - [Software Engineering at Google - Chapter 14](https://abseil.io/resources/swe-book/html/ch14.html)
-   - [Google Testing Blog - SMURF](https://testing.googleblog.com/2024/10/smurf-beyond-test-pyramid.html)
-   - [Just Say No to More End-to-End Tests](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html)
-
-2. **Netflix**
-   - [Chaos Engineering - Wikipedia](https://en.wikipedia.org/wiki/Chaos_engineering)
-   - [Chaos Monkey - Netflix](https://netflix.github.io/chaosmonkey/)
-   - [Testing in Production the Netflix Way](https://launchdarkly.com/blog/testing-in-production-the-netflix-way/)
-
-3. **Playwright/Microsoft**
-   - [Page Object Models](https://playwright.dev/docs/pom)
-   - [Test Fixtures](https://playwright.dev/docs/test-fixtures)
-   - [Best Practices](https://playwright.dev/docs/best-practices)
-
-4. **Standards**
-   - [FDA 21 CFR Part 11](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application)
-   - [ISO/IEC/IEEE 29119](https://en.wikipedia.org/wiki/ISO/IEC_29119)
-
-5. **Industrie**
-   - [Martin Fowler - Test Pyramid](https://martinfowler.com/bliki/TestPyramid.html)
-   - [Kent C. Dodds - Write tests. Not too many. Mostly integration.](https://kentcdodds.com/blog/write-tests)
-
----
-
-## 📝 Changelog
-
-| Version | Date | Changements |
-|---------|------|-------------|
-| 1.0 | Jan 2026 | Version initiale |
-
----
-
-*Ce document est maintenu par l'équipe QA360 Core et reflète les best practices de l'industrie au moment de sa rédaction.*