Tester un logiciel ne consiste pas à cliquer au hasard pour voir si « ça marche ». Un test sérieux repose sur des scénarios écrits, reproductibles et compréhensibles par toute l’équipe. Ces scénarios s’appellent des cas de test. Bien les rédiger permet de détecter les défauts plus tôt, de répéter les vérifications à chaque nouvelle version et de partager un langage commun entre testeurs, développeurs et responsables produit.
Qu’est-ce qu’un cas de test ?
Un cas de test est une description précise d’une vérification à effectuer : dans quelles conditions de départ, avec quelles données, en suivant quelles actions, et quel résultat est attendu. Il répond à une question simple : « le logiciel se comporte-t-il comme prévu dans cette situation ? »
La force d’un bon cas de test est sa reproductibilité. Une autre personne, ou vous-même dans trois mois, doit pouvoir l’exécuter et obtenir le même résultat sans deviner ce que l’auteur avait en tête.
Les éléments d’un cas de test
Selon les outils et les équipes, le format varie, mais on retrouve presque toujours les mêmes éléments :
| Élément | Rôle |
|---|---|
| Identifiant | Référence unique permettant de retrouver et de suivre le test |
| Titre | Résumé court de ce qui est vérifié |
| Objectif | Exigence ou fonctionnalité couverte |
| Préconditions | État du système et des données avant de commencer |
| Données de test | Valeurs à saisir ou à utiliser |
| Étapes | Actions à réaliser, dans l’ordre |
| Résultat attendu | Comportement correct du logiciel |
| Résultat obtenu et statut | Ce qui s’est réellement passé (réussi, échoué, bloqué) |
Un exemple concret : la connexion à un compte
Prenons une page de connexion avec un identifiant et un mot de passe. Voici un cas de test simple, présenté de façon schématique :
- Identifiant : CT-001
- Titre : Connexion réussie avec des identifiants valides
- Préconditions : un compte utilisateur actif existe ; l’utilisateur n’est pas connecté
- Données : adresse e-mail et mot de passe corrects du compte de test
Étapes :
- Ouvrir la page de connexion.
- Saisir l’adresse e-mail dans le champ prévu.
- Saisir le mot de passe.
- Cliquer sur le bouton « Se connecter ».
Résultat attendu : l’utilisateur est redirigé vers son espace personnel et son nom apparaît dans l’en-tête.
Ne pas oublier les cas négatifs et les limites
Un logiciel ne se teste pas seulement avec des données correctes. Les erreurs les plus fréquentes se cachent dans les situations inhabituelles. Pour la même page de connexion, on prévoit aussi des cas négatifs : mot de passe erroné, champ vide, adresse e-mail mal formée, compte désactivé. Dans chacun, le résultat attendu est un message d’erreur clair, sans révéler d’information sensible.
Deux techniques classiques aident à choisir les cas utiles sans tester l’infini :
- Les classes d’équivalence : on regroupe les valeurs qui doivent provoquer le même comportement et on teste un représentant de chaque groupe.
- Les valeurs limites : on teste les bornes et leurs voisins. Si un champ accepte de 8 à 20 caractères, on vérifie 7, 8, 20 et 21.
Bonnes pratiques de rédaction
- Un cas de test, un objectif. Si un test vérifie trois choses, il est difficile de savoir laquelle a échoué.
- Des étapes courtes et précises. Une action par étape, avec des verbes à l’impératif.
- Un résultat attendu vérifiable. Évitez « ça fonctionne » ; préférez « le message “Mot de passe incorrect” s’affiche ».
- Des préconditions explicites. Indiquez les comptes, les droits et l’état des données nécessaires.
- Un langage clair et neutre. Le test doit être compréhensible par un nouveau membre de l’équipe.
- Un lien avec les exigences. Cela montre ce qui est couvert et ce qui ne l’est pas.
- Une maintenance régulière. Quand le logiciel évolue, mettez les cas de test à jour.
Les erreurs fréquentes
Parmi les écueils habituels, on trouve les étapes ambiguës (« remplir le formulaire » sans préciser quelles données), les tests dépendants les uns des autres sans que cela soit indiqué, les résultats attendus trop vagues et l’oubli des préconditions. Un autre piège consiste à ne rédiger que des scénarios « heureux » : le logiciel semble alors fiable alors que les cas d’erreur n’ont jamais été vérifiés.
Du cas de test à la campagne de test
Les cas de test sont généralement regroupés en suites ou en campagnes, par fonctionnalité ou par risque. Lors de l’exécution, chaque cas reçoit un statut, et les échecs donnent lieu à des fiches d’anomalie décrivant le problème, les étapes de reproduction et l’environnement concerné. Les cas les plus stables et les plus importants peuvent ensuite être automatisés pour être rejoués rapidement à chaque modification.
Exemple de cas négatif
Reprenons la connexion avec un mot de passe incorrect. Les préconditions sont identiques : un compte actif existe et l’utilisateur n’est pas connecté. Les étapes sont les mêmes, mais la donnée de test change : on saisit une adresse valide avec un mot de passe erroné. Le résultat attendu est l’affichage d’un message d’erreur clair, l’absence d’accès à l’espace personnel et le maintien de l’utilisateur sur la page de connexion. Ce type de cas vérifie que le logiciel protège l’accès et guide correctement l’utilisateur en cas d’erreur.
Conclusion
Un bon cas de test est précis, reproductible et orienté vers un objectif unique. En soignant les préconditions, les étapes et le résultat attendu, et en couvrant les cas négatifs et les limites, vous améliorez nettement la qualité de vos vérifications. Pour poursuivre votre apprentissage, découvrez les formations en test de logiciel et en informatique proposées par Cursa.
