Les nouveaux testeurs entendent souvent ces deux termes utilisés comme s’ils signifiaient la même chose. Ce n’est pas le cas. La différence entre un cas de test et un scénario de test réside principalement dans le niveau de détail, et sa compréhension vous aide à décider de la quantité d’écriture avant de commencer les tests.

Ce guide explique chacun d’eux, puis fonctionne via une seule fonctionnalité de réinitialisation de mot de passe, des exigences aux scénarios en passant par les cas de test complets. La fonctionnalité et ses règles sont un exemple inventé. La terminologie varie également un peu selon les équipes et les outils, alors convenez de la signification de ces mots dans votre propre équipe.

La réponse courte

Un scénario de test décrit une situation à vérifier, telle que “vérifier qu’un utilisateur peut réinitialiser un mot de passe oublié”. Il s’agit généralement d’une seule ligne et laisse les détails au testeur.

Un cas de test explique précisément comment vérifier une condition dans cette situation : les conditions préalables, les étapes, les données de test et le résultat attendu. Deux testeurs qui le suivront devraient parvenir au même verdict.

Pensez à planifier un voyage. Le scénario est “Voyage de Pune à Delhi”. Le cas test est l’itinéraire complet, avec le numéro de vol, l’heure de départ et ce qu’il faut faire à chaque étape.

Cas de test et scénario de test côte à côte

Qu’est-ce qu’un scénario de test ?

Un scénario de test est une brève description de quelque chose qu’un utilisateur peut faire ou d’une situation que le système doit gérer. Il se concentre sur ce qui compte de l’extérieur et découle généralement directement d’une exigence ou d’une user story.

Les scénarios sont précieux car ils sont rapides. Vous pouvez en énumérer une trentaine dans le temps nécessaire à la rédaction de trois cas détaillés, ce qui en fait un excellent moyen de revoir la couverture avec un Product Owner : « avons-nous pensé à tout ? Un lecteur non technique peut suivre une liste de scénarios sans problème.

Qu’est-ce qu’un cas de test ?

Un scénario de test est un ensemble de conditions et d’étapes spécifiques, utilisées pour déterminer si une chose fonctionne. Un scénario de test typique contient :

• Un ID unique et un titre clair
• Conditions préalables, c’est-à-dire ce qui doit être vrai avant de commencer
• étapes numérotées
• Données de test spécifiques
• Un résultat attendu
• Le résultat réel et le statut, renseignés lors de l’exécution

Les cas de test brillent lorsque la cohérence compte. Un nouveau membre de l’équipe peut les exécuter, les résultats peuvent être comparés entre les versions et vous disposez d’un enregistrement de ce qui a été vérifié. Nous approfondissons notre guide sur comment rédiger des cas de test.

Une fonctionnalité, du début à la fin

Étape 1 : L’exigence

Les utilisateurs qui oublient leur mot de passe peuvent demander un lien de réinitialisation par e-mail. Le lien fonctionne une fois et expire au bout de 30 minutes. Un nouveau mot de passe doit comporter au moins 8 caractères.

Étape 2 : Les scénarios de tests

Regardez TS-02. L’exigence ne précise jamais ce qui devrait arriver avec un e-mail inconnu, et la rédaction du scénario a révélé cette lacune. La page doit-elle révéler que l’adresse n’est pas enregistrée ? Pour des raisons de sécurité, cela ne devrait généralement pas être le cas, car cela permet aux attaquants de découvrir des comptes valides. Trouver ces questions dès le début est l’un des plus grands avantages de la rédaction de scénarios.

Étape 3 : Les cas de tests

Maintenant, nous étendons uniquement le TS-05 aux cas de test. Un scénario devient plusieurs :

Ces valeurs n’étaient pas aléatoires. TC-051 et TC-052 se situent de chaque côté de la limite, en utilisant l’analyse des valeurs limites, et les autres proviennent du partitionnement d’équivalence.

Un modèle de cas de test

Voici TC-052 rédigé dans son intégralité. Copiez cette mise en page si votre équipe n’a pas encore de standard :

ID:            TC-052
Title:         Reset rejects a password of 7 characters
Scenario:      TS-05 New password rules are enforced
Priority:      High
Preconditions: Account asha@example.com exists
               A valid, unused reset link has been requested
Test data:     New password: abcd123

Steps:
  1. Open the reset link from the email
  2. Enter abcd123 in New password
  3. Enter abcd123 in Confirm password
  4. Click Reset password

Expected:      Error "Password must be at least 8 characters"
               Password is unchanged, and the link stays valid
Actual:        (filled in during the run)
Status:        (Pass / Fail / Blocked)

Notez que le résultat attendu vérifie plus que le message d’erreur. Cela confirme également que l’ancien mot de passe fonctionne toujours et que le lien reste utilisable. Les cas de test faibles s’arrêtent souvent à ce qui est visible à l’écran.

Où ils s’intègrent dans l’ensemble

Traditionnellement, les scénarios et les cas sont rédigés pendant la phase de conception des tests du cycle de vie des tests logiciels.

Quand utiliser chacun

Les scénarios suffisent souvent lorsque :

• L’équipe est petite, expérimentée et connaît bien le produit.
• Le temps presse ou les exigences changent fréquemment.
• La fonctionnalité présente un faible risque.
• Vous souhaitez revoir rapidement la couverture avec les parties prenantes.
• Vous guidez les tests exploratoires.

Les cas de test détaillés en valent la peine lorsque :

• Une panne serait coûteuse, comme pour les paiements, la sécurité ou les données de santé.
• Les régulateurs ou les auditeurs ont besoin de preuves de ce qui a été testé.
• Les testeurs nouveaux ou externalisés doivent exécuter les tests.
• Les résultats doivent être répétés exactement, comme dans une suite de régression.
• Les étapes deviendront des tests automatisés.

La plupart des équipes matures utilisent les deux. Ils énumèrent des scénarios pour tout et rédigent des cas complets uniquement pour les risques les plus élevés. Il n’est pas nécessaire de documenter chaque étape d’une page de paramètres à faible risque de la même manière qu’un virement bancaire.

Scénarios, cas et automatisation

Un scénario de test bien rédigé correspond presque directement à un test automatisé. Les conditions préalables deviennent une configuration, les étapes deviennent des actions et le résultat attendu devient une assertion. Les frameworks de développement axés sur le comportement utilisent même le mot « Scénario » pour leurs spécifications exécutables :

Scenario: Reset rejects a short password
  Given I have opened a valid reset link
  When I submit the new password "abcd123"
  Then I see "Password must be at least 8 characters"
  And my password is unchanged

Curieusement, ce que BDD appelle un scénario est beaucoup plus proche d’un cas de test, car il contient des données et des résultats spécifiques. C’est un bon rappel pour convenir des conditions. Pour automatiser ces vérifications, consultez notre Tutoriel Playwright ou notre Tutoriel Pytest.

Qu’est-ce qui les rend bons

Erreurs courantes

• Écrire uniquement des chemins heureux. La plupart des bogues se trouvent dans des conditions d’erreur, alors incluez ce qui devrait échouer.
• Utilisation de résultats attendus vagues. “Cela devrait fonctionner correctement” permet à n’importe quel testeur de décider de n’importe quoi.
• Documenter tout dans son intégralité. Des milliers de cas que personne ne maintient sont pires qu’un petit ensemble utile.
• Sauter des scénarios. Passer directement aux cas peut laisser des zones entières oubliées.
• Laisser les cas devenir obsolètes. Lorsque le produit change, les anciens cas induisent les gens en erreur. Examinez-les régulièrement.
• Lier les étapes à des détails fragiles. “Cliquez sur le bouton bleu en haut” rompt avec toute refonte.

Pour conclure

Les scénarios vous donnent de l’ampleur et les cas de test vous donnent de la profondeur. Commencez par des scénarios pour votre prochaine fonctionnalité et examinez-les avec un développeur et un propriétaire de produit. Ensuite, développez uniquement les cas à risque dans des cas complets. Vous découvrirez des lacunes plus tôt et vous passerez votre temps à écrire là où cela compte.

Questions fréquentes

Continuez à apprendre