Un cas de test est un ensemble documenté de conditions et d'étapes qui vérifie si un logiciel se comporte comme prévu. Écrire de bons cas de test s'apprend. En écrire de mauvais est l'une des façons les plus fréquentes pour les ingénieurs QA de ralentir leur équipe sans s'en rendre compte.

Ce qu'un cas de test n'est pas

Un cas de test n'est pas une liste de clics. "Aller sur la page de connexion. Saisir le nom d'utilisateur. Saisir le mot de passe. Cliquer sur soumettre. Vérifier la page." Ça indique quoi faire mais pas quoi vérifier, quel est le comportement attendu, ni ce que signifie "correct".

Un cas de test est un contrat : étant donné ces conditions et ces actions, ce résultat précis doit se produire.

Les composantes d'un cas de test

Chaque cas de test nécessite ces champs. L'outil ou le modèle exact importe peu (TestRail, Zephyr, Notion, une feuille de calcul), mais ces éléments doivent être présents quelque part.

ID du cas de test : Un identifiant unique. TC-001, AUTH-005, ITEMS-032, selon ce qu'utilise votre équipe. Permet de le référencer dans les rapports de bug et les matrices de traçabilité. Titre : Une phrase décrivant ce qui est testé, précise, sans mots vagues. Mêmes règles que pour les titres de rapport de bug. Préconditions : Ce qui doit être vrai avant que le test commence. Statut du compte utilisateur, données devant exister, état du système, environnement. Étapes du test : Les actions exactes à réaliser, numérotées, dans l'ordre. Chaque étape est une action. Données de test : Les entrées spécifiques utilisées. Pas "saisir un e-mail valide" mais "saisir admin@becomeqa.com". Résultat attendu : Ce qui doit se passer après la dernière étape. Précis, observable, vérifiable. Priorité : À quel point ce cas de test est critique. Haute (bloque la release s'il échoue), Moyenne (importante mais avec une solution de contournement), Basse (agréable à avoir). Statut : Passé, Échoué, Bloqué, Non exécuté.

Un cas de test minimal

ID: AUTH-001
Titre: L'utilisateur peut se connecter avec des identifiants valides

Préconditions:
- Le compte admin@becomeqa.com existe avec le mot de passe testpass123
- L'utilisateur n'est pas actuellement connecté

Étapes:
1. Naviguer vers https://lab.becomeqa.com
2. Cliquer sur le bouton "Login" dans la navigation
3. Saisir "admin@becomeqa.com" dans le champ Username
4. Saisir "testpass123" dans le champ Password
5. Cliquer sur "Submit"

Résultat attendu:
- La modale se ferme
- La page du dashboard est affichée
- Le titre "My Travel Items" est visible
- La navigation affiche le nom ou l'avatar de l'utilisateur connecté

Priorité: Haute

C'est complet. Un ingénieur QA débutant pourrait l'exécuter sans poser de questions. Un développeur pourrait en écrire un test automatisé directement.

Comment écrire des cas de test pour la fonctionnalité de connexion

La connexion génère plus de cas de test que le chemin heureux. Une fonctionnalité de connexion complète nécessite au minimum :

Chemin heureux : identifiants valides, connexion réussie. Chemins négatifs :
  • Mot de passe incorrect → message d'erreur, pas de redirection
  • Nom d'utilisateur inexistant → message d'erreur (attention : ne pas révéler si l'e-mail existe)
  • Nom d'utilisateur vide → erreur de validation
  • Mot de passe vide → erreur de validation
  • Les deux vides → erreur de validation
Cas limites : adresse e-mail de longueur maximale, mot de passe de longueur maximale, et mot de passe avec des caractères spéciaux (!@#$%^&*). Cas de sécurité : injection SQL dans le champ du nom d'utilisateur (ne doit pas casser l'application) et injection de script () qui doit être échappé, pas exécuté. Cas UX : le champ mot de passe doit masquer les caractères, Entrée dans ce champ doit soumettre le formulaire, et le lien "Mot de passe oublié" doit être présent et fonctionnel.

Ça fait 12 cas de test ou plus pour une seule fonctionnalité. Décider combien en écrire relève du jugement, en fonction du risque. La connexion d'un prestataire de paiement les nécessite tous ; un outil d'administration interne utilisé par 5 personnes en nécessite moins.

Techniques de conception de cas de test

Partitionnement en classes d'équivalence

Plutôt que de tester chaque âge possible de 0 à 120, divisez l'espace d'entrée en groupes devant se comporter de façon identique. Testez une valeur de chaque groupe.

Pour un champ âge acceptant 18 à 65 ans :

  • Partition valide : toute valeur de 18 à 65 (tester une : 35)
  • Invalide en dessous : toute valeur sous 18 (tester une : 15)
  • Invalide au-dessus : toute valeur au-dessus de 65 (tester une : 70)
  • Type invalide : entrée non numérique (tester une : "vingt")

Quatre cas de test au lieu de 120.

Analyse des valeurs limites

Les bugs se concentrent aux limites. Testez les bords de chaque partition.

Pour le même champ âge de 18 à 65 ans :

  • 17 : juste en dessous de la borne inférieure (invalide)
  • 18 : borne inférieure (valide)
  • 65 : borne supérieure (valide)
  • 66 : juste au-dessus de la borne supérieure (invalide)

Combiné au partitionnement en classes d'équivalence : 4 valeurs bien choisies couvrent l'ensemble de la plage.

Tests par table de décision

Quand plusieurs conditions se combinent pour produire des résultats différents, une table de décision cartographie toutes les combinaisons :

| Connecté | Abonnement actif | Affiche le contenu premium |

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

| Non | quelconque | Non |

| Oui | Non | Non |

| Oui | Oui | Oui |

Écrivez un cas de test par ligne. Les tables de décision sont excellentes pour les règles métier avec plusieurs conditions.

Écrire des cas de test à partir d'une user story

User story : "En tant qu'utilisateur, je peux ajouter un élément de voyage avec un nom de destination et un statut."

C'est un point de départ, pas une spécification complète. Avant d'écrire des cas de test, demandez : quels sont les statuts valides ? La destination est-elle obligatoire ? Quelle est la longueur maximale ? Que se passe-t-il si vous soumettez un formulaire vide ?

Obtenez d'abord les réponses, puis écrivez les cas de test. Les cas de test écrits à partir d'exigences ambiguës sont généralement incorrects. Pas parce que le testeur est incompétent, mais parce que l'exigence ne précisait pas le comportement.

ID: ITEMS-001
Titre: L'utilisateur peut créer un nouvel élément de voyage avec des données valides

Préconditions:
- L'utilisateur est connecté en tant que admin@becomeqa.com
- Le dashboard est affiché avec le tableau des éléments

Étapes:
1. Cliquer sur le bouton "Add Item"
2. Saisir "Tokyo" dans le champ Destination
3. Sélectionner "Planned" dans la liste déroulante Status
4. Cliquer sur "Save"

Résultat attendu:
- La modale se ferme
- La nouvelle ligne "Tokyo" avec le statut "Planned" apparaît dans le tableau
- Une confirmation de succès est affichée (toast ou message)

Priorité: Haute

ID: ITEMS-002
Titre: Le formulaire d'ajout affiche une erreur de validation quand la destination est vide

Préconditions:
- L'utilisateur est connecté en tant que admin@becomeqa.com
- La modale d'ajout est ouverte

Étapes:
1. Laisser le champ Destination vide
2. Sélectionner "Planned" dans la liste déroulante Status
3. Cliquer sur "Save"

Résultat attendu:
- Le formulaire ne se soumet pas
- L'erreur de validation "Destination is required" apparaît sous le champ Destination
- La modale reste ouverte

Priorité: Haute

Ce qui fait un bon ou un mauvais cas de test

Bon :
  • Assez précis pour être reproduit sans poser de questions
  • Le résultat attendu est observable et vérifiable (pas "la page fonctionne correctement")
  • Les préconditions sont complètes
  • Un seul résultat attendu par cas de test
  • Les étapes sont séquentielles et non ambiguës
Mauvais :
  • "Vérifier que la connexion fonctionne" (que signifie "fonctionne" ?)
  • Préconditions manquantes (le test échouera parce que les données n'existent pas)
  • Étapes regroupées en une seule ("remplir le formulaire et soumettre"), trop vagues
  • Plusieurs résultats attendus dans un seul cas de test (si l'un échoue, vous ne savez pas quelle condition a lâché)
Un cas de test doit pouvoir être exécuté par quelqu'un qui n'a jamais vu la fonctionnalité. Si vous devez ajouter un contexte mental quand vous relisez vos étapes, le cas de test n'est pas assez précis.

Quand écrire des cas de test, quand tester de façon exploratoire

Écrivez des cas de test pour les scénarios de régression réexécutés régulièrement, les fonctionnalités à haut risque ou complexes, et les flux qui seront éventuellement automatisés. Incluez aussi tout ce qui nécessite une validation d'un propriétaire de produit ou d'un stakeholder.

Testez de façon exploratoire pour les nouvelles fonctionnalités avant que les cas de test soient écrits, les cas limites que vous découvrez en cours de test, et tout ce qui est trop limité dans le temps pour justifier l'écriture de scripts.

Les deux approches ont leur place. Les meilleurs ingénieurs QA savent quand utiliser laquelle.

FAQ

Combien de cas de test suffisent pour une fonctionnalité ?

Assez pour vous donner confiance que la fonctionnalité fonctionne correctement sur ses chemins principaux, ses cas limites et ses conditions d'erreur. Il n'y a pas de nombre fixe. Un formulaire simple à deux champs en nécessite moins qu'un flux de paiement multi-étapes complexe.

Faut-il écrire les cas de test avant ou après le développement ?

Avant, ou pendant. Écrire des cas de test avant le développement force la clarification des exigences ambiguës. Ça produit aussi une checklist de tests prête à l'emploi quand le développement se termine. C'est l'approche shift-left.

Mes cas de test échouent sans arrêt parce que les exigences changent. Que faire ?

Mettez à jour les cas de test au fil des changements d'exigences. Des cas de test reflétant des exigences obsolètes sont pires qu'inutiles. Ils donnent une fausse confiance. Traitez les cas de test comme de la documentation vivante, pas comme des artefacts immuables.

Dois-je écrire des cas de test pour les tests automatisés ?

Les tests automatisés sont une forme de cas de test exécutables. Si votre test automatisé est bien écrit et lisible, il est le cas de test. Vous n'avez pas besoin d'un document manuel séparé qui duplique ce que le code dit déjà.

→ See also: L'Anatomie d'un Rapport de Bug que les Développeurs Corrigent Vraiment | Tests Basés sur les Risques: Prioriser ce qu'il Faut Tester Quand On Ne Peut Pas Tout Tester | Cas de Test vs Scénario de Test: Différence et Quand Utiliser Chacun | Techniques de Conception de Cas de Test: EP, BVA, Tables de Décision, Transition d'États | Comment Écrire un Plan de Test: Modèle et Exemples Réels