Comment tester une application Android avant sa sortie

Définir la version candidate et la portée

Choisissez la version exacte que vous avez l'intention d'expédier et enregistrez ce qui a changé. Répertoriez les parcours les plus importants, les versions et facteurs de forme Android pris en charge, ainsi que toutes les intégrations affectées par le changement. Convenez des domaines qui sont exclus.

Choisissez une matrice de test représentative

Sélectionnez les appareils et les versions de Android en fonction de votre audience prise en charge, des données d'utilisation disponibles et de la modification que vous apportez. Incluez les appareils réels pertinents aux côtés des émulateurs lorsque cela est possible. Un résultat positif sur une configuration n’établit pas la couverture de tous les appareils.

Effectuez d’abord un court test de fumée

Confirmez l'installation, le lancement et un parcours principal complet avant de passer du temps sur le plan complet. Si un problème de blocage empêche des tests significatifs, signalez-le par rapport à la version exacte et répétez le test de fumée après le correctif.

Tester les transitions et les chemins d’échec

Vérifiez le comportement des nouvelles installations et mises à jour, les choix d'autorisations, les entrées non valides et l'accès au réseau interrompu. Exercice de mise en arrière-plan et retour à l'application. Pour les achats ou les flux de compte spécifiques à une application, utilisez des environnements de test appropriés et des comptes dédiés.

Vérifier les variations d'écran et d'accessibilité

Inspectez la plus petite fenêtre prise en charge, le texte volumineux, les orientations prises en charge et les langues pertinentes. Incluez un parcours TalkBack manuel lors de l’évaluation de l’accessibilité. Les contrôles automatisés et l'utilisation manuelle révèlent différents problèmes ; ni l’un ni l’autre n’établit à lui seul une accessibilité complète.

Enregistrez les résultats avant de prendre une décision de libération

Marquez un chèque comme réussi seulement après avoir observé son résultat attendu. Enregistrez les contrôles ayant échoué avec les références du rapport, laissez les contrôles non testés comme non vérifiés et expliquez pourquoi un élément n'est pas applicable. Passez en revue les correctifs et les risques restants avec la personne responsable de l’expédition.

Exemple : un flux de connexion modifié

Exemple de planification illustratif : une modification de connexion affecte les nouvelles connexions, les informations d'identification non valides, les sessions expirées, les nouvelles tentatives hors ligne et le retour en arrière-plan. Ajoutez la langue prise en charge et les variantes de texte volumineux les plus pertinentes pour cet écran. Enregistrez chaque résultat par rapport à la version candidate.

Gardez les éligibilités QA et Google Play séparées

Cette liste de contrôle permet d'organiser les tests de qualité. Il ne s'agit pas d'une certification officielle Google, d'un audit de sécurité ou d'une preuve qu'une condition de participation d'un testeur Google Play a été remplie. L’éligibilité à la production Google Play est un processus distinct.

Le fait de remplir la liste de contrôle signifie-t-il que l'application est prête à être expédiée ?

Non. Il résume uniquement les vérifications que vous avez effectuées. La décision de publication dépend également des problèmes non résolus, des zones exclues et des besoins de vos utilisateurs.

Combien d’appareils dois-je tester ?

Il n’existe aucun décompte universel prouvant la couverture. Choisissez des configurations représentatives pour votre public pris en charge et documentez les limites de votre matrice de test.

Puis-je utiliser la liste de contrôle sans JavaScript ?

Oui. La liste de contrôle complète se trouve dans la page HTML et peut être imprimée. Les statuts interactifs et l'exportation Markdown nécessitent JavaScript.