Écrire un cas de test mobile
Le gain du jour : structurer un cas de test lisible, reproductible par n’importe qui dans l’équipe, et savoir où le stocker pour qu’il reste utile dans le temps.
L’anatomie d’un bon cas de test
Un cas de test mal écrit ressemble à une note personnelle : compréhensible par son auteur, opaque pour le reste de l’équipe. Un bon cas de test contient toujours ces éléments :
- ID — un identifiant unique et stable (
TC-042), pour pouvoir le référencer ailleurs (un bug report, un rapport de campagne). - Titre — une phrase courte et descriptive, pas « test 1 ».
- Préconditions — l’état de départ nécessaire (compte déjà créé, connexion WiFi active, permission caméra déjà accordée…).
- Étapes — numérotées, une action par ligne, sans ambiguïté.
- Résultat attendu — précis et vérifiable, pas « ça marche ».
- Priorité — critique, haute, moyenne, basse (lien avec la priorisation par risque vue en leçon 2).
- Environnement — appareil, version d’OS, version d’app testée.
Exemple concret
ID : TC-042
Titre : Connexion avec identifiants valides après déconnexion
Préconditions :
- Un compte existe (email: test@exemple.com, mot de passe valide)
- L'utilisateur est déconnecté
- Connexion réseau active (WiFi)
Étapes :
1. Ouvrir l'app
2. Sur l'écran de connexion, saisir l'email valide
3. Saisir le mot de passe valide
4. Taper sur « Se connecter »
Résultat attendu :
- L'utilisateur est redirigé vers l'écran d'accueil en moins de 3 secondes
- Le nom de l'utilisateur apparaît dans le menu du profil
Priorité : Critique
Environnement : Pixel 7, Android 14, app v3.2.1« La connexion fonctionne » n’est pas un résultat attendu exploitable : deux testeurs différents peuvent en avoir une lecture différente. « L’utilisateur est redirigé vers l’écran d’accueil en moins de 3 secondes, son nom apparaît dans le menu du profil » laisse beaucoup moins de place à l’interprétation — et devient directement transformable en assertion automatisée (leçon 11).
Où stocker les cas de test : du tableur à l’outil dédié
Pour une petite équipe ou un projet naissant, un Google Sheet partagé entre développeurs et testeurs suffit largement : une feuille avec les colonnes ID, Titre, Préconditions, Étapes, Résultat attendu, Priorité, Statut (Passé / Échoué / Bloqué / Non exécuté), Dernière exécution. Son avantage principal est la communication directe — un développeur peut consulter la même feuille que le testeur sans changer d’outil, laisser un commentaire sur une ligne, ou filtrer par statut avant une mise en production.
Quand le volume de cas de test grandit (des centaines, voire des milliers), un outil dédié comme TestRail, Zephyr ou Xray (plugin Jira) devient pertinent : gestion des versions de cas de test, exécution en masse, rapports de couverture automatiques, intégration directe avec le tracker de bugs. Le principe reste le même que dans un tableur — seule la mise à l’échelle change.
Cette structure ID / préconditions / étapes / résultat attendu a un cousin plus proche
du métier : le format Gherkin (Given / When / Then), lisible par un product
owner et directement exécutable par un outil d’automatisation. C’est l’objet de la
leçon 8.
Vérifie ta compréhension
Lequel de ces résultats attendus est correctement formulé pour un cas de test ?
Pourquoi une petite équipe démarre-t-elle souvent avec un Google Sheet plutôt qu'un outil dédié comme TestRail ?
À toi de jouer
Choisis une fonctionnalité d’une app que tu utilises et rédige un cas de test complet (ID, préconditions, étapes, résultat attendu, priorité) selon la structure de cette leçon.
Crée un Google Sheet à colonnes ID / Titre / Étapes / Résultat attendu / Statut, et ajoutes-y trois cas de test pour une même fonctionnalité — un cas nominal, un cas limite, un cas d’erreur.
🗂 Fiche de référence associée : Glossaire QA mobile — antisèche.