Checklist de test d’une application mobile avant sa mise en ligne
Une checklist de test d’application mobile doit vérifier que les personnes peuvent terminer les parcours importants dans des conditions réelles. Ne vous contentez pas de confirmer que les écrans s’ouvrent. Testez les données, les interruptions, les permissions, les paiements, l’accessibilité, les appareils ciblés et la récupération après une erreur.
Commencez par les risques qui pourraient bloquer un utilisateur ou endommager sa confiance. Une anomalie cosmétique sur un écran secondaire ne pèse pas autant qu’une perte de données, un achat impossible à restaurer ou une connexion qui échoue après une mise à jour.
La checklist courte avant publication
| Zone | Contrôle indispensable | Preuve attendue |
|---|---|---|
| Parcours principal | Une personne termine la tâche promise sans aide | Scénario réussi sur appareil réel |
| Comptes et données | Inscription, connexion, sauvegarde, synchronisation et suppression | Données cohérentes après reprise |
| Erreurs | Réseau lent, absence de réseau, délai serveur et interruption | Message utile et récupération possible |
| Paiements | Achat, annulation, restauration et changement de compte | État d’accès correct dans chaque cas |
| Accessibilité | Lecteur d’écran, texte agrandi, contraste et commandes | Parcours critique utilisable |
| Compatibilité | Appareils, versions système, orientation et permissions | Matrice testée et signée |
| Publication | Build signé, fiche exacte, confidentialité et support | Dossier prêt pour la boutique |
1. Définissez les parcours qui ne peuvent pas échouer
Listez d’abord les résultats que votre application promet. Pour une application de réservation, le parcours critique peut aller de la recherche au paiement puis à la confirmation. Pour un outil de terrain, il peut couvrir la saisie hors connexion, la synchronisation et la reprise après conflit.
Transformez chaque parcours en scénario observable. Écrivez le point de départ, les données nécessaires, les actions, le résultat attendu et ce qui doit rester enregistré. Ajoutez les variantes qui changent le risque : nouvel utilisateur, compte existant, permission refusée, contenu vide et abonnement expiré.
Limitez la checklist de lancement aux parcours qui protègent la promesse du produit. Vous pourrez tester les écrans secondaires ensuite. Cette hiérarchie empêche une longue liste de contrôles faciles de masquer un défaut réellement bloquant.
2. Testez les comptes et le cycle de vie des données
Vérifiez l’inscription, la confirmation d’adresse, la connexion, la déconnexion, la réinitialisation du mot de passe et la suppression du compte. Testez aussi un compte incomplet, un compte ancien et une session expirée.
Suivez une donnée du début à la fin. Créez-la, modifiez-la, fermez l’application, changez d’appareil, synchronisez puis supprimez-la. Le résultat visible doit correspondre à la source de vérité. La documentation d’architecture Android recommande une source de vérité clairement définie et une séparation nette des responsabilités dans son guide d’architecture.
Testez les migrations avec une installation provenant de la version déjà publiée. Une application neuve peut fonctionner alors qu’une mise à jour casse une base locale, un cache ou une préférence créée plusieurs mois plus tôt.
3. Simulez les réseaux et interruptions réels
Une connexion parfaite cache les défauts. Lancez chaque parcours critique avec un réseau lent, une perte de connexion et une réponse serveur retardée. Interrompez l’application pendant une sauvegarde, un paiement et un téléversement. Rouvrez-la ensuite et vérifiez ce que l’utilisateur retrouve.
Un bon état d’erreur explique ce qui s’est passé, protège les données déjà saisies et propose une prochaine action. Évitez les messages techniques sans issue. Si une opération peut créer un doublon, rendez-la idempotente ou empêchez clairement sa répétition.
4. Vérifiez les permissions sans supposer un oui
Testez chaque permission quand l’utilisateur l’accepte, la refuse, la retire ensuite dans les réglages ou choisit un accès limité. L’application doit continuer à expliquer le bénéfice et offrir une solution quand la fonction reste possible sans permission.
Demandez l’accès au moment où la personne comprend pourquoi elle en a besoin. Vérifiez que la copie correspond au comportement réel. Une description de confidentialité ou une phrase système ne doit jamais promettre une utilisation plus étroite que celle du produit.
5. Contrôlez les achats et les abonnements
Testez l’achat réussi, l’annulation, l’échec, la restauration, le remboursement, l’expiration et le changement de compte. Confirmez que l’accès premium suit l’état validé par la boutique ou votre serveur, pas un indicateur local facile à désynchroniser.
Vérifiez aussi les textes, les produits chargés, la devise présentée par la boutique et le bouton de restauration. Après chaque scénario, fermez puis rouvrez l’application. Le bon droit d’accès doit persister sans obliger l’utilisateur à payer une seconde fois.
6. Testez l’accessibilité comme un parcours complet
Ne contrôlez pas seulement quelques libellés. Terminez le parcours principal avec le lecteur d’écran, un texte agrandi et des réglages de contraste. Vérifiez l’ordre de lecture, les noms des commandes, les états sélectionnés, les erreurs et les éléments qui changent dynamiquement.
Apple décrit des contrôles manuels et automatisés dans sa documentation sur les tests d’accessibilité d’une application. Android fournit aussi un cadre de tests d’accessibilité. Utilisez les outils automatisés pour trouver des défauts, puis vérifiez le parcours avec une personne et un appareil réel.
7. Construisez une matrice d’appareils raisonnable
Vous n’avez pas besoin de posséder chaque téléphone. Couvrez les versions système prises en charge, une petite et une grande taille d’écran, un appareil peu performant, les orientations autorisées et les langues qui modifient fortement la longueur du texte.
Utilisez les simulateurs pour élargir la couverture, puis réservez les appareils réels aux parcours sensibles : caméra, microphone, notifications, biométrie, Bluetooth, performances, achats et changements de réseau. Notez le modèle, le système, le build et le compte utilisés afin de reproduire un défaut.
8. Organisez une bêta qui produit des preuves
Donnez aux testeurs une mission précise au lieu de demander une impression générale. Demandez-leur d’accomplir une tâche, puis collectez le résultat, l’appareil, la version et l’étape où ils ont hésité ou échoué.
Classez les retours selon la gravité et la fréquence. Corrigez d’abord les pertes de données, les blocages, les erreurs de paiement, les risques de confidentialité et les défauts qui empêchent le parcours central. Une préférence visuelle isolée ne doit pas retarder un correctif critique.
9. Fixez des critères de sortie explicites
Un calendrier ne prouve pas qu’une version est prête. Écrivez les conditions qui autorisent la publication. Par exemple : aucun défaut bloquant ouvert, parcours critiques réussis sur la matrice cible, achats restaurables, migration validée, mesures de confidentialité cohérentes et procédure de retour documentée.
Nommez aussi la personne qui prend la décision et les signaux surveillés après mise en ligne. Conservez le build précédent, les notes de version et les étapes de retour. Une sortie réversible protège l’équipe quand la production révèle une condition absente du laboratoire.
Questions fréquentes
Combien de temps faut-il réserver aux tests ?
La durée dépend du nombre de parcours, des plateformes, des intégrations et du risque. Commencez les tests pendant le développement. Si vous attendez la fin, chaque défaut arrive au moment où le calendrier coûte le plus cher à modifier.
Faut-il automatiser toute la checklist ?
Non. Automatisez les comportements stables et répétés, notamment la logique, les données et les parcours critiques. Gardez des contrôles manuels pour l’ergonomie, l’accessibilité réelle, les appareils, les permissions et les comportements difficiles à simuler.
Quand une application est-elle prête à être publiée ?
Elle est prête quand les critères de sortie liés à son risque sont satisfaits, pas quand elle ne contient plus aucune anomalie. L’équipe doit connaître les défauts restants, leur impact, le plan de surveillance et la procédure de correction.
Conclusion
Une checklist utile suit les personnes, les données et les interruptions à travers le produit. Testez d’abord la promesse centrale, puis les comptes, les erreurs, les permissions, les paiements, l’accessibilité, les appareils et la publication. Gardez une preuve pour chaque contrôle et refusez de confondre une date de lancement avec un niveau de qualité.
