La plupart des cas de test échouent avant même d’avoir détecté un seul 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 de « réussi ». Conséquence : des bugs passent entre les mailles du filet, les exécutions de tests 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 cas de test relève moins de la compétence en matière de test que de la conception de la vérification. Dans le secteur des services financiers, on parle de « processus maker-checker ». Dans le domaine des commandes nucléaires, on parle de « règle des deux personnes ». Le principe est le même : un travail critique ne doit jamais reposer sur une seule action non vérifiée. Un cas 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 cas 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 cas 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 par programmation). 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 « 2026 State of Testing Report » 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 des centaines de cas de test simultanément |
| Répétabilité | Sujet aux erreurs humaines et à des interprétations incohérentes des étapes | Une répétabilité et une cohérence élevées lorsque la maintenance des scripts de test est correctement effectuée |
| Intégration CI/CD | Difficile à intégrer dans des pipelines de livraison au rythme soutenu en raison de goulots d'étranglement humains | S'intègre directement aux 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 évolue |
| 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 créent des tickets. Chaque modification du code comporte le risque de casser quelque chose qui fonctionne déjà. Un cas 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 cas de test qui le signale en environnement de préproduction.
Faites en sorte que « réussi » ou « échoué » 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 cas de test : 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 formulé ainsi : « 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 le même langage.
Vous transformez les connaissances tacites en ressources réutilisables. 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, accompagnés de conditions préalables et de valeurs limites explicites, permettent de préserver ces connaissances de manière structurée. Un nouveau testeur rejoignant l’équipe peut sélectionner TC_LOGIN_005 et tester le flux de « verrouillage du compte après cinq tentatives » dès le premier jour, sans avoir à demander à qui que ce soit 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é, e-mail non enregistré, format invalide, 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 cas de test
Un cas de test utile ne se contente pas de décrire ce qu'il faut tester. Il précise le contexte, les étapes d'exécution et le 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 cas 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 de fonctionnalité de connexion au site web que nous avons partagé ci-dessus, votre scénario de test devrait inclure :
Identifiant du cas de test : chaque cas de test doit disposer d’un identifiant unique. Lorsqu’elles testent 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 : Ce champ explique quelle fonction le cas de test est censé valider. Il fournit un bref résumé afin que toute personne lisant le cas de test en comprenne immédiatement l'objectif.
Exemple : Vérifiez qu’un utilisateur enregistré peut réussir sa connexion à l’application à l’aide d’identifiants valides.
Conditions préalables : Les conditions préalables décrivent l'état du système requis avant l'exécution du cas de test. Sans elles, 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 cas 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 : ils définissent ce que le système doit faire lorsque 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 cas 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 des travaux stratégiques tels que l'identification des risques (19,9 %).
Comment rédiger des cas de test (procédure étape par étape)
La rédaction d'un cas 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 cas, puis l'exécuter et consigner les résultats.
Étape 1 : Analyser les exigences
Avant de rédiger un cas de test, assurez-vous de bien comprendre le fonctionnement prévu de la fonctionnalité. C'est à ce stade que vous passez en revue les documents disponibles (PRD, ou cahiers des charges produit ; user stories ; spécifications des fonctionnalités ; et documents de conception) afin d'identifier chaque élément fonctionnel devant être vérifié.
Exemple : vous développez une fonctionnalité permettant aux utilisateurs de réinitialiser leur mot de passe par e-mail. Pour créer un cas 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 a oublié 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 modifier 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, c'est-à-dire 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 clair pour votre scénario de test.
Objectif : Vérifier qu'un utilisateur inscrit peut réinitialiser son mot de passe par e-mail avec succès.
Étape 2 : Identifiez 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 générale qui, en règle générale, 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'une adresse e-mail qui n'existe pas dans le système est soumise.
- 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érifiez 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 à la suite
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 les tests 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 de réutiliser les cas sans devoir 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 quelles qualifications la personne chargée d’effectuer 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 les vulnérabilités liées à l’authentification, au contrôle d’accès ou à 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 via un agent IA ?
- Comment les résultats seront-ils enregistré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 de toutes les 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@exemple.com »
- L'utilisateur est déconnecté du système
- Le service d'e-mail est actif et capable d'envoyer 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
- Limite : mot de passe respectant exactement les limites minimale et maximale 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.
Pour poursuivre notre flux de réinitialisation de 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 » | Un message de réussite s'affiche : « Lien de réinitialisation envoyé à test@example.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 générer 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 maintenant 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 : Ajoutez les pièces jointes pertinentes
Joignez les documents ou pièces jointes pertinents qui aideront les testeurs à exécuter le cas de test en disposant de tout le contexte nécessaire 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 avec 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, des spécifications OpenAPI ou une 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 cas de test est exhaustif et couvre tous les scénarios 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 code de statut), et non une qualité telle que « fonctionne correctement ».
- Les données de test et les conditions préalables sont complètes et exactes
- Toutes les hypothèses formulées lors de la rédaction sont explicitement documentées
É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 si un test est réussi ou échoué à chaque étape. Pour chaque étape ayant échoué, signalez immédiatement un bug et liez-le au scénario 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 cas de test s'adapte à différents types de tests logiciels. Chacun d'entre eux utilise les composants et le format d'é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 d'un site de commerce électronique (interface utilisateur, flux de travail en plusieurs étapes)
L'équipe d'assurance qualité d'un e-commerçant teste le flux de paiement avant une opération promotionnelle liée aux fêtes de fin d'année. Le flux s'étend sur plusieurs pages : panier → livraison → paiement → confirmation. La difficulté majeure réside ici dans la dépendance d'état : chaque étape dépend de l'étape précédente qui doit être achevée correctement, 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 du test : 03/09/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 la 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édez à 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 » | Chargement des pages de livraison 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 en indiquant 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ée, puis cliquez sur « Passer la 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 l’erreur suivante : « Impossible de traiter le paiement » | Échec |
Résumé des résultats : le flux de paiement gère correctement le passage du panier à l'expédition, mais le traitement du paiement échoue avec les cartes de crédit enregistrées. Problème 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 de l'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 cas de test valide directement les charges utiles des requêtes, les codes de réponse et la persistance des données. Le défi principal consiste à tester l’interface entre les systèmes, et non l’expérience utilisateur.
Testeuse : Sarah S.
Date du test : 05/09/2026
Identifiant du cas de test : TC_API_USER_001
Description : Vérifiez qu'une requête POST vers /api/v1/users crée un nouvel 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": "Utilisateur test", "e-mail": "newuser@testdomain.com", "rôle : "viewer" } | La réponse renvoie le code 201 « Créé » 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 |
| Envoyez à nouveau la même requête POST avec le même e-mail | La réponse renvoie le code 409 « Conflit » avec le message : « Un utilisateur avec ce type d’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 le code 400 « Bad Request » avec l'erreur de validation suivante : « L'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 : L'interface de programmation 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 si une fonctionnalité fonctionne, mais si elle est correctement bloquée. Le résultat attendu pour la plupart des étapes est un bloc, et non une réussite.
Testeur : Marcus L.
Date du test : 08/09/2026
Identifiant du cas de test : TC_RBAC_002
Description : Vérifiez qu'un utilisateur disposant du rôle « Observateur » ne peut ni créer, ni modifier, ni 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 en mode lecture seule voit la liste des projets ; 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 réaliser une modification du 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 « Supprimer » 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 « Viewers », mais les permissions de modification ne sont pas appliquées au niveau des champs. Un « Viewer » 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 : avez-vous besoin d'une fonctionnalité d'exécution intégrée ou simplement d'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 les espaces, les dossiers et les 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 (PRD), les plans de test et les guides d'installation de l'environnement à proximité des cas de test auxquels ils se rapportent
- Chat intégré pour faciliter la communication entre les responsables de l'assurance qualité et les développeurs, sans avoir à passer par Slack ou par e-mail
- Résumés des 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 réelle ?
Voici ce qu'en dit un contributeur 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 sont tous regroupé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 mode de fonctionnement réel de notre équipe. Cela facilite l’organisation et offre une visibilité claire sur les responsabilités de chacun ainsi que sur l’état d’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 ainsi que sur l’avancement des projets à tout moment.
Idéal pour : un responsable QA qui souhaite qu’un test échoué soit transformé en ticket de bug pour les développeurs en un seul clic, la pull request, les étapes de test et le sprint étant 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 automatiquement 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 prend en charge 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 automatiser les tâches et synchroniser les données de test avec des systèmes externes
Limites de TestRail
- Pas de fonctionnalité native 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
- Professional : 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 contributeur 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 on peut structurer et mettre en œuvre des suites de tests, ainsi que réutiliser des cas de test déjà créés. 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 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.
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 vous offrent 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 directement depuis l’interface Jira. Il prend en charge à la fois les tests manuels et d’automatisation, 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 réutiliser et organiser les 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 de la part des fournisseurs.
Tarifs de Zephyr
- Essentiel : à partir de 5,99 $ par utilisateur et par mois (11 à 50 utilisateurs)
- Standard : à partir de 6,81 $ par utilisateur et par mois (11 à 50 utilisateurs)
- Formule Advanced : à 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 contributeur 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. Parmi les autres fonctionnalités de cet outil, on peut citer la possibilité de marquer les cas de test comme réussis ou échoués, ainsi que d'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'y 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 problèmes et des champs personnalisables, adaptés à 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, notamment GitHub, Confluence, Slack et des outils CI/CD
- Règles d'automatisation permettant de déclencher des actions sur 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 mise en route qui peuvent s'alourdir pour les grandes équipes
Tarifs de Jira
- Free
- 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 pratique ?
Voici ce qu'en dit un contributeur de G2:
Jira est l'un de mes outils numériques préférés pour suivre et visualiser les performances de tous mes projets de travail en collaboration avec tous les membres de mon équipe, car il offre les meilleures fonctionnalités de suivi de performances 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 de travail en collaboration avec tous les membres de mon équipe, car il offre les meilleures fonctionnalités de suivi de performances 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'un outil dédié à la gestion des tests. Lancer dans un premier temps quelques cycles de tests 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'un outil 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 recueil des exigences et de conception afin d’identifier les problèmes potentiels avant le début du codage |
| Les cas de test ne sont pas mis à jour | Mettez à jour le cas 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 quel doit être l’état du système 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 idéal | 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 d'échec. Cela vous aide à concentrer vos efforts de test et à prendre des décisions plus éclairées concernant le budget et les méthodes de test. |
Comment garantir la pertinence des cas de test au fil du temps
Une suite de tests reste fiable lorsque chaque cas 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 verdict fiable. Ces six bonnes pratiques distinguent les suites qui détectent des bugs 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 définir son propre état et ne jamais dépendre de la dépendance à l’égard de l’exécution préalable d’un autre scénario. Lorsque TC_CHECKOUT_003 part du principe que TC_CHECKOUT_002 a laissé un élément dans le panier, un échec en entraîne cinq autres, et vous passez la matinée à essayer de déterminer lequel était réel. Si le titre d’un test contient le mot « et », divisez-le en deux scénarios.
Testez aux limites
Les bugs se concentrent aux extrémités des valeurs d'entrée acceptées, et non au milieu. Si un champ de mot de passe accepte entre 8 et 128 caractères, testez 7, 8, 128 et 129, et pas seulement un mot de passe de 12 caractères, ce qui serait trop facile. 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 permettent pas de 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 ou un fichier de données de test. Les mêmes étapes s’exécutent alors sur les environnements de staging, d’assurance qualité et de préproduction 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 de défauts non détectés
Un test instable échoue de manière aléatoire 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 cas alterne entre réussite et échec sur des versions identiques. Si un cas 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 cas 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 de base et de tests fonctionnels à haute fréquence sont les plus adaptés à l’automatisation, car ils s’exécutent à chaque version 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 auto-corrigés 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’évaluation de 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 présente le rôle de ClickUp. Cette section décrit l’installation concrète, en correspondance avec les étapes décrites plus haut dans ce guide.
Structurez votre bibliothèque de cas de test. Créez un Espace pour 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'ID 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 contient des informations contextuelles telles que 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 → Échoué → 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 pull request qui l’a introduit. 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 description de la tâche, les spécifications associées et les commentaires, rédige une proposition de correction et ouvre une demande de tirage pour révision, 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 globale de la situation.
Exécutez des cycles de test à l’aide des vues. Utilisez la vue Tableau (Groupé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 Tableur 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 vérification rapide sur les chemins critiques.
Le modèle de gestion des tests ClickUp vous offre un moyen centralisé de gérer l'ensemble de votre flux de travail de tests, qu'il s'agisse de fonctionnalités, de scénarios de test ou de cas limites, le tout en un seul et même endroit. Utilisez-le pour suivre les retours des utilisateurs, gérer les plannings de tests, surveiller l'avancement 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 conditions préalables 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 cas de test ou jusqu’à dix, selon le nombre de scénarios, de cas limites et de variations d’entrée 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 décrit 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. Évitez de regrouper plusieurs actions ou d'ajouter une complexité inutile.
Un scénario de test indique quoi tester en une seule ligne (« Vérifier la réinitialisation du mot de passe ») ; un cas de test précise comment procéder, avec les conditions préalables, les étapes, les données de test et les 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 guident la planification de la couverture ; les cas de test viennent ensuite et guident 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 échoue de manière contrôlée : 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 d’environ 1:3 à 1:5 entre les cas positifs et négatifs, 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 des efforts de test. Une suite de tests est un ensemble de cas de test regroupés pour une seule exécution, par exemple « 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 : une vérification documentée donnant lieu à un résultat « 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.