Checklist de test mobile

Une checklist mobile garde visibles les risques importants parmi des dizaines d’écrans et d’appareils avant une livraison. Elle relie chaque vérification à une action précise et à un résultat observable. « Vérifier le réseau » est trop vague ; « déconnecter après l’envoi d’une commande et vérifier qu’une nouvelle tentative n’en crée pas une seconde » peut révéler un défaut.

Adaptez ce point de départ. Une application bancaire, un lecteur multimédia et un suivi d’habitudes exigent des profondeurs et des priorités différentes. Une bonne checklist se nourrit du produit, des statistiques d’usage, des changements livrés et des incidents passés.

Définir le périmètre du test

Avant de tester, relevez la version et le numéro de build, l’environnement API, la méthode d’installation, les fonctionnalités activées et les comptes de test. Créez une courte matrice d’appareils : une version OS importante, la configuration minimale prise en charge, une taille d’écran populaire et un appareil limité en ressources. Choisissez selon les utilisateurs et les risques, et précisez les exclusions.

Séparez les tests smoke de la régression étendue. Les tests smoke établissent si un build permet de poursuivre le travail et si les parcours essentiels passent. Ils ne remplacent ni les vérifications de migration de données ni les tests après plusieurs heures d’utilisation.

Installation, mise à jour et premier lancement

Vérifiez une installation neuve et une mise à jour depuis une ancienne version prise en charge. Avant la mise à jour, créez des données réalistes : brouillon, paramètres et objets hors ligne. Elles doivent ensuite être conservées ou migrées selon les exigences.

Au premier lancement, vérifiez l’accueil, la sélection de langue, les consentements requis et l’accès à l’écran principal lorsque les permissions facultatives sont refusées. Après désinstallation puis réinstallation, vérifiez la restauration selon les règles de la plateforme et du produit ; l’existence persistante d’un compte serveur ne signifie pas à elle seule que la désinstallation a échoué.

Parcours utilisateur critiques

Identifiez les actions qui motivent l’usage du produit : connexion, recherche, commande, message ou consultation d’un billet. Pour chacune, vérifiez le succès et au moins une situation d’échec.

→L’action modifie réellement les données serveur, et une reconnexion affiche l’état enregistré.
→Une liste vide indique l’étape suivante et les erreurs permettent de poursuivre.
→Les doubles appuis et les envois répétés ne créent pas de doublons interdits.
→Le clavier, les textes longs et les panneaux système ne masquent pas une action nécessaire.

Vérifier le résultat compte plus que le nombre d’écrans ouverts. Une notification temporaire correctement affichée ne prouve pas l’enregistrement d’une requête.

Réseau et fonctionnement hors ligne

Vérifiez le démarrage sans réseau, la perte de connexion pendant les lectures et écritures, les réponses lentes, la reconnexion et le passage du Wi-Fi aux données mobiles. Clarifiez le comportement des opérations locales en attente et les règles de résolution des conflits.

Pour une opération avec effets de bord, déterminez ce qui se passe si le serveur termine la requête sans que le client reçoive la réponse. L’écran ne doit ni annoncer un succès non vérifié ni imposer une répétition infinie. Après reconnexion, comparez les états local et serveur et recherchez les doublons.

Cycle de vie et interruptions système

Passez l’application en arrière-plan avec un formulaire ouvert, rouvrez-la, verrouillez l’appareil et revenez après expiration de la session. Testez séparément la recréation de l’écran, l’arrêt du processus et une simple mise en arrière-plan : leurs conditions de reprise diffèrent.

Les exigences peuvent imposer la conservation des brouillons tout en masquant les données sensibles. Le système ne doit ni perdre une opération confirmée ni la poursuivre avec des droits périmés. Vérifiez aussi les appels entrants et boîtes de dialogue système pendant un enregistrement audio, un paiement ou un téléversement lorsque le produit le permet.

Vérifiez l’octroi, le refus et la révocation ultérieure des permissions utilisées. L’application doit expliquer clairement l’indisponibilité de la caméra, de la localisation ou des notifications. Inutile d’ajouter des permissions inutilisées pour donner une impression d’exhaustivité.

Pour les notifications push, testez le premier plan, l’arrière-plan et le lancement depuis une notification. Pour les liens profonds, testez l’application installée, la session expirée, l’objet indisponible et la réouverture du lien. Une notification ne doit pas exposer les données d’un autre utilisateur après un changement de compte, et la navigation ne doit pas contourner le contrôle d’accès.

Données, sécurité et compatibilité

Avec deux comptes de test, vérifiez le changement d’utilisateur, la déconnexion et l’accès aux écrans privés précédemment ouverts. Confirmez que caches, recherche et notifications ne révèlent plus les données de l’ancien compte. Les journaux et rapports ne doivent pas contenir de vrais jetons ni de secrets utilisateur.

Vérifiez les langues, fuseaux horaires et formats de date pris en charge dans les scénarios pertinents. Le passage à minuit est particulièrement utile pour les réservations, horaires et limites quotidiennes. Répétez les scénarios les plus risqués sur d’autres appareils en tenant compte du changement livré.

Accessibilité, rapidité et stabilité

Suivez le parcours principal avec TalkBack ou VoiceOver, du texte agrandi et les réglages système convenus. Évaluez l’accès aux boutons, l’ordre du focus et les erreurs. Les scanners automatiques complètent le test manuel.

Pour les performances, comparez le lancement à froid et l’opération principale à une version de référence acceptée, dans le même environnement. Consignez la méthode et plusieurs répétitions. Vérifiez blocages, plantages, croissance mémoire après actions répétées et activité en arrière-plan ; « cela semble rapide » ne suffit pas.

Exemple pratique : test smoke d’une application de livraison

Supposons cinq vérifications obligatoires pour un nouveau build : mise à jour, connexion, panier, confirmation de commande et ouverture depuis une notification. Sur l’appareil principal, mettez à jour l’ancienne version avec une adresse enregistrée, connectez-vous, ajoutez un article, passez une commande de test et ouvrez sa notification.

Résultat attendu : adresse conservée, montant identique à chaque étape, une seule commande créée, notification ouvrant cette commande et aucun plantage. Répétez séparément la confirmation avec une réponse perdue puis une reconnexion. Sur un second appareil, vérifiez connexion et finalisation de commande. Ce test a des limites explicites ; le nombre de points réussis ne le transforme pas en régression complète.

Présenter les résultats

Pour chaque point, utilisez Réussi, Échoué, Bloqué ou Non exécuté, avec l’environnement et un lien vers le défaut. Bloqué signifie que le test était impossible, pas qu’il a réussi. Listez les blocages et risques non couverts, par exemple une mise à jour non vérifiée sur la version OS minimale.

Une checklist est utile lorsqu’elle aide à décider sur un build. Mettez-la à jour après incidents et évolutions, supprimez les doublons et automatisez les vérifications stables et répétables. Chaque point doit expliquer précisément quoi observer et pourquoi.

Lectures complémentaires

Transformer la checklist en matrice fonction × plateforme × état

Choisissez les appareils selon la plage d’OS prise en charge, l’usage réel du produit lorsqu’il est connu et les risques : pression mémoire, petits écrans et fonctions matérielles. Sans statistiques d’usage, une proposition de trois appareils reste une hypothèse fondée sur les risques, pas une couverture mesurée du marché : une configuration Android avec l’OS le plus ancien pris en charge, un Android actuel d’un autre fabricant et un iPhone pris en charge. Ajoutez des variantes d’OS et d’écran iPhone si la plage de prise en charge ou les risques le justifient.

plain text

Fonction	Plateforme / état	Action	Observation attendue	Preuve
Formulaire en cours	Android : arrière-plan / retour	Saisir du texte, changer d’application, revenir	État conforme à la règle de sauvegarde convenue ; aucun envoi en double	Build + vidéo
Formulaire en cours	iOS : inactif / arrière-plan / retour	Interrompre la saisie, revenir	État conforme à la règle de sauvegarde convenue	Build + vidéo
Caméra	Chaque plateforme ; autorisation refusée	Appeler la fonction et refuser l’autorisation	Solution de repli utilisable ; explication claire ; aucun plantage	État de l’autorisation + vidéo
Liste enregistrée	Chaque plateforme ; hors ligne / reconnexion	Charger, déconnecter, actualiser, reconnecter	Cache et nouvelles tentatives conformes aux exigences	Trace réseau + UI
Lien profond	Chaque plateforme ; démarrage à froid / à chaud	Ouvrir le lien avec et sans session	Bonne destination ou parcours de connexion sûr	Lien + état de session
Mise à niveau	Chaque parcours de mise à niveau pris en charge	Installer le nouveau build sur un état ancien préparé	Données requises préservées et migrées	Ancien/nouveau build + comparaison des données

Ne considérez pas les callbacks d’activité Android comme interchangeables avec les transitions de scènes iOS. Les activités Android peuvent être recréées ; iOS suit le cycle de vie des scènes ou de l’application. Relevez l’OS réel, l’action du cycle de vie et la reprise observée. Testez séparément refus de permission et révocation dans les réglages ; les options dépendent de la version OS et du type de permission.

Pour chaque ligne, consignez Pass/Fail/Blocked/Not run, l’appareil et l’OS exacts, le build, l’état initial et une preuve sans données sensibles. Une exécution sur simulateur ne prouve pas le comportement d’une vraie caméra, de la livraison de notifications, du changement de réseau radio ou de la pression mémoire. Choisissez les tests sur appareils réels selon le risque de la fonction, sans prétendre couvrir toutes les configurations.