Qu'est-ce qu'un cas de test ?
Un cas de test est un ensemble de conditions et d'étapes utilisées pour vérifier qu'une fonctionnalité ou une fonction spécifique d'une application logicielle fonctionne correctement. Chaque cas de test définit quoi tester, comment le tester et quel résultat attendu est attendu.
Considérez les cas de test comme les éléments constitutifs de votre processus QA. Des cas de test bien rédigés sont reproductibles, sans ambiguïté, et couvrent à la fois les parcours nominaux et les cas limites — afin que n'importe quel testeur puisse les reprendre et les exécuter de manière cohérente.
Cet article fournit un modèle de cas de test pratique, puis parcourt des exemples concrets basés sur les scénarios les plus courants de connexion et d'inscription. Ces cas de test couvrent les parcours nominaux et les cas limites clés — prêts à copier dans votre outil de gestion de test.
Modèle de cas de test
Voici un modèle de cas de test standard que vous pouvez copier dans votre outil de gestion de test, votre feuille de calcul ou votre document.
ID du cas de test : TC-[Module]-[Number]
Module : [p. ex., Connexion, Inscription]
Titre du test : [Nom court et descriptif]
Priorité : [Critique / Élevée / Moyenne / Basse]
Préconditions : [Ce qui doit être vrai avant de tester]
Données de test : [Données spécifiques à utiliser pendant le test]
Étapes de test :
1. [Étape 1]
2. [Étape 2]
3. [Étape 3]
Résultat attendu :
[Ce qui devrait se produire lorsque les étapes sont exécutées correctement]
Résultat réel :
[Ce qui s'est réellement produit — rempli pendant l'exécution du test]
Statut : [Réussi / Échoué / Bloqué / Non exécuté]
Référence du bug : [BUG-XXX si applicable]
Testeur : [Nom]
Date du test : [AAAA-MM-JJ]
Référence des champs d'un cas de test
Avant de rédiger des cas de test, comprenez ce que signifie chaque champ :
| Champ | Description | Exemple |
|---|---|---|
| ID du cas de test | Identifiant unique : TC-[Module]-[Number] |
TC-REG-001 |
| Module | Fonctionnalité/module auquel cela appartient | Inscription, Connexion, Réinitialisation du mot de passe |
| Titre du test | Description en une ligne du scénario | Inscription réussie avec un e-mail et un mot de passe valides |
| Priorité | Importance : Critique > Élevée > Moyenne > Basse | Critique = flux principal cassé ; Élevée = problème majeur ; Moyenne = cas limite ; Basse = esthétique |
| Préconditions | État qui doit être vrai avant de tester | L'utilisateur est sur la page d'inscription, l'e-mail n'est pas enregistré |
| Données de test | Valeurs spécifiques utilisées pendant le test, chaînes exactes | email = "<user@example.com>" |
| Étapes de test | Actions numérotées, une étape par action | 1. Naviguer vers l'URL ; 2. Saisir une valeur ; 3. Cliquer sur le bouton |
| Résultat attendu | Ce qui devrait se produire en cas d'exécution correcte | Compte créé, redirigé vers le tableau de bord |
| Résultat réel | Ce qui s'est réellement produit — rempli pendant l'exécution | Identique au résultat attendu / Erreur : « Cette adresse e-mail existe déjà » |
| Statut | Réussi / Échoué / Bloqué / Non exécuté | Rempli pendant l'exécution |
| Référence du bug | ID de suivi des bugs associé (si applicable) | BUG-0042 |
| Notes | Informations supplémentaires : solution de contournement, tickets liés | Reproductible uniquement dans Firefox |
Exemple complet
Voici un cas de test complet montrant comment le modèle est rempli :
ID du cas de test : TC-REG-001
Module : Inscription utilisateur
Titre du test : Inscription réussie avec un e-mail et un mot de passe valides
Priorité : Critique
Préconditions : L'utilisateur est sur la page d'inscription, aucun compte existant avec cet e-mail
Données de test : email = "newuser@example.com", password = "SecurePass123!", name = "John Doe"
Étapes de test :
1. Naviguer vers https://app.example.com/register
2. Saisir « John Doe » dans le champ Nom complet
3. Saisir « newuser@example.com » dans le champ E-mail
4. Saisir « SecurePass123! » dans le champ Mot de passe
5. Saisir « SecurePass123! » dans le champ Confirmer le mot de passe
6. Cochez la case « J'accepte les conditions d'utilisation »
7. Cliquer sur le bouton « Create Account »
Résultat attendu :
- Le compte est créé avec succès
- L'utilisateur est redirigé vers une page « vérifiez votre e-mail »
- Un e-mail de confirmation est envoyé à newuser@example.com en 30 secondes
- L'utilisateur peut se connecter avec les identifiants enregistrés après vérification de l'e-mail
Tableau de cas de test (prêt à copier-coller)
Copiez ce tableau directement dans Excel / Google Sheets / TestRail. Les 5 premières colonnes sont pré-remplies avec des données d'exemple ; les colonnes restantes sont à remplir pendant l'exécution du test.
| ID | Module | Titre du test | Priorité | Type | Préconditions | Étapes de test | Données de test | Résultat attendu | Résultat réel | Réussi/Échoué | Notes |
|---|---|---|---|---|---|---|---|---|---|---|---|
| TC-REG-001 | Inscription | Inscription réussie avec un e-mail et un mot de passe valides | Critique | Parcours nominal | Utilisateur sur la page d'inscription, e-mail non enregistré | 1. Aller sur /register 2. Saisir nom, e-mail, mot de passe 3. Accepter les conditions 4. Cliquer sur Créer | email="<newuser@example.com>", password="SecurePass123!" | Compte créé, redirigé vers la page de vérification, e-mail de confirmation envoyé en 30 s | |||
| TC-LOGIN-001 | Connexion | Connexion réussie avec un e-mail et un mot de passe corrects | Critique | Parcours nominal | Compte vérifié <user@example.com> existe | 1. Aller sur /login 2. Saisir l'e-mail 3. Saisir le mot de passe 4. Cliquer sur Se connecter | email="<user@example.com>", password="CorrectPass123!" | Authentifié, redirigé vers le tableau de bord, jeton de session défini |
Tableau de modèle vierge
Voici l'en-tête du tableau vierge. Copiez-le et ajoutez des lignes pour vos propres cas de test :
| ID | Module | Titre du test | Priorité | Type | Préconditions | Étapes de test | Données de test | Résultat attendu | Résultat réel | Réussi/Échoué | Notes |
|---|
Comment rédiger de bons cas de test : meilleures pratiques
1. Rendez chaque cas de test indépendant
Un cas de test doit vérifier un comportement spécifique. S'il échoue, vous devez savoir exactement ce qui est cassé. Ne combinez pas plusieurs scénarios dans un seul cas de test.
2. Soyez précis avec les données de test
« Saisir un e-mail valide » est vague. « Saisir <user@example.com> » est précis. Des données de test spécifiques rendent les cas de test reproductibles.
3. Couvrez le parcours nominal ET les cas limites
Le parcours nominal (connexion réussie avec des données valides) est important, mais les cas limites révèlent de vrais bugs :
- Champs vides
- Formats invalides
- Valeurs limites
- Jetons expirés
- Sessions simultanées
4. Rédigez les préconditions
Les préconditions configurent l'environnement de test. Sans elles, le testeur pourrait partir d'un état erroné et obtenir un résultat réussi/échoué faussé.
5. Utilisez des étapes numérotées claires
Chaque étape doit être une seule action. « Remplir le formulaire et envoyer » est trop vague. Décomposez-la en saisies de champs individuelles.
6. Incluez le résultat attendu en détail
« La connexion réussit » ne suffit pas. Précisez ce que l'utilisateur voit, où il est redirigé, quels e-mails sont envoyés et ce qui se passe dans la base de données.
Comment BugCapturer aide lors de l'exécution des cas de test
Lors de l'exécution des cas de test, les testeurs doivent documenter les résultats rapidement. BugCapturer, une extension Chrome gratuite pour le signalement de bugs et le retour visuel, rend cette étape sans friction :
- Captures d'écran annotées : lorsqu'un cas de test échoue, capturez l'état exact de la page avec des flèches et du texte mettant en évidence le problème — sans avoir à le décrire par des mots.
- Enregistrement d'écran : pour les scénarios complexes (par ex., un flux de connexion en plusieurs étapes avec des problèmes de synchronisation), enregistrez une courte vidéo WebM de l'exécution complète du test.
- Métadonnées techniques automatiques : l'URL, le navigateur, l'OS, la résolution d'écran et la fenêtre d'affichage sont capturés automatiquement — essentiel pour reproduire les bugs spécifiques à l'environnement.
- Données de diagnostic : les erreurs de console et les requêtes réseau ayant échoué (statut HTTP ≥ 400) sont capturées en complément des preuves visuelles. Les URL réseau sont automatiquement expurgées des paramètres sensibles.
- Export Excel/TSV : copiez en un clic une ligne de rapport de bug structurée dans votre presse-papiers. Collez-la directement dans votre outil de gestion de test ou votre feuille de calcul d'équipe.
Cela signifie que les testeurs passent moins de temps à rédiger des rapports de bug et plus de temps à exécuter des cas de test.
Téléchargement : modèle de cas de test
Copiez le modèle et les exemples ci-dessus dans le format de votre choix :
- TestRail / Zephyr / Xray — créez des cas de test avec les champs standard
- Excel / Google Sheets — utilisez-le comme une feuille de calcul avec des colonnes pour chaque champ
- Notion / Confluence — créez une base de données avec une entrée par cas de test
- Markdown — conservez-le dans votre dépôt pour le contrôle de version
Le modèle et les exemples de cet article sont prêts à l'emploi. Personnalisez les scénarios de connexion/inscription pour votre application spécifique, ajoutez vos propres modules et construisez une suite de tests complète que votre équipe QA peut exécuter en toute confiance.