Comment organiser efficacement le référentiel vs les plans de test ?

1. Classer les tests par sprint → bonne ou mauvaise idée ?

⚠️ En général ce n’est pas recommandé de classer les cas de test par sprint, car :

  • Les sprints sont temporaires, alors que les tests doivent être pérennes et réutilisables.
  • Nous risquons d’avoir des doublons (le même test peut concerner SP1, SP2, SP3 → nous finissons par le copier plusieurs fois).
  • Cela casse l’idée que le référentiel est une bibliothèque stable de tous les tests disponibles.

👉 Les sprints doivent plutôt être gérés via des plans de tests, pas dans la structure du référentiel.

2. Critères de classification les plus courants dans le référentiel

Les bonnes pratiques privilégient des critères stables dans le temps, par ex. :

  • Par fonctionnalité / user story / exigence (ex. : “Authentification”, “Paiement”, “Recherche produit”).
  • Par module ou composant applicatif (ex. : “Front-end”, “Back-end”, “API”).
  • Par type de test (ex. : “Tests fonctionnels”, “Tests non régression”, “Tests d’intégration”).
  • Par processus métier (ex. : “Création de compte”, “Commander un produit”, “Livraison”).
  • Par criticité ou priorité (utile pour organiser des régressions ciblées).

👉 Le but est que, dans 6 mois ou 1 an, notre référentiel reste logique et exploitable sans être dépendant d’un sprint qui n’existe plus.

3. Plans de tests basés sur ces critères

Oui ✅, les plans de tests peuvent (et devraient) exploiter ces critères :

  • Par sprint / release : un plan “Sprint 5”, qui sélectionne uniquement les tests des fonctionnalités livrées dans ce sprint.
  • Par type de campagne : un plan “Régression”, qui reprend tous les tests classés comme critiques + existants depuis plusieurs versions.
  • Par module : un plan “Tests API”, qui cible uniquement les tests du dossier “API”.
  • Par criticité : un plan “Smoke tests”, qui reprend seulement les tests hautement prioritaires.

👉 Ainsi :

  • Le référentiel reste organisé de façon stable.
  • Les plans permettent de construire des campagnes dynamiques, adaptées à chaque contexte (sprint, release, régression, etc.).