📖 Manuel

Test Strategy Planner

Workflow

1. Analyser le contexte du projet

Recueillir avant toute chose :

• Type d'application : API REST, SPA, mobile natif, microservices, batch…
• Stack technique et frameworks de test disponibles
• Contraintes réglementaires : PCI-DSS, RGPD, ISO 27001, HIPAA…
• Délais, budget QA, effectif QA vs Dev
• Niveau de maturité actuel (aucun test, legacy sans CI, CI partielle…)

Décision rapide :

2. Définir la pyramide de tests

Proportion cible selon le contexte :

              [E2E / UI]        ~10 %   lents, coûteux, fragiles
           [Intégration]        ~20 %   API, BDD, contrats
        [Unitaires]             ~70 %   rapides, isolés, stables

Pour un projet microservices, substituer une partie des E2E par des tests de contrat (Pact) :

              [E2E smoke]       ~5 %
        [Contrats Pact]         ~15 %
    [Intégration service]       ~20 %
  [Unitaires]                   ~60 %

3. Appliquer les quadrants de tests agiles (Agile Testing Quadrants)

Vérifier qu'au moins un quadrant par sprint est couvert ; Q3 et Q4 sont souvent négligés.

4. Analyse de risques (Risk-Based Testing)

Matrice risque = probabilité × impact :

         │ Impact faible │ Impact élevé
─────────┼───────────────┼──────────────────
Proba    │               │
élevée   │  Surveiller   │  ★ Tester en priorité
─────────┼───────────────┼──────────────────
Proba    │               │
faible   │  Ignorer      │  Tester si temps dispo

Exemples de zones à haut risque à identifier : paiements, authentification, calculs métier critiques, intégrations tierces instables.

Template Markdown pour la matrice :

| Fonctionnalité | Probabilité (1-5) | Impact (1-5) | Score | Couverture cible |
|---|---|---|---|---|
| Paiement carte | 3 | 5 | 15 | Unitaire + Intégration + E2E |
| Rapport PDF | 2 | 2 | 4 | Unitaire seul |

5. Planifier la couverture de tests

Objectifs de couverture recommandés :

Configurer Istanbul/NYC (JS/TS) :

// package.json
"jest": {
  "coverageThreshold": {
    "global": { "lines": 80, "branches": 70, "functions": 80 }
  },
  "coveragePathIgnorePatterns": ["generated/", "migrations/"]
}

JaCoCo (Java/Kotlin) — build.gradle :

jacocoTestCoverageVerification {
  violationRules {
    rule { limit { minimum = 0.80 } }
  }
}

Coverlet (.NET) :

dotnet test --collect:"XPlat Code Coverage" \
  /p:Threshold=80 /p:ThresholdType=line

Bloquer le pipeline CI si les seuils ne sont pas atteints.

6. Définir les environnements et données de test

Environnements :

Stratégie données :

• Utiliser des builders / fixtures factories (ex : FactoryBot, Bogus .NET, Faker.js) plutôt que des dumps SQL figés.
• Anonymiser systématiquement les dumps de production (RGPD) : outil recommandé faker + script de masquage.
• Versionner les seeds avec les migrations pour éviter les drifts.

7. Établir les critères d'entrée et de sortie

Critères d'entrée (pour démarrer les tests d'intégration/E2E) :

• Build CI vert
• Tests unitaires passants ≥ seuil défini
• Environnement de test disponible et configuré
• User stories avec critères d'acceptance définis

Critères de sortie (Definition of Done QA) :

• Couverture ≥ seuils définis
• 0 bug bloquant / critique ouvert
• Tests de régression passants
• Rapport de test généré et archivé
• Tests de performance dans les SLA définis

Niveaux de sévérité de défauts :

8. Intégrer la stratégie dans le CI/CD

Pipeline type (GitHub Actions / Azure DevOps) :

stages:
  - name: unit-tests        # < 2 min — bloque le merge
  - name: lint-and-coverage # contrôle seuils
  - name: integration-tests # < 10 min — bloque le merge
  - name: e2e-smoke         # < 5 min — bloque le déploiement
  - name: performance       # planifié nightly
  - name: security-scan     # OWASP ZAP, Snyk — planifié nightly

Garde-fous et anti-patterns

• Faux sentiment de sécurité du coverage : 90 % de couverture sans assertions utiles ne détecte rien. Préférer la mutation testing (Stryker, PITest) pour valider la qualité des tests.
• Trop d'E2E : Chaque test E2E coûte 10x à 100x plus qu'un test unitaire en maintenance. Supprimer les E2E redondants dès qu'un test d'intégration couvre la même logique.
• Tests couplés à l'implémentation : Tester les comportements observables, pas les détails internes. Un refactoring ne doit pas casser les tests si le comportement est inchangé.
• Données de test en dur dans le code : utiliser des factories/fixtures pour éviter les tests fragiles et les conflits entre runs parallèles.
• Ignorer les tests flaky : Un test instable masque des problèmes réels. Politique stricte : quarantaine immédiate + fix dans le sprint courant.
• Stratégie figée : Réviser la stratégie à chaque release majeure ou changement d'architecture. C'est un document vivant.

Bonnes pratiques 2026

• Shift-left : intégrer les tests dès la phase de design (Test-Driven Development, BDD avec Gherkin).
• AI-assisted testing : utiliser les outils de génération de tests (Diffblue, CodiumAI, GitHub Copilot) pour accélérer la couverture des cas limites — toujours relire et valider les tests générés.
• Observabilité comme filet de sécurité : traces distribuées (OpenTelemetry) + alertes en production complètent la stratégie de test.
• Chaos engineering léger : dès la staging, injecter des pannes simulées (Toxiproxy pour les dépendances réseau) pour valider la résilience.
• Test contracts first : pour les APIs exposées à des partenaires, définir le contrat OpenAPI avant l'implémentation et le valider en CI (Schemathesis, Dredd).