Dans ce guide
Un émulateur est un bon premier passage. Il est rapide et gratuit, et tu peux le faire tourner dans la même fenêtre que ton éditeur. Mais c'est une modélisation d'un téléphone, et les détails qu'un modèle omet sont justement ceux que rencontrent les vrais utilisateurs. Cela vaut pour toute app, quelle que soit sa méthode de création. Cela compte un peu plus quand tu n'as pas écrit chaque ligne toi-même, car tu as moins d'intuition des endroits où elle pourrait être fragile.
Ce qu'un vrai téléphone révèle
- Vitesse et chauffe. Un écran fluide sur ton ordinateur peut saccader sur un téléphone plus ancien ou moins cher. Fais défiler de longues listes, ouvre l'écran le plus lourd et utilise l'app pendant dix minutes.
- Autorisations. Caméra, localisation, notifications, stockage : appuie sur « Autoriser », puis sur « Ne pas autoriser », puis désactive-la plus tard dans les réglages système. L'app s'explique-t-elle et fonctionne-t-elle encore ?
- Le clavier. Couvre-t-il le champ de saisie ? Le bon type de clavier apparaît-il pour un e-mail ou des chiffres ? Que se passe-t-il quand tu le fermes avec le geste retour ?
- Interruptions. Un appel, une notification, un changement d'app, une rotation de l'écran, une mise en veille. Reviens dans l'app : ta saisie est-elle toujours là ?
- Connexions réelles. Signal faible, passage du Wi-Fi aux données mobiles, mode avion. Voir tester le comportement hors ligne.
- Tactile et taille. Les boutons sont-ils faciles à toucher avec le pouce ? Le texte tient-il sur un petit écran et avec de grandes polices système ?
- Installation et mise à jour. Installe le build de publication à neuf, puis mets-le à jour par-dessus une ancienne version. Les données survivent-elles ?
Tu ne peux pas vérifier tout cela de façon convaincante depuis un ordinateur.
Un plan d'appareils court
Tu n'as pas besoin d'un tiroir rempli de téléphones. Couvre les différences, pas la quantité. Ce tableau ne contient volontairement aucune donnée de part de marché ; choisis parmi ceux que tu peux obtenir.
| Emplacement | Pourquoi | Où l'obtenir |
|---|---|---|
| Ton propre téléphone | Usage quotidien, habitudes réelles | Tu l'as déjà |
| Un téléphone plus ancien ou moins cher | Montre les limites de vitesse et de mémoire | Un ami, la famille, un téléphone d'occasion |
| Un téléphone avec une taille d'écran différente | Problèmes de mise en page | Idem |
| Une autre version d'OS | Le comportement et les boîtes d'autorisation diffèrent selon les versions | Idem, ou un testeur |
| Une personne qui n'est pas développeuse | Trouve les étapes que tu ne vois plus | Demande-lui |
Quels modèles et versions privilégier est traité dans quels appareils Android tu devrais vraiment tester.
Quand tu ne peux pas obtenir les appareils
Demande à des testeurs. Des retours privés et structurés de personnes sur leur propre téléphone te donnent accès à des appareils que tu ne possèdes pas, et le rapport contient le modèle et la version d'OS. Demande-le explicitement dans ton brief de test.
Pour Google Play, l'exigence de test fermé met déjà ton app entre les mains des téléphones d'autres personnes. Voir les exigences du test fermé (DE) et ce qui compte comme 14 jours (DE). Utilise ces jours pour des retours réels, pas seulement pour un compteur.
Une passe de 30 minutes
- Installe le build de publication sur un vrai téléphone.
- Premier lancement, inscription, parcours principal, de bout en bout.
- Refuse chaque autorisation une fois, accorde-la une fois.
- Interromps l'app de trois façons : appel ou notification, changement d'app, rotation.
- Active le mode avion au milieu d'un parcours.
- Note chaque problème avec étapes, attendu, réel, appareil. Puis utilise le modèle de consigne si tu corriges avec un assistant.
Où se situe AppReviewX
AppReviewX te fournit des retours privés et structurés d'autres développeurs sur leurs propres téléphones. Un retour que tu rédiges rapporte un crédit, les crédits achètent des retours sur ton app, et les nouveaux comptes commencent avec 0 crédit. Pour Android, il existe des groupes de test de 12 testeurs pendant 14 jours d'affilée pour l'exigence de Google Play.
Liens : hub vibe coding, comment tester avant le lancement, checklist de lancement.