La plupart des cas de test échouent avant même d’avoir détecté le moindre bug. Ils sont rédigés sous forme de checklists vagues, ne mentionnent pas les conditions préalables, regroupent plusieurs actions en une seule étape ou décrivent les résultats attendus de manière si imprécise que deux testeurs lisant le même cas ne s’accorderaient pas sur la définition d’un « test réussi ». Conséquence : des bugs passent entre les mailles du filet, les exécutions de test ne peuvent pas être reproduites et l’assurance qualité devient un goulot d’étranglement au lieu d’un filet de sécurité.
Rédiger un bon scénario de test relève moins de la compétence en matière de tests que de la conception de la vérification. Dans le secteur des services financiers, on parle de « processus maker-checker ». Dans le domaine du commandement nucléaire, on parle de « règle des deux personnes ». Le principe est le même : une tâche critique ne doit jamais reposer sur une seule action non vérifiée. Un scénario de test bien rédigé intègre cette même rigueur dans le logiciel. Il sépare ce que vous attendez de ce que vous observez, de sorte que l'écart entre les deux devient impossible à ignorer.
Nous vous montrerons comment rédiger des cas de test, pourquoi ils sont importants et comment améliorer leur qualité au fil du temps.
En bref
Un scénario de test définit les étapes précises, les données d'entrée et les résultats attendus nécessaires pour vérifier qu'une fonctionnalité fonctionne correctement. Chaque scénario doit comporter un identifiant unique, des conditions préalables et des résultats attendus clairement formulés afin de pouvoir vérifier l'issue du test. Ce guide présente le processus de rédaction en sept étapes, trois exemples concrets et explique comment garantir la fiabilité d'une suite de tests à mesure que le produit évolue.
Que sont les cas de test ?
Un cas de test est un document structuré qui définit les étapes précises, les données d'entrée, les conditions préalables et les résultats attendus nécessaires pour vérifier si un logiciel spécifique se comporte correctement. Il ne s'agit ni d'un plan de test (qui décrit la stratégie de test) ni d'un script de test (un code automatisé qui exécute les étapes de manière programmatique). Un cas de test est la spécification à partir de laquelle ces deux éléments sont élaborés.
Exemple : Vous testez la fonctionnalité de connexion d'une application web. Un scénario de test pour cette fonctionnalité définirait les éléments suivants :
- Actions décrivant les étapes effectuées par un utilisateur et les réponses attendues du système
- Conditions définissant les règles qui doivent être respectées pour que le système puisse passer à l'étape suivante
- Saisissez des données avec des valeurs d'échantillon pour tester différents résultats et vérifier à la fois les scénarios de réussite et ceux qui échouent.
Comparaison entre les cas de test manuels et automatisés
L'IA fait désormais partie intégrante de la plupart des flux de travail de test. Selon le rapport « State of Testing 2026 » de PractiTest, 76,8 % des professionnels du test utilisent l'IA dans le domaine de l'assurance qualité, la création de cas de test (69,6 %) et la maintenance des scripts (59,6 %) étant les deux utilisations les plus courantes. C'est dans les cas de test automatisés que cette évolution est la plus visible ; il est donc utile de savoir en quoi ils diffèrent des cas de test manuels.
| Paramètre | Cas de test manuels | Cas de test automatisés |
|---|---|---|
| Exécution | Réalisés par un testeur humain qui suit une série d'étapes documentées | Exécutés par des outils logiciels, des scripts ou des agents IA |
| Rapidité | Lente et chronophage, car les données doivent être saisies manuellement et les résultats vérifiés par des personnes | Permet d'exécuter simultanément des centaines de cas de test |
| Répétabilité | Sujet aux erreurs humaines et à des interprétations incohérentes des étapes | Une grande répétabilité et une grande cohérence lorsque la maintenance des scripts de test est correctement effectuée |
| Intégration CI/CD | Difficile à intégrer dans des pipelines de livraison évoluant rapidement en raison de goulots d'étranglement humains | S'intègre directement dans les pipelines CI/CD pour exécuter des tests à chaque build |
| Maintenance | Nécessite des mises à jour manuelles des documents chaque fois que les exigences changent | Nécessite une maintenance technique pour mettre à jour les scripts lorsque l'interface utilisateur ou la logique change |
| Idéal pour | Tests exploratoires | Tests répétitifs et tests de régression |
Pourquoi il est important de bien rédiger ses cas de test
Vous détectez les régressions avant même que les utilisateurs ne signalent de problèmes. Chaque modification du code comporte le risque de perturber le fonctionnement d’un élément qui marchait déjà. Un scénario de test bien rédigé devient un point de contrôle permanent qui s’exécute après chaque déploiement. Lorsqu’un développeur refactorise votre code de connexion un an plus tard et perturbe accidentellement la gestion des sessions, c’est ce scénario de test qui le signale en environnement de préproduction.
Faites en sorte que la réussite ou l’échec soit un fait, et non une opinion. Des résultats attendus vagues tels que « le système répond de manière appropriée » obligent chaque testeur à interpréter ce que signifie « appropriée ». Deux testeurs exécutent le même scénario, l’un le marque comme réussi, l’autre signale un défaut, et l’équipe se retrouve alors à déboguer ce désaccord au lieu de déboguer le logiciel. Lorsque votre résultat attendu est « le système affiche le message d’erreur : “Mot de passe invalide” et maintient l’utilisateur sur la page de connexion », il n’y a aucune place pour l’interprétation. Soit le résultat correspond, soit il ne correspond pas. C’est la règle des deux personnes mise en pratique : le cas de test est le créateur, le testeur est le vérificateur, et tous deux doivent parler la même langue.
Vous transformez ainsi les connaissances tacites en un atout réutilisable. Dans la plupart des équipes, l’ingénieur QA senior détient une carte mentale de chaque cas limite, de chaque solution de contournement, de chaque « oh, n’oublie pas de vérifier aussi X ». Lorsque cette personne part en congé ou change d’équipe, cette carte mentale part avec elle. Des cas de test documentés, avec des préconditions et des valeurs limites explicites, permettent de préserver ces connaissances de manière structurée. Un nouveau testeur qui rejoint l’équipe peut prendre le cas de test TC_LOGIN_005 et tester le flux « verrouillage du compte après cinq tentatives » dès le premier jour, sans avoir à demander à personne quel est le seuil ni comment le chronomètre se réinitialise.
Vous isolez les échecs à des étapes précises, et non à des zones générales. Lorsqu’un scénario de test regroupe « accéder à la page, saisir les identifiants et cliquer sur Valider » en une seule étape et que le test échoue, tout ce que vous savez, c’est que « quelque chose s’est mal passé dans le flux de connexion ». » Lorsque chaque action constitue une étape distincte avec son propre résultat attendu, l’échec se situe à l’étape 4 : « Cliquer sur “Envoyer le lien de réinitialisation” → message de réussite attendu, erreur 500 obtenue. » Cette précision réduit considérablement le temps de débogage, car le développeur sait exactement quelle interaction a déclenché le défaut, et pas seulement dans quelle fonctionnalité il doit chercher.
Vous voyez ce qui est couvert et ce qui constitue un angle mort. Sans cas de test structurés, la couverture des tests reste aléatoire. Grâce à eux, vous pouvez mapper chaque cas à une exigence et repérer instantanément les lacunes. Si votre fonctionnalité de réinitialisation de mot de passe comporte six scénarios (réussite de la réinitialisation, lien expiré, lien réutilisé, adresse e-mail non enregistrée, format non valide, demandes multiples) et que vous ne disposez de cas de test que pour trois d’entre eux, la lacune est visible et quantifiable. C’est cette visibilité qui fait passer les tests de « nous l’avons testé » à « voici exactement ce que nous avons testé, voici ce que nous n’avons pas testé, et voici le risque que nous acceptons ».
Les éléments d'un bon scénario de test
Un scénario de test utile ne se contente pas de décrire ce qu'il faut tester. Il rend compte du contexte, des étapes d'exécution et du comportement attendu du système, afin qu'un autre testeur, développeur ou chef de produit puisse reproduire le test et en vérifier le résultat.
Les éléments constitutifs d'un scénario de test sont les suivants :
- Identifiant unique
- Objectif ou description
- Conditions préalables
- Étapes d'exécution
- Résultats attendus
- Résultats réels à titre de comparaison
Pour l'exemple d'une fonction de connexion au site web que nous avons partagé plus haut, votre scénario de test devrait inclure :
Identifiant du cas de test : Chaque cas de test doit disposer d’un identifiant unique. Lors du test d’une fonctionnalité, les équipes d’assurance qualité créent souvent plusieurs cas de test qui valident des conditions similaires. L’identifiant du cas de test permet de les suivre, de les organiser et de les référencer facilement lors du débogage ou de la création de rapports.
Exemple : TC_LOGIN_001
Description : Cette section explique quelle fonction le scénario de test est censé valider. Elle fournit un bref résumé afin que toute personne lisant le scénario de test en comprenne immédiatement l'objectif.
Exemple : Vérifier qu'un utilisateur enregistré peut se connecter correctement à l'application à l'aide d'identifiants valides.
Prérequis : Les prérequis décrivent l'état du système requis avant l'exécution du scénario de test. Sans eux, les testeurs risquent d'exécuter le même test dans des conditions différentes et d'obtenir des résultats incohérents.
Exemples :
- Le compte d'utilisateur doit déjà exister dans le système
- Le compte utilisateur doit être actif et ne pas être verrouillé
- La page de connexion doit être accessible
Étapes : il s'agit des actions qu'un utilisateur ou un testeur effectue pour exécuter le scénario de test. Chaque étape doit être claire et séquentielle afin que n'importe quel membre de l'équipe puisse reproduire le test.
- L'utilisateur accède à la page de connexion
- L'utilisateur saisit une adresse e-mail enregistrée
- L'utilisateur saisit le mot de passe correct
- L'utilisateur clique sur le bouton Connexion
Résultats attendus : cela définit ce que le système doit faire si la fonctionnalité fonctionne correctement.
- Si les identifiants sont valides, le système effectue l'authentification de l'utilisateur
- L'utilisateur est redirigé vers le tableau de bord
- Une session utilisateur a été créée avec succès
Si les identifiants ne sont pas valides, le système doit afficher le message d'erreur approprié.
Résultats réels : ils reflètent les observations du testeur après l'exécution du scénario de test. Si le comportement observé diffère du résultat attendu, le problème est enregistré comme un défaut.
Exemple d'observation :
- Vous avez saisi des identifiants valides, mais vous avez reçu une erreur « Mot de passe invalide »
Mettons maintenant en pratique vos compétences en rédaction de cas de test.
Le saviez-vous ? Seules 2,1 % des équipes qualifient leurs pratiques de test de l'IA d'optimisées, tandis que plus de 85 % en sont encore à l'étape initiale ou expérimentale. L'utilisation la plus courante consiste à générer des cas de test (69,6 %), et non à mener du travail stratégique tel que l'identification des risques (19,9 %).
Comment rédiger des cas de test (procédure étape par étape)
La rédaction d'un scénario de test se déroule en sept étapes : analyser l'exigence, établir une liste de scénarios, planifier la structure, rédiger les étapes avec les résultats attendus, ajouter une pièce jointe, faire valider le scénario, puis l'exécuter et consigner les résultats.
Étape 1 : Analyser les exigences
Avant de rédiger le scénario de test, assurez-vous de bien comprendre ce que la fonctionnalité est censée faire. C’est à ce stade que vous passez en revue les documents disponibles (cahiers des charges, récits d’utilisateurs, spécifications fonctionnelles et documents de conception) et que vous identifiez chaque fonctionnalité devant être vérifiée.
Exemple : Vous développez une fonctionnalité permettant aux utilisateurs de réinitialiser leur mot de passe par e-mail. Pour créer un scénario de test autour de cette fonctionnalité, vous devez comprendre :
- Quel problème cette fonctionnalité permet-elle de résoudre ? Autrement dit, un utilisateur peut-il récupérer l'accès à son compte s'il oublie son mot de passe ?
- Quelles actions l'utilisateur peut-il effectuer, c'est-à-dire demander un lien de réinitialisation, le recevoir par e-mail et définir un nouveau mot de passe ?
- Que doit-il se passer lorsque ces actions sont effectuées ? Autrement dit, le système envoie-t-il un lien de réinitialisation et permet-il à l'utilisateur de mettre à jour son mot de passe avec succès ?
- Y a-t-il des restrictions, c'est-à-dire le lien expire-t-il après un certain temps ou devient-il invalide après une seule utilisation ?
- Existe-t-il des validations ou des règles à respecter ? Par exemple, le nouveau mot de passe doit-il respecter des exigences spécifiques en matière de format ou de longueur ?
- Certaines fonctions sont-elles vagues ou mal définies ? Si tel est le cas, demandez des précisions aux parties prenantes concernées.
Cette clarté vous fournit les bases nécessaires pour définir un objectif précis pour votre scénario de test.
Objectif : Vérifier qu'un utilisateur inscrit peut réinitialiser son mot de passe par e-mail.
Étape 2 : Identifier différents scénarios de test
Ensuite, dressez la liste des scénarios de test que vous devez valider. Un scénario de test est une situation de haut niveau qui, en général, se décline en plusieurs cas de test couvrant différentes entrées et différents résultats.
Pour la fonctionnalité de réinitialisation du mot de passe, vos scénarios pourraient ressembler à ceci :
- Réinitialisation réussie : Vérifiez qu'un utilisateur enregistré peut demander un lien de réinitialisation et définir un nouveau mot de passe
- Adresse e-mail non enregistrée : Testez ce qui se passe lorsqu'un e-mail n'existant pas dans le système est envoyé.
- Lien expiré : Vérifiez que le système bloque l'accès lorsque l'on clique sur le lien de réinitialisation après son expiration.
- Lien réutilisé : Vérifier qu'un lien de réinitialisation déjà utilisé ne peut pas être réutilisé
- Nouveau mot de passe non valide : Vérifiez que les mots de passe ne respectant pas les exigences de format sont rejetés
- Demandes de réinitialisation multiples : Testez quel lien reste valide lorsqu'un utilisateur en demande plusieurs d'affilée
Chaque scénario présenté ici se traduira par un ou plusieurs cas de test couvrant des entrées et des conditions spécifiques. Décomposer la fonctionnalité de cette manière vous garantit une couverture de test à la fois pour les comportements attendus et pour les cas limites auxquels les utilisateurs réels seront inévitablement confrontés.
Étape 3 : Planifier le test et définir la structure des cas de test
Pour les tests de régression répétitifs, vous avez besoin d'une structure qui vous permette de documenter vos cas de test et leurs résultats de manière cohérente. Un modèle de cas de test bien défini apporte cette cohérence et permet la réutilisation sans avoir à repartir de zéro à chaque fois.
Planifiez l'exécution de vos tests en clarifiant les éléments suivants :
Qui va réaliser le test ?
Quel rôle ou quelle qualification la personne chargée de ce test doit-elle posséder ? En fonction de la complexité du test et de l'intervention humaine requise, attribuez les rôles suivants :
- Testeur QA : tests fonctionnels et de régression, tels que la vérification des flux de connexion, la validation des formulaires ou les processus de paiement
- Équipe de sécurité : tests portant sur l'authentification, le contrôle d'accès ou les vulnérabilités liées à l'exposition des données
- Développeur : Tests unitaires pour des fonctions individuelles telles que le hachage des mots de passe ou la génération de jetons
Comment le test sera-t-il réalisé ?
- Sur quels appareils et systèmes d'exploitation les tests seront-ils exécutés ?
- Quels outils ou frameworks de test seront utilisés ?
- Le test sera-t-il exécuté manuellement ou par un agent IA ?
- Comment les résultats seront-ils consignés : dans un outil de gestion des tests, un tableur ou un outil de suivi des bugs?
Quelles sont les conditions préalables ?
Énumérez la liste des conditions qui doivent être remplies avant l'étape 1, et veillez à ce que chacune d'entre elles puisse être vérifiée par le testeur :
Exemple :
- Un compte utilisateur existe avec l'adresse e-mail « test@example.com »
- L'utilisateur est déconnecté du système
- Le service d'e-mail est actif et capable de transmettre des messages
- L'environnement de test est accessible et opérationnel
Quelles données de test seront utilisées ?
Définissez les valeurs d’entrée exactes nécessaires à l’exécution du test : données valides, données non valides et valeurs limites.
Exemple :
- Valide : adresse e-mail enregistrée « test@example.com », mot de passe conforme aux exigences de format
- Non valide : e-mail non enregistré, mot de passe ne respectant pas la limite minimale de caractères requis
- Cas limite : mot de passe respectant exactement les limites minimale et maximale du nombre de caractères
Étape 4 : Rédigez les étapes de test et les résultats attendus
Décomposez le processus d'exécution en étapes séquentielles. Utilisez une terminologie cohérente et veillez à ce que chaque étape corresponde à une seule action. Lorsque vous définissez les étapes, précisez également le résultat attendu et ce qui constitue un succès ou un échec.
Dans la continuité de notre flux de réinitialisation du mot de passe, voici à quoi ressembleraient les étapes de test :
| Étapes | Résultat attendu |
| Accédez à la page de connexion | La page de connexion s'affiche avec un lien cliquable « Mot de passe oublié ». |
| Cliquez sur « Mot de passe oublié » | L'utilisateur est redirigé vers la page de demande de réinitialisation du mot de passe |
| Saisissez votre adresse e-mail dans le champ « E-mail » | L'adresse e-mail est acceptée sans erreur de validation |
| Cliquez sur « Envoyer le lien de réinitialisation » | Le message de réussite s'affiche : « Lien de réinitialisation envoyé à test@exemple.com » |
| Cliquez sur le lien de réinitialisation figurant dans l'e-mail | L'utilisateur est redirigé vers la page de création d'un nouveau mot de passe |
| Saisissez un nouveau mot de passe valide | Le champ « Mot de passe » accepte les saisies sans afficher d'erreur |
| Cliquez sur « Réinitialiser le mot de passe » | Un message de réussite s'affiche et l'utilisateur est redirigé vers la page de connexion |
Définissez à présent les étapes et les résultats attendus pour les différents scénarios (évoqués précédemment). Précisez ce qui se passe lorsque l'utilisateur saisit une adresse e-mail non valide ou que le mot de passe ne correspond pas aux critères prédéfinis.
Bonus : Voici comment réaliser l'automatisation de la documentation à l'aide de l'IA pour tous vos cas de test.
Étape 5 : Joindre les pièces jointes pertinentes
Joignez les documents ou pièces jointes pertinents qui aideront les testeurs à exécuter le scénario de test en toute connaissance de cause et sans ambiguïté. Il peut s'agir notamment :
- Captures d'écran annotées de l'interface utilisateur aux étapes clés
- Enregistrements d'écran montrant comment exécuter le test dans différents scénarios et quels résultats attendre
- Les journaux système ou les fichiers de configuration permettent de diagnostiquer les problèmes au niveau du backend lorsqu'un test échoue
- Documents d'exigences qui mappent le scénario de test sur l'histoire utilisateur ou les critères d'acceptation qu'il valide
- Fichiers de données de test contenant des entrées valides et non valides, ou des données générées telles que des numéros de carte de crédit, des adresses aléatoires ou des identifiants d’utilisateurs
- Mettez en place une documentation couvrant la version spécifique du logiciel, le matériel requis, le système d'exploitation et les habilitations de sécurité éventuelles
- Pour les tests d'API, les spécifications OpenAPI ou la documentation des points de terminaison détaillant les méthodes de requête, les paramètres et les codes de statut attendus
Étape 6 : Faites réviser le cas de test
Partagez le scénario de test rédigé avec un collègue ou un responsable senior de l'assurance qualité avant de l'exécuter. Lors de la révision, vérifiez que :
- Le scénario de test est exhaustif et couvre tous les cas de figure possibles découlant des exigences.
- Les étapes sont claires et représentent de manière séquentielle le flux réel de l'exécution
- Chaque résultat attendu désigne un résultat observable (un message, une redirection, un statut), et non une qualité telle que « fonctionne correctement ».
- Les données de test et les conditions préalables sont achevées et exactes
- Toute hypothèse formulée lors de la rédaction est explicitement documentée
Étape 7 : Exécuter les tests et consigner les résultats
Effectuez le test et consignez le résultat réel par rapport à chaque résultat attendu. Indiquez à chaque étape si le test est réussi ou échoué. Pour chaque étape échouée, signalez immédiatement un bug et liez-le au cas de test. De plus, si un comportement inattendu se produit et qu’il n’est pas clairement possible de déterminer s’il s’agit d’un succès ou d’un échec, notez-le dans le champ de commentaires pour un examen ultérieur.
En savoir plus : Comment utiliser l'IA pour l'assurance qualité
Exemples de rédaction de cas de test
Ces trois exemples montrent comment une même structure de scénario de test s'adapte à différents types de tests logiciels. Chacun d'entre eux reprend les composants et le format des étapes présentés plus haut dans ce guide, mais la complexité, les données de test et les modes de défaillance varient en fonction de ce que vous vérifiez.
Exemple 1 : Flux de paiement dans le commerce électronique (interface utilisateur, flux de travail en plusieurs étapes)
L'équipe d'assurance qualité d'un détaillant en ligne teste le flux de paiement avant une promotion de fin d'année. Le flux s'étend sur plusieurs pages : panier → livraison → paiement → confirmation. La difficulté particulière ici réside dans la dépendance d'état : chaque étape dépend de la bonne exécution de l'étape précédente, et les données de test (contenu du panier, adresse de livraison, mode de paiement) doivent être conservées tout au long du flux.
Testeur : Rahul D.
Date de l'examen : 09/03/2026
Identifiant du cas de test : TC_CHECKOUT_003
Description : Vérifiez qu'un utilisateur connecté peut achever un achat en utilisant une carte de crédit enregistrée et une livraison standard.
Prérequis :
- Le compte utilisateur existe et comporte au moins une carte de crédit enregistrée et une adresse de livraison enregistrée.
- Au moins un élément est en stock et a été ajouté au panier
- L'environnement de test fonctionne sous Chrome 128, macOS
| Étape | Résultat attendu | Résultat réel | Réussite/Échec |
| Accéder à la page du panier | Le panier affiche correctement l'élément, la quantité et le sous-total | Comme prévu | Réussir |
| Cliquez sur « Passer à la caisse » | La page de livraison s'affiche avec l'adresse enregistrée sélectionnée | Comme prévu | Réussir |
| Sélectionnez « Livraison standard » puis cliquez sur Continuer | La page de paiement s'affiche et indique le montant total de la commande, frais de port compris | Comme prévu | Réussir |
| Vérifiez les informations de votre carte de crédit enregistrées, puis cliquez sur « Passer commande ». | La page de confirmation de commande s'affiche avec le numéro de commande, le résumé des éléments et la date de livraison estimée. | La page de paiement se recharge avec le message d’erreur suivant : « Impossible de traiter le paiement » | Échec |
Résumé des résultats : Le flux de paiement gère correctement le transfert du panier vers l’expédition, mais le traitement du paiement échoue avec les cartes de crédit enregistrées. Défaut signalé : la recherche de la carte tokenisée expire lorsque la passerelle de paiement met plus de 3 secondes à répondre.
Exemple 2 : point de terminaison d'une API REST (sans interface utilisateur, validation des entrées/sorties)
Un ingénieur backend teste le point de terminaison API « Créer un utilisateur » avant qu’il ne soit utilisé par l’équipe front-end. Il n’y a pas d’interface sur laquelle cliquer : le scénario de test valide directement les charges utiles des requêtes, les codes de réponse et la persistance des données. Le défi majeur consiste à tester le contrat entre les systèmes, et non l’expérience utilisateur.
Testeuse : Sarah S.
Date de l'examen : 09/05/2026
Identifiant du scénario de test : TC_API_USER_001
Description : Vérifiez qu'une requête POST vers /api/v1/users crée un nouveau utilisateur et renvoie la réponse correcte.
Prérequis :
- L'environnement de test de l'API est opérationnel et accessible
- Un jeton d'authentification doté de permissions d'administrateur a été généré et est valide
- Aucun utilisateur dont l'e-mail est « newuser@testdomain.com » n'existe dans la base de données.
| Étape | Résultat attendu | Résultat réel | Réussite/Échec |
| Envoyez une requête POST à /api/v1/utilisateurs avec une charge utile valide : { "name": "Test Utilisateur", "e-mail": "newuser@testdomain.com", "rôle : "viewer" } | La réponse renvoie le code 201 « Created » avec un corps JSON contenant l'identifiant de l'utilisateur, son nom, son e-mail et son rôle. | 201 renvoyé avec un corps correct | Réussir |
| Renvoyez la même requête POST avec l'e-mail identique | La réponse renvoie le code 409 « Conflit » avec le message : « Un utilisateur portant cette adresse e-mail existe déjà ». | Réponse 200 OK renvoyée ; utilisateur en double créé | Échec |
| Envoyer une requête POST avec le champ « e-mail » manquant | La réponse renvoie un code d'erreur 400 (Bad Request) avec l'erreur de validation suivante : « L'adresse e-mail est obligatoire » | 400 renvoyé comme prévu | Réussir |
| Effectuez une requête GET /api/v1/users/{id} en utilisant l'identifiant obtenu à l'étape 1 | La réponse renvoie un code 200 OK, les informations de l'utilisateur correspondant à la charge utile d'origine. | Comme prévu | Réussir |
Résumé des résultats : Le point de terminaison crée correctement les utilisateurs et valide les champs obligatoires, mais ne vérifie pas l'unicité des adresses e-mail au niveau de la base de données. Des enregistrements en double ont été créés sans générer d'erreur. Défaut enregistré avec un niveau de gravité : Élevé.
Exemple 3 : Contrôle d'accès basé sur les rôles (sécurité, limites des permissions)
Une équipe de sécurité vérifie, avant un audit de conformité, si l'application restreint correctement les actions en fonction des rôles des utilisateurs. La difficulté réside dans le fait que vous ne testez pas le bon fonctionnement d'une fonctionnalité, mais vérifiez si celle-ci est correctement refusée. Le résultat attendu pour la plupart des étapes est un bloc, et non une réussite.
Testeur : Marcus L.
Date de l'examen : 09/08/2026
Identifiant du scénario de test : TC_RBAC_002
Description : Vérifiez qu’un utilisateur disposant du rôle « Viewer » ne peut pas créer, modifier ou supprimer de projets.
Prérequis :
- Il existe deux comptes : l'un avec le rôle « Administrateur », l'autre avec le rôle « Viewer ».
- L'environnement de travail doit contenir au moins un projet, créé par l'administrateur.
- L'utilisateur est connecté sur Firefox 130, Windows 11
| Étape | Résultat attendu | Résultat réel | Réussite/Échec |
| Accédez à la page Projets | L'utilisateur consulte la liste des projets en mode lecture seule ; le bouton « Créer un projet » est soit masqué, soit désactivé. | Le bouton est visible mais grisé | Réussir |
| Essayez de cliquer sur « Créer un projet » | Le système empêche l'action ; le formulaire de création d'un nouveau projet ne se charge pas | Aucun formulaire n’a été chargé ; l’info-bulle indique « Vous n’avez pas la permission ». | Réussir |
| Ouvrez un projet existant et essayez de modifier le titre | Le champ « Titre » n'est pas modifiable, ou le système bloque l'enregistrement | Le champ « Titre » était modifiable ; les modifications ont été enregistrées avec succès. | Échec |
| Essayez de supprimer le projet via le menu à trois points | L'option de suppression est masquée, ou l'action est bloquée en raison d'une erreur de permission | L'option « Supprimer » n'a pas de visibilité dans le menu | Réussir |
Résumé des résultats : Les permissions de création et de suppression sont correctement restreintes pour les utilisateurs en mode « Lecture seule », mais les permissions de modification ne sont pas appliquées au niveau des champs. Un utilisateur en mode « Lecture seule » peut modifier les titres des projets bien qu’il ne dispose que d’un accès en lecture seule. Défaut enregistré avec le niveau de gravité : Critique (obstacle à la conformité).
Quels sont les meilleurs outils pour gérer les cas de test ?
Les cas de test peuvent être gérés dans un outil dédié à l'assurance qualité (TestRail, Zephyr), un outil général de gestion de projet (ClickUp, Jira) ou un tableur ; le choix approprié dépend de vos besoins : une exécution intégrée ou simplement un suivi.
ClickUp
ClickUp for Software Teams est une plateforme de gestion de projet où les cas de test sont gérés sous forme de tâches, aux côtés des sprints, des bugs et des demandes de tirage auxquels ils se rapportent. Il ne s'agit pas d'un outil dédié à la gestion des tests, mais sa structure de tâches flexible permet aux équipes de créer des flux de travail de cas de test à l'aide de statuts, de champs et de types de tâches personnalisés, sans avoir besoin d'un outil distinct.
Principales fonctionnalités de ClickUp
- Une hiérarchie flexible pour organiser les cas de test dans des espaces, des dossiers et des listes, avec des champs personnalisés pour le type de test, la priorité et l'environnement
- Plus de 15 vues ClickUp (Tableau, Liste, Tableau) pour suivre l'exécution des tests par statut, assigné ou sprint
- Documentation permettant de conserver les spécifications fonctionnelles, les plans de test et les guides d'installation de l'environnement à côté des cas de test qu'ils sous-tendent
- Chat intégré pour faciliter la communication entre les développeurs et les responsables de l'assurance qualité, sans avoir à passer par Slack ou par e-mail
- Résumés de tâches générés par l'IA via ClickUp Brain pour une mise en contexte rapide lors des revues de sprint
Limites de ClickUp
- Pas de moteur d'exécution de tests natif
- Les rapports spécifiques aux tests (couverture par exigence, taux de réussite par cycle) nécessitent des tableaux de bord personnalisés plutôt que des rapports d'assurance qualité prêts à l'emploi.
Tarifs de ClickUp
Évaluations et avis sur ClickUp
- G2 : 4,6/5 (plus de 14 100 avis)
- Capterra : 4,6/5 (plus de 4 600 avis)
Que disent les utilisateurs de ClickUp dans la vie de tous les jours ?
Voici ce qu'en dit un critique de G2:
Ce que j’apprécie le plus chez ClickUp, c’est qu’il regroupe tout au même endroit. Les tâches, les échéanciers, les notes et les mises à jour se trouvent tous dans le même système, ce qui réduit les allers-retours entre les différents outils. J’apprécie également sa flexibilité. Nous pouvons personnaliser les statuts, les champs et les vues pour les adapter au mode de fonctionnement réel de notre équipe. Cela facilite l’organisation et offre une visibilité claire sur les responsabilités de chacun et l’avancement des projets à tout moment.
Ce que j’apprécie le plus chez ClickUp, c’est qu’il regroupe tout au même endroit. Les tâches, les échéanciers, les notes et les mises à jour sont tous centralisés dans le même système, ce qui réduit les allers-retours entre les différents outils. J’apprécie également sa flexibilité. Nous pouvons personnaliser les statuts, les champs et les vues pour les adapter au fonctionnement réel de notre équipe. Cela facilite l’organisation et offre une visibilité claire sur les responsabilités de chacun et l’avancement des projets à tout moment.
Idéal pour : un responsable assurance qualité qui souhaite qu’un test échoué se transforme en ticket de bug pour les développeurs en un seul clic, avec la pull request, les étapes de test et le sprint tous visibles depuis la même tâche.
À ignorer si : votre cycle de test est en grande partie automatisé. Si 80 % de votre suite de tests s’exécute à partir d’un pipeline d’intégration continue (CI), vous avez besoin d’un outil qui intègre les résultats d’exécution, et non d’un outil où un utilisateur doit mettre à jour manuellement le statut.
TestRail
TestRail est une plateforme dédiée à la gestion des tests, conçue pour les équipes d'assurance qualité qui ont besoin d'un contrôle structuré sur l'ensemble de leur processus de test. Elle gère le cycle complet de rédaction, d'exécution et de génération de rapports sur les cas de test, grâce à des intégrations DevOps et CI/CD qui alimentent les résultats.
Principales fonctionnalités de TestRail
- Gestion centralisée des cas de test et des suites de test, avec des cas de test réutilisables d'un projet à l'autre
- Plans de test et jalons pour organiser et planifier les exécutions de tests tout au long des sprints et des versions
- Rapports détaillés avec analyse de couverture, suivi de la progression et historique d'exécution
- Intégrations avec Jira, GitHub, Jenkins, Azure DevOps et plus de 20 autres outils DevOps
- API REST pour l'automatisation des tâches et la synchronisation des données de test avec des systèmes externes
Limites de TestRail
- En l'absence de fonctionnalités natives de gestion des exigences ou de suivi des problèmes, les équipes doivent s'appuyer sur des outils externes tels que Jira, ce qui peut nuire à la traçabilité.
- L'organisation par dossiers devient difficile à gérer lorsque les référentiels de tests comptent des milliers d'éléments
Tarifs de TestRail
- Professionnel : 39 $ par place et par mois
- Enterprise : 78 $ par place et par mois
Évaluations et avis sur TestRail
- G2 : 4,4/5 (plus de 600 avis)
- Capterra : 4,3/5 (plus de 160 avis)
Que disent les utilisateurs de TestRail dans la pratique ?
Voici ce qu'en dit un critique de G2:
Ce que j’apprécie le plus chez TestRail, c’est qu’il offre à notre équipe d’assurance qualité un environnement sécurisé et bien organisé pour gérer les plans de test, les cas de test et les exécutions de test. J'apprécie la simplicité avec laquelle il est possible de structurer et de mettre en œuvre des suites de tests, ainsi que de réutiliser des cas de test créés précédemment. Les intégrations avec Jira et les outils CI/CD ont rendu notre flux de travail plus cohérent et plus facile à suivre. La possibilité de surveiller la progression et la couverture des tests en temps réel s'est avérée extrêmement utile pour la planification des sprints et la création de rapports. Dans mon travail quotidien d'ingénieur assurance qualité, l'utilisation de TestRail m'a également permis de gagner un temps considérable.
Ce que j’apprécie le plus chez TestRail, c’est qu’il offre à notre équipe d’assurance qualité un environnement sécurisé et bien organisé pour gérer les plans de test, les cas de test et les exécutions de test. J'apprécie la simplicité avec laquelle on peut structurer et mettre en œuvre des suites de tests, ainsi que réutiliser des cas de test créés précédemment. Les intégrations avec Jira et les outils CI/CD ont rendu notre flux de travail plus cohérent et plus facile à suivre. La possibilité de surveiller la progression et la couverture des tests en temps réel s'est avérée extrêmement utile pour la planification des sprints et la création de rapports. Dans mon travail quotidien d'ingénieur assurance qualité, l'utilisation de TestRail m'a également permis de gagner un temps considérable.
Idéal pour : une équipe d’assurance qualité composée d’au moins cinq personnes et effectuant des cycles de test formels à chaque version, où un responsable doit pouvoir répondre à la question « quel pourcentage de la version 2.0 a été testé et validé ? » à partir d’un tableau de bord, et non d’un tableur.
À éviter si : votre suite compte moins de quelques centaines de cas ou si vos testeurs font également office de développeurs. À cette échelle, le coût par place et la connexion distincte ne vous apporteront que des rapports que vous ne consulterez pas.
Zephyr
Zephyr est le plugin de gestion des tests de SmartBear pour Jira, conçu pour gérer les cas de test depuis l'interface Jira. Il prend en charge à la fois les tests manuels et automatisés, et offre de puissantes fonctionnalités de rapports et de traçabilité destinées aux équipes agiles et aux entreprises.
Principales fonctionnalités de Zephyr
- Intégration native à Jira : créez, liez et exécutez des cas de test directement à partir des problèmes Jira
- Bibliothèques de tests hiérarchiques inter-projets pour la réutilisation et l'organisation des cas de test à grande échelle
- Plus de 70 rapports prêts à l'emploi couvrant la couverture des tests, l'avancement de l'exécution et le suivi des défauts
- Assistance pour le BDD avec la syntaxe Gherkin pour les flux de travail de développement piloté par le comportement
- Intégrations CI/CD avec Jenkins, GitHub, GitLab, Bitbucket et Bamboo
Limites de Zephyr
- Licence par utilisateur Jira, et non par testeur
- Les grands référentiels de tests (contenant des milliers de cas) peuvent sembler plus difficiles à parcourir que dans des outils autonomes tels que TestRail
- L'assistance est gérée via Atlassian Marketplace, ce qui ajoute une étape supplémentaire pour les équipes habituées à bénéficier d'une assistance directe auprès des éditeurs.
Tarifs de Zephyr
- Essentiel : à partir de 5,99 $ par utilisateur et par mois (11 à 50 utilisateurs)
- Formule Standard : à partir de 6,81 $ par utilisateur et par mois (11 à 50 utilisateurs)
- Avancé : à partir de 8,73 $ par utilisateur et par mois (11 à 50 utilisateurs)
Évaluations et avis sur Zephyr
- G2 : 4,1/5 (plus de 80 avis)
- Capterra : pas assez d'avis
Que disent les utilisateurs de Zephyr dans la pratique ?
Voici ce qu'en dit un critique de G2:
C'est l'outil idéal pour importer des cas de test directement depuis une feuille Excel. Grâce à cet outil, le travail des testeurs est simplifié par rapport à l'importation de cas de test dans Jira. Cet outil offre également une fonctionnalité très pratique permettant de marquer les cas de test comme réussis ou échoués et d'y ajouter des pièces jointes.
C'est l'outil idéal pour importer des cas de test directement depuis une feuille Excel. Grâce à cet outil, le travail des testeurs est simplifié par rapport à l'importation de cas de test dans Jira. Il offre également une fonctionnalité très pratique permettant de marquer les cas de test comme réussis ou échoués et d'ajouter des pièces jointes.
Idéal pour : les équipes soumises à une réglementation stricte ou à de nombreux audits (fintech, santé) qui ont besoin que chaque test soit rattaché à une exigence Jira et que chaque défaut soit lié au test qui l’a détecté, le tout au sein d’une seule instance Atlassian.
À éviter si : votre instance Jira est volumineuse et votre équipe d'assurance qualité réduite. Une instance Jira de 200 places avec 10 testeurs revient à payer 190 licences Zephyr que personne n'utilise ; un outil autonome facturé par testeur revient moins cher.
Jira
Jira est la plateforme de gestion de projet et de suivi des tickets d’Atlassian, largement utilisée par les équipes d’ingénierie et d’assurance qualité pour gérer les sprints, les bugs et les flux de travail de développement. Bien qu’il ne s’agisse pas d’un outil dédié à la gestion des tests, de nombreuses équipes l’utilisent en complément de solutions telles que Zephyr Scale ou Xray pour gérer leurs cas de test au sein de leur installation Jira existante.
Principales fonctionnalités de Jira
- Tableaux Scrum et Kanban pour la gestion des sprints, des backlogs et des flux de travail de tests Agile
- Des flux de travail, des types de tickets et des champs personnalisables pour s'adapter à la manière dont votre équipe suit son travail
- Feuilles de route avancées pour la planification inter-équipes et le suivi des dépendances (Premium)
- Plus de 1 000 intégrations à des plateformes, notamment GitHub, Confluence, Slack et des outils CI/CD
- Règles d'automatisation permettant de déclencher des actions dans l'ensemble des projets en fonction des mises à jour des problèmes ou des changements de statut
Limites de Jira
- La gestion des cas de test nécessite un plugin du Marketplace (Zephyr Scale, Xray) dont le coût par utilisateur s'ajoute à l'abonnement Jira.
- Une courbe d'apprentissage plus raide pour les utilisateurs non techniciens, avec des coûts de formation qui peuvent s'alourdir pour les équipes plus importantes
Tarifs de Jira
- Free
- Forfait Standard : 7,91 $ par utilisateur et par mois
- Premium : 14,54 $ par utilisateur et par mois
- Enterprise : tarification personnalisée
Évaluations et avis sur Jira
- G2 : 4,3/5 (plus de 7 900 avis)
- Capterra : 4,4/5 (plus de 15 400 avis)
Que disent les utilisateurs de Jira dans la vie réelle ?
Voici ce qu'en dit un évaluateur de G2:
Jira est l'un de mes outils numériques préférés pour suivre et visualiser l'avancement de tous mes projets de travail en collaboration avec tous les membres de mon équipe, car il offre les meilleures fonctionnalités de suivi virtuel de sa catégorie, ce qui me permet d'atteindre plus facilement tous mes objectifs professionnels.
Jira est l'un de mes outils numériques favoris pour suivre et visualiser les performances de tous mes projets professionnels en collaboration avec tous les membres de mon équipe, car il offre les meilleures fonctionnalités de gestion virtuelle de sa catégorie, ce qui me permet d'atteindre plus facilement tous mes objectifs professionnels.
Idéal pour : les équipes d'ingénieurs qui cherchent à déterminer si elles ont réellement besoin d'une gestion dédiée des tests. Lancer dans un premier temps quelques cycles de test en utilisant des types de tickets Jira personnalisés permet de voir si le volume justifie l'utilisation d'un plugin.
Passez cette étape si : vous savez déjà que vous avez besoin d'une solution de gestion des tests. En optant directement pour un plugin ou un outil autonome, vous éviterez la migration lorsque les types de problèmes personnalisés ne suffiront plus à répondre à vos besoins.
Erreurs courantes à éviter lors de la création de cas de test
Évitez ces erreurs de rédaction de cas de test qui peuvent nuire à leur efficacité globale.
| Erreur | Que faire à la place ? |
|---|---|
| Rédaction des cas de test trop tardive | Impliquez les testeurs dès les phases de collecte des exigences et de conception afin d'identifier les problèmes potentiels avant le début du codage |
| Non-mise à jour des cas de test | Mettez à jour le scénario de test dès qu'une fonctionnalité fait l'objet d'une nouvelle mise à jour, d'une modification de ses fonctionnalités ou d'un changement d'interface utilisateur. |
| Pas de postconditions | Précisez l'état dans lequel le système doit se trouver une fois le test achevé (utilisateur test supprimé, panier vidé, session fermée) afin que le cas suivant démarre à partir d'un état vierge. |
| Uniquement les données du scénario normal | Chaque champ de saisie doit comporter au moins une valeur que le système doit rejeter. Documentez la manière dont l'ensemble de données est généré ou extrait. |
| Ne pas hiérarchiser les cas de test | Attribuez à chaque scénario de test une priorité en fonction de son impact sur l'activité, de sa fréquence d'utilisation et du risque de défaillance. Cela vous aidera à cibler vos efforts de test et à prendre des décisions plus éclairées en matière de budget et de méthodes de test. |
Comment garantir la pertinence des cas de test au fil du temps
Une suite de tests reste fiable lorsque chaque scénario est indépendant, cible les entrées les plus susceptibles de provoquer des défaillances et est retirée dès qu'elle ne produit plus de résultat fiable. Ces six bonnes pratiques distinguent les suites qui détectent des bogues pendant des années de celles qui sont ignorées dès le deuxième sprint.
Rédigez des tests indépendants et atomiques
Un scénario de test doit pouvoir s’exécuter de manière autonome et ne jamais être soumis à une dépendance vis-à-vis de l’exécution préalable d’un autre scénario. Lorsque le scénario TC_CHECKOUT_003 part du principe que le scénario TC_CHECKOUT_002 a laissé un élément dans le panier, un seul échec entraîne une cascade de cinq autres, et vous passez la matinée à essayer de déterminer lequel de ces échecs était réel. Si le titre d’un test contient le mot « et », divisez-le en deux scénarios distincts.
Testez aux limites
The bugs concentrate at the edges of the accepted value ranges, not in the middle. Si un champ de mot de passe accepte entre 8 et 128 caractères, testez les valeurs 7, 8, 128 et 129, et pas seulement un mot de passe de 12 caractères, plus pratique. L’analyse des valeurs limites est une technique formelle prévue par la norme ISO/IEC/IEEE 29119-4 relative à la conception des tests précisément pour cette raison : elle permet de détecter les erreurs de décalage d’un élément que les entrées aléatoires ne parviennent pas à repérer.
Utilisez le partitionnement par équivalence pour réduire les cas redondants
Regroupez les entrées que le système doit traiter de manière identique, puis testez un exemple représentatif de chaque groupe. Tous les formats d'e-mail valides se comportent de la même manière dans un formulaire de connexion ; un seul e-mail valide suffit donc. Tester user@example.com, jane@company.com et bob@domain.org comme trois cas distincts triple votre charge de maintenance sans augmenter la couverture.
Séparer les données de test des étapes de test
Coder en dur « saisir test@example.com » dans une étape implique de réécrire cette étape à chaque fois que l’environnement de test change. Privilégiez des étapes génériques (« saisir une adresse e-mail enregistrée ») et conservez les valeurs réelles dans un champ de données de test ou un fichier. Les mêmes étapes s’exécutent alors sur les environnements de préproduction, d’assurance qualité et de staging sans modification, et le remplacement par un nouvel ensemble de données pour un test négatif ne nécessite qu’une seule ligne de code.
Suivi des tests instables et du taux d'échappement des défauts
Un test instable échoue de manière irrégulière sans qu’il y ait de véritable bug dans le produit, et chaque test instable incite l’équipe à ignorer les résultats « rouges ». Suivez la fréquence à laquelle chaque scénario alterne entre réussite et échec sur des versions identiques. Si un scénario présente une instabilité plus de deux fois par mois, réécrivez-le ou supprimez-le. Associez cela au taux d’échappement des défauts (bugs détectés en production qu’un scénario de test aurait dû détecter) pour identifier les zones où la couverture est insuffisante, et pas seulement celles où elle est bruyante.
Effectuez l'automatisation des tests que vous effectuez le plus souvent
Les cas de régression, de vérification sommaire et de tests fonctionnels à haute fréquence sont les plus adaptés à l’automatisation, car ils s’exécutent à chaque build et changent rarement. Intégrez-les dans des scripts de votre pipeline CI/CD et utilisez des outils assistés par l’IA dotés de localisateurs à correction automatique lorsque les éléments de l’interface utilisateur changent fréquemment. Cela permet aux testeurs humains de se consacrer au travail exploratoire et aux types de tests logiciels qui nécessitent un jugement, comme l’ergonomie et la recherche de cas limites.
Comment rédiger et exécuter des cas de test dans ClickUp
La section « Outils » ci-dessus explique comment ClickUp s'intègre dans ce contexte. Cette section présente l'installation concrète, en suivant les étapes décrites plus haut dans ce guide.
Structurez votre bibliothèque de cas de test. Créez un espace dédié à votre produit, un dossier pour chaque fonctionnalité (par exemple, Authentification, Paiements, Intégration) et une liste pour chaque cycle de test ou sprint. Chaque tâche devient un cas de test individuel. Utilisez les champs personnalisés de ClickUp pour enregistrer des informations telles que l'identifiant du cas de test, les conditions préalables, les données de test, le niveau de priorité et l'environnement.
Rédigez les étapes de test directement dans la tâche. Utilisez la description de la tâche pour documenter les étapes d'exécution séquentielles et les résultats attendus. Les checklists sont particulièrement adaptées aux flux étape par étape, où le testeur doit cocher chaque action, tandis que la description fournit le contexte, comme les conditions préalables et les données de test.
Suivez l'exécution et les résultats. Créez des statuts personnalisés qui reflètent votre flux de travail de test : Non commencé → En cours → Réussi → Échec → Bloqué. Lorsqu'un test échoue, convertissez-le en tâche de bug ou créez une tâche liée attribuée au développeur, avec une priorité, des dépendances et une date limite. Les intégrations GitHub et GitLab vous permettent de lier ce bug directement à la demande de tirage à l’origine du problème. Si la cause première est un défaut de code, vous pouvez attribuer cette tâche de bug à l’agent ClickUp Codegen, qui lit la tâche, les spécifications associées et les commentaires, rédige le correctif et ouvre une demande de tirage dont la progression est renvoyée vers la tâche.
Conseil de pro : Les responsables QA peuvent obtenir un aperçu instantané de n'importe quelle tâche en demandant à ClickUp Brain de résumer les tâches liées aux bugs en cours. Ils disposent ainsi de tout le contexte nécessaire pour les revues de sprint, sans avoir à passer au crible chaque tâche pour se faire une idée d'ensemble.
Exécutez des cycles de test à l’aide des vues. Utilisez la vue Tableau, regroupée par statut, pour visualiser d’un seul coup d’œil la distribution des résultats (réussite/échec) pendant l’exécution d’un test. La vue Tableau fonctionne comme une matrice de test classique lorsque vous devez passer en revue les résultats de dizaines de cas. Filtrez par responsable pour équilibrer la charge de travail, ou par priorité pour concentrer d’abord un test de fumée sur les chemins critiques.
Le modèle de gestion des tests ClickUp vous offre un moyen centralisé de gérer l’ensemble du flux de travail de test, couvrant plusieurs fonctionnalités, scénarios de test et cas limites, le tout en un seul et même endroit. Utilisez-le pour suivre les retours des utilisateurs, gérer les plannings de test, surveiller la progression de vos tests et évaluer les résultats (réussite/échec) sans avoir à passer d’un outil à l’autre.
Gérez efficacement vos flux de travail de test
Un scénario de test fait ses preuves dès lors que deux personnes peuvent l'exécuter indépendamment l'une de l'autre et aboutir au même résultat (réussite ou échec). Tout ce qui figure dans ce guide (une action par étape, des préconditions explicites, des résultats attendus ne laissant aucune place à l'interprétation) répond à cette norme unique. Si vous planifiez déjà vos sprints dans ClickUp, l'installation décrite ci-dessus vous permet de rédiger, d'exécuter et de suivre les scénarios de test ainsi que les bugs qu'ils mettent en évidence, sans avoir à ajouter d'autre outil.
Inscrivez-vous gratuitement à ClickUp
Foire aux questions sur les cas de test
Combien de cas de test une exigence doit-elle comporter ?
Une même exigence peut nécessiter un seul scénario de test ou jusqu’à dix, selon le nombre de scénarios, de cas limites et de variations d’entrées qu’elle implique. L’objectif est de couvrir tous les chemins réalistes, en offrant une couverture suffisante sans redondance.
Quelle est la différence entre les cas de test et les scripts de test ?
Un cas de test documente ce qu'il faut tester et le résultat attendu ; il est rédigé en vue d'une exécution manuelle. Un script de test, en revanche, en est la version automatisée : il s'agit d'un code qui exécute ces mêmes étapes de manière programmatique.
Quel doit être le niveau de détail des étapes de test ?
Décomposez le test en étapes logiques et séquentielles, faciles à suivre même sans contexte préalable. Ne regroupez pas plusieurs actions et n'ajoutez pas de complexité inutile.
Un scénario de test indique ce qu'il faut tester en une seule ligne (« Vérifier la réinitialisation du mot de passe ») ; un cas de test précise comment procéder, avec des conditions préalables, des étapes, des données de test et des résultats attendus. Un scénario génère généralement entre 3 et 10 cas de test couvrant le scénario normal, les entrées non valides et les conditions limites. Les scénarios viennent en premier et déterminent la planification de la couverture ; les cas de test viennent ensuite et déterminent l'exécution.
Un cas de test positif utilise des données d’entrée valides et s’attend à une réussite : un e-mail et un mot de passe corrects permettent à l’utilisateur de se connecter. Un cas de test négatif utilise des données d’entrée invalides ou inattendues et s’attend à ce que le système gère l’échec de manière correcte : un mot de passe erroné affiche le message « Mot de passe invalide » sans créer de session. Les suites de tests abouties présentent un rapport de cas positifs à négatifs d’environ 1:3 à 1:5, car la plupart des bugs en production se trouvent dans les chemins d’erreur, et non dans les chemins normaux.
Un plan de test définit la portée, l'approche, les ressources et le calendrier de l'ensemble de l'effort de test. Une suite de tests est un ensemble de cas de test regroupés pour une seule exécution, comme par exemple la « suite de tests de régression pour la version 2.1 ». Un cas de test est l'unité de base de ces deux éléments : il s'agit d'une vérification documentée dont le résultat est « réussi » ou « échoué ». Le plan définit la stratégie, la suite définit la portée, et le cas définit le verdict.