Un cas de test décrit de façon structurée une vérification précise. Il doit la rendre claire, reproductible et utile à l’équipe, au-delà de la simple documentation.
Ce que contient généralement un bon cas de test
- →Un titre clair qui exprime l’objectif de la vérification.
- →Conditions préalables : l'état initial du système requis.
- →Étapes de test : actions effectuées par le testeur ou le système.
- →Résultat attendu : exactement ce qui devrait arriver.
- →Si nécessaire : données de test, priorité, liens vers les exigences et remarques.
Qu'est-ce qui fait un cas de test solide
- →Il vérifie une règle ou un risque spécifique plutôt que tout en même temps.
- →Son résultat attendu est mesurable et sans ambiguïté.
- →Il contient suffisamment d’étapes pour plus de clarté sans détails inutiles.
- →Un échec montre clairement ce qui n’a pas fonctionné.
Erreurs courantes
- →Rédiger des cas trop longs qui couvrent plusieurs idées différentes à la fois.
- →Utiliser des résultats attendus vagues tels que « fonctionne correctement ».
- →Ne pas séparer les conditions préalables des étapes.
- →Dupliquer des dizaines de cas presque identiques où une liste de contrôle ou un paramétrage fonctionnerait mieux.
Quand un cas de test détaillé n’est pas nécessaire
Chaque vérification ne nécessite pas un cas de test distinct. Pour des tests smoke ou sanity rapides, des fonctions instables ou des sessions exploratoires, une documentation détaillée peut coûter plus qu’elle n’apporte. L’équipe QA choisit délibérément le format adapté.
Exemples de cas de connexion avec des exigences explicites
Ces cas reposent sur une spécification pédagogique fictive, pas sur des règles universelles de connexion. Le compte learner@example.test est actif et possède un mot de passe valide connu. Un mauvais mot de passe ou un compte inconnu affiche le même message « Invalid credentials » sans créer de session. Les champs vides déclenchent des erreurs sans envoyer de requête de connexion. Le troisième mot de passe incorrect consécutif pour un compte connu le bloque pendant 5 minutes ; une connexion réussie remet le compteur à zéro. Un compte bloqué ne peut pas se connecter, même avec le bon mot de passe.
Exécutez chaque cas indépendamment. Restaurez le compteur d'échecs indiqué, l'état de verrouillage et la session avant de démarrer ; sinon la séquence des tests précédents modifie le résultat attendu. Utilisez uniquement des informations d’identification synthétiques.
ID État initial Entrée / action Résultat attendu
L01 Compte actif, 0 échec, déconnecté Envoyer un compte connu et le mot de passe correct Session créée ; profil ouvert ; compteur à 0
L02 Compte actif, 0 échec, déconnecté Envoyer un compte connu et un mauvais mot de passe Invalid credentials ; aucune session ; compteur à 1
L03 Compte inconnu, déconnecté Envoyer unknown@example.test et un mot de passe quelconque Invalid credentials ; aucune session
L04 Déconnecté Envoyer les deux champs vides Deux erreurs de champ ; aucune requête de connexion
L05 Compte actif, 2 échecs, déconnecté Envoyer un compte connu et un mauvais mot de passe Aucune session ; compte bloqué pendant 5 minutes
L06 Compte bloqué, délai non expiré, déconnecté Envoyer un compte connu et le mot de passe correct Aucune session ; blocage maintenuDévelopper une ligne en cas de test manuel exécutable
Cas : L02 — refuser un mauvais mot de passe
Préconditions : compte actif, compteur d’échecs à 0, aucune session.
1. Ouvrir la page de connexion.
2. Saisir learner@example.test et un mot de passe volontairement incorrect.
3. Envoyer une seule fois.
Interface attendue : « Invalid credentials » ; le profil ne s’ouvre pas.
État attendu : aucune session ; le compteur d’échecs du compte connu passe à 1.
Preuves : réponse sans données sensibles et observation de l’état disponible dans l’environnement de test.Le compteur nécessite un mécanisme d'observation convenu, tel qu'une vue d'administration réservée aux tests ou un dispositif de test autorisé. Si elle n'est pas disponible, marquez cette assertion comme non vérifiée plutôt que de la déduire d'un message. Ajouter des cas de récupération, d'expiration de verrouillage, de concurrence et d'accessibilité en fonction des risques réels du produit ; les six lignes constituent un ensemble de départ et non une évaluation d'authentification complète.