Dans ce guide
Si tu as créé ton app en la décrivant à un outil de code, tu as un produit qui fonctionne et une carte mentale du code plus petite que quelqu'un qui a tapé chaque ligne. Ce n'est pas grave. Cela signifie seulement que tes tests doivent s'appuyer sur ce que l'app fait, et non sur ce dont tu te souviens avoir écrit.
Ce plan prend environ un après-midi. Note chaque échec ; corrige après avoir terminé un passage, pas pendant.
1. Partir d'une installation propre
Désinstalle l'app, puis installe le build que tu prévois de publier (pas une exécution de debug depuis ton ordinateur). Ouvre-la comme un tout nouvel utilisateur.
- Le premier lancement fonctionne-t-il sans compte, sans données, sans réglages enregistrés ?
- Les demandes d'autorisation sont-elles compréhensibles, et l'app fonctionne-t-elle encore si tu tapes « Ne pas autoriser » ?
Pourquoi : la version sur ton téléphone pendant le développement contient des données et des autorisations résiduelles qu'un nouvel utilisateur n'a pas.
2. Parcourir chaque écran, puis casser l'ordre
Fais une liste des écrans et des actions. Parcours-les une fois comme prévu. Puis parcours-les mal :
- Tape deux fois vite sur les boutons.
- Reviens en arrière au milieu d'un parcours.
- Tourne le téléphone, change la taille de police, passe en mode sombre.
- Laisse l'app ouverte cinq minutes, puis reviens.
Pourquoi : les écrans générés ne sont souvent testés que sur le parcours idéal que tu as décrit. L'ordre et le timing sont là où se cachent les surprises.
3. Lui donner des entrées maladroites
Champs vides, nom très long, emoji, un nombre là où un texte est attendu, espaces seuls. Pour aller plus loin : voir la checklist de test mobile.
Pourquoi : les formulaires disent rarement ce qu'ils font des entrées que tu n'as pas décrites. On le découvre en essayant.
4. Couper le réseau
Active le mode avion à différents moments : avant l'ouverture, pendant le chargement, pendant l'enregistrement. Puis réactive le réseau.
- Y a-t-il un message compréhensible, ou un spinner sans fin ?
- Perd-on quelque chose que l'utilisateur a saisi ?
Détails dans tester le comportement hors ligne de ton app.
5. Tester sur un vrai téléphone, idéalement deux
Un émulateur est un début, pas une fin. Utilise un téléphone récent et, si possible, un plus ancien ou plus petit. Voir quels appareils Android tester.
6. Vérifier ce que tu ne vois pas
Parcours le projet à la recherche de tout ce qui ne doit pas être publié : clés, comptes de test, écrans de debug, textes de remplacement. Voir clés API et secrets dans les apps générées par IA.
7. Laisser quelqu'un d'autre essayer
Tu sais comment l'app doit être utilisée, donc tu évites ses problèmes. Donne-la à une personne qui ne l'a jamais vue et observe sans l'aider. Puis collecte les plantages et classe-les : comment prioriser les rapports de plantage.
Tiens un journal simple
Pour chaque échec, note : ce que tu as fait, ce que tu attendais, ce qui s'est passé, l'appareil. C'est aussi le format que tu peux coller plus tard dans ton outil de code. Voir bugs que les testeurs trouvent dans les apps créées par IA.
Étape suivante
AppReviewX te fournit des retours privés et structurés d'autres développeurs sur une version que tu t'apprêtes à publier. Un retour que tu rédiges rapporte un crédit ; les nouveaux comptes commencent à 0. Commencer gratuitement.
Liens : hub vibe coding, checklist de lancement, clés API et secrets.