Cas de Test vs Scénario de Test: Différence et Quand Utiliser Chacun

Un scénario de test décrit ce qu'il faut vérifier en une phrase. Un cas de test fournit la procédure complète pour le faire, y compris les étapes exactes, les données de test, les préconditions et les résultats attendus.

La version simple

Scénario de test : une description de haut niveau de ce qu'il faut vérifier. Une phrase ou un énoncé bref. Cas de test : une spécification détaillée de comment le vérifier, avec les étapes exactes, les données de test et les résultats attendus.

Un scénario de test est la question. Un cas de test est la procédure complète pour y répondre.

Scénarios de test

Un scénario de test décrit un comportement utilisateur ou une condition système à tester, sans spécifier les étapes exactes. Il est rédigé du point de vue de l'utilisateur et se concentre sur le "quoi", pas le "comment".

Exemples pour une fonctionnalité de connexion :

L'utilisateur peut se connecter avec des identifiants valides
L'utilisateur ne peut pas se connecter avec un mot de passe incorrect
L'utilisateur ne peut pas se connecter avec un e-mail non enregistré
Le compte est bloqué après 5 tentatives de connexion échouées
L'utilisateur peut se connecter depuis un navigateur mobile
La session expire après 30 minutes d'inactivité
L'utilisateur peut se connecter avec Google OAuth

Chacun de ces points est un scénario. Remarquez qu'ils ne précisent pas :

Quel navigateur utiliser
Quel e-mail spécifique saisir
Où exactement cliquer
Ce que dit exactement le message d'erreur attendu

Les scénarios sont utiles pour planifier la couverture : s'assurer qu'on n'a manqué aucun parcours utilisateur important. Ils sont rapides à rédiger et faciles à revoir avec les stakeholders métier qui ne s'intéressent pas aux détails d'implémentation.

Cas de test

Un cas de test est une spécification complète et reproductible. N'importe qui avec le cas de test et un accès au système doit pouvoir l'exécuter exactement et obtenir le même résultat.

Exemple de cas de test pour "L'utilisateur ne peut pas se connecter avec un mot de passe incorrect" :

| Champ | Contenu |

|---|---|

| ID du cas de test | TC-LOGIN-003 |

| Titre | La connexion échoue avec un mot de passe incorrect |

| Préconditions | Le compte utilisateur existe : qa_test@example.com (enregistré, non bloqué) |

| Données de test | E-mail : qa_test@example.com / Mot de passe : WrongPass123! |

| Étapes | 1. Aller sur /login 2. Saisir l'e-mail qa_test@example.com 3. Saisir le mot de passe WrongPass123! 4. Cliquer sur "Se connecter" |

| Résultat attendu | Le message d'erreur "E-mail ou mot de passe incorrect" est visible. L'utilisateur reste sur la page de connexion. |

| Postconditions | Le compteur de tentatives de connexion échouées augmente de 1 |

Ce niveau de détail signifie :

Un testeur junior peut l'exécuter sans avoir à deviner
Le test peut être reproduit exactement s'il échoue
Les résultats peuvent être comparés dans le temps (régression)
Il peut être automatisé sans ambiguïté

Pourquoi les deux existent

Scénarios sans cas de test = planification de la couverture sans cohérence d'exécution. Vous savez quoi tester mais l'exécution varie entre les testeurs. Un testeur utilise un e-mail valide pour le test "mot de passe incorrect", un autre utilise un e-mail inexistant : résultats différents, bugs différents trouvés. Cas de test sans scénarios = vous pouvez vous perdre dans les étapes et perdre de vue la couverture. Vous pourriez avoir 50 cas de test détaillés et manquer quand même des flux utilisateur entiers.

En pratique, la plupart des équipes les utilisent en séquence :

1. Rédiger les scénarios d'abord, les revoir avec les PMs et développeurs, confirmer la couverture

2. Développer les scénarios prioritaires en cas de test complets, exécuter de façon systématique

Quand utiliser quoi

Utiliser les scénarios de test quand

En début de planification. Avant que la fonctionnalité soit construite, vous pouvez rédiger des scénarios pour aligner l'équipe sur ce qui doit être testé. Pas besoin de connaître encore les URLs exactes ou les libellés des boutons. Pour les tests exploratoires. Les scénarios fonctionnent comme des chartes légères pour les sessions exploratoires. "Explorer la connexion avec diverses entrées invalides" est une direction suffisante. Pour les revues des stakeholders. Les stakeholders métier et les chefs de produit peuvent revoir une liste de scénarios et dire "oui, nous devons aussi tester X". Ils ne se perdent pas dans les détails étape par étape. Pour la cartographie de la couverture. Une liste de scénarios donne une vue rapide de ce qui est couvert et ce qui manque.

Utiliser les cas de test quand

Pour les tests de régression. Les tests exécutés à plusieurs reprises à travers les releases doivent être cohérents. Les cas de test garantissent que la même chose est testée de la même façon à chaque fois. Pour l'intégration de nouveaux testeurs. Un nouveau membre de l'équipe peut prendre un cas de test et l'exécuter correctement dès le premier jour. Pour la conformité et l'audit. Les industries réglementées (banque, médical, aérospatiale) exigent souvent des preuves de ce qui a été testé exactement et de ce qui a réussi. Les scénarios seuls ne suffisent pas. Pour l'automatisation. L'automatisation convertit les cas de test en code. Si votre cas de test est vague, votre automatisation le sera aussi.

Différentes équipes, différents mots

La terminologie varie selon les équipes :

Certaines appellent ce qu'on appelle "scénarios" des idées de test ou chartes de test
Certaines utilisent "cas de test" pour désigner tout test, qu'il soit détaillé ou non
Certaines équipes Agile rédigent des critères d'acceptation (sur les user stories) qui servent le même objectif que les scénarios
Le format BDD/Gherkin (Given/When/Then) fait le pont : il est structuré comme un cas de test mais lisible comme un scénario

Ce qui compte plus que l'étiquette, c'est l'objectif : le format léger (scénario/idée) sert à planifier la couverture, le format détaillé (cas de test/spécification) à exécuter de façon cohérente.

Exemple pratique : fonctionnalité de checkout

Étape 1 : rédiger les scénarios

L'utilisateur peut finaliser le checkout avec une carte de crédit valide
L'utilisateur ne peut pas faire le checkout avec une carte expirée
L'utilisateur ne peut pas faire le checkout avec un CVV invalide
Le total de la commande inclut la taxe correcte pour la région de l'utilisateur
L'utilisateur reçoit une confirmation par e-mail après un checkout réussi
Les articles en rupture de stock ne peuvent pas être commandés
Le formulaire de checkout valide les champs requis

Étape 2 : prioriser

Marquez les scénarios à haut risque (traitement des paiements, validation de l'inventaire) comme "rédiger des cas de test détaillés". Marquez les scénarios à faible risque comme "exploratoires : tester si le temps le permet".

Étape 3 : rédiger les cas de test pour les scénarios prioritaires

Pour "L'utilisateur ne peut pas faire le checkout avec une carte expirée", rédigez :

Les préconditions (utilisateur connecté, articles dans le panier, numéros de carte de test disponibles)
Les données de test exactes (numéro de carte, mois/année d'expiration, CVV)
Les étapes détaillées (naviguer vers le checkout, remplir la livraison, remplir les champs de carte, soumettre)
Le résultat attendu (texte du message d'erreur, paiement non débité, panier conservé)

Résumé

| | Scénario de test | Cas de test |

|---|---|---|

| Niveau de détail | Haut niveau | Étape par étape |

| Se concentre sur | Ce qu'il faut tester | Comment le tester |

| Rédigé par | QA, PM, équipe | Ingénieur QA |

| Utilisé pour | Planification, couverture | Exécution, régression |

| Temps de rédaction | Rapide (minutes) | Plus long (détaillé) |

| Audience | Toute l'équipe | Testeurs, automatisation |

Commencez par les scénarios pour vous assurer d'avoir la bonne couverture. Rédigez des cas de test pour ce que vous testerez à plusieurs reprises, automatiserez, ou devrez prouver que ça a fonctionné. Évitez les cas de test pour les zones où les tests exploratoires suffisent.

Aucun format n'est supérieur par nature : le bon choix dépend du risque, du processus de l'équipe, et de ce que le test est censé accomplir.