# Modèle de stratégie de test

*Kit Ismail 3000 · version 1.0 · à copier et compléter. Les passages en italique sont des consignes à remplacer.*

## 1. Contexte

| Élément | À compléter |
| --- | --- |
| Produit | *Nom du produit et description en une phrase* |
| Utilisateurs | *Qui l'utilise, combien, sur quels appareils* |
| Équipe | *Nombre de devs, QA, PO ; rythme de livraison* |
| Enjeux | *Ce qui coûte cher en cas de bug : argent, données, image, réglementaire* |
| Date et version du document | |

## 2. Objectifs qualité

*Trois à cinq objectifs mesurables, alignés sur les enjeux.*

- Aucun bug bloquant sur les parcours critiques en production.
- Une régression détectée avant la mise en production dans *X* % des cas.
- Un retour des tests en moins de *X* minutes à chaque pull request.

## 3. Périmètre

| Dans le périmètre | Hors périmètre |
| --- | --- |
| *Applications, modules, API, plateformes testés* | *Ce qui ne sera pas testé, et pourquoi* |

## 4. Analyse des risques

*Listez les fonctionnalités, notez la probabilité et l'impact de 1 à 3, puis multipliez. Les risques notés 6 et 9 sont prioritaires.*

| Fonctionnalité | Probabilité (1-3) | Impact (1-3) | Score | Priorité |
| --- | --- | --- | --- | --- |
| *Paiement* | | | | |
| *Inscription / connexion* | | | | |
| | | | | |

## 5. Parcours critiques

*Les parcours qui ne doivent jamais casser. Ils sont testés à chaque livraison et automatisés en premier.*

1. *Parcours 1*
2. *Parcours 2*
3. *Parcours 3*

## 6. Niveaux et types de test

| Niveau | Qui | Outils | Quand |
| --- | --- | --- | --- |
| Tests unitaires | Devs | *Jest, JUnit...* | À chaque commit |
| Tests d'API / intégration | Devs, QA | *Postman, Karate, Playwright API...* | À chaque pull request |
| Tests de bout en bout | QA | *Playwright, Cypress, Maestro...* | À chaque pull request (parcours critiques), chaque nuit (suite complète) |
| Tests exploratoires | QA, PO | Sessions chronométrées | Chaque sprint |
| Non fonctionnel | *Qui* | *k6, Lighthouse, axe...* | *Fréquence* |
| Tests des fonctionnalités IA | QA | *Jeu de scénarios, LLM évaluateur* | À chaque changement de prompt ou de modèle |

## 7. Automatisation

- **Ce qu'on automatise d'abord** : les parcours critiques et les régressions déjà rencontrées.
- **Ce qu'on n'automatise pas** : *écrans très instables, tests ponctuels...*
- **Intégration CI** : *outil de CI, déclencheurs, temps d'exécution cible*.
- **Règle de stabilité** : un test instable est réparé ou retiré de la suite bloquante sous *X* jours.

## 8. Environnements et données de test

| Environnement | Usage | Données |
| --- | --- | --- |
| *Recette / staging* | *Tests de bout en bout et recette* | *Jeux de données anonymisés, comptes de test* |
| | | |

## 9. Critères d'entrée et de sortie

- **Une fonctionnalité entre en test quand** : *critères d'acceptation écrits, build déployé, tests unitaires verts*.
- **Une version part en production quand** : *zéro bug bloquant ouvert, parcours critiques verts, checklist de recette déroulée*.

## 10. Gestion des anomalies

- Outil : *Jira, Linear, GitHub Issues...*
- Modèle de ticket : étapes, résultat obtenu, résultat attendu, environnement, capture.
- Sévérités : **Bloquant** (corrigé avant livraison), **Majeur** (corrigé dans le sprint), **Mineur** (priorisé au backlog).

## 11. Indicateurs suivis

| Indicateur | Cible | Fréquence |
| --- | --- | --- |
| Couverture des parcours critiques automatisés | *X %* | Chaque sprint |
| Taux de tests instables | *< X %* | Chaque sprint |
| Durée de la suite de tests en CI | *< X min* | Chaque sprint |
| Bugs trouvés en production | *Tendance à la baisse* | Chaque mois |

## 12. Rôles

| Rôle | Responsabilités |
| --- | --- |
| *QA* | *Stratégie, automatisation, recette, indicateurs* |
| *Devs* | *Tests unitaires, correction, revue des tests* |
| *PO* | *Critères d'acceptation, validation fonctionnelle* |

---

*Ce modèle est libre d'utilisation dans vos projets. Retrouvez d'autres kits et des articles sur la QA augmentée par l'IA sur ismail3000.*