Définissez la version et les conditions de test
Imaginons une blanchisserie de Budapest modifiant l’écran des adresses enregistrées dans son application de collecte. Les clients existants doivent choisir leur adresse habituelle et retrouver leurs commandes passées. Convenez de la version à valider, des versions antérieures permettant la mise à jour, ainsi que des téléphones et systèmes pris en charge.
Les principes de test d’Android distinguent les composants des parcours complets. Demandez quelles preuves couvrent chaque point. Utilisez un tableau compact indiquant version, appareil, langue et état initial du compte. Multiplier les combinaisons prend du temps : privilégiez celles de vos clients et consignez ce qui reste non testé.
Simulez une mise à jour avec des données existantes
Dans l’ancienne version, enregistrez deux adresses fictives et un historique de commandes exemple sur un compte test. Installez la mise à jour par le circuit de distribution de test de l’équipe, sans supprimer l’application. Comparez ensuite adresses, sélection par défaut et détails des commandes au résultat attendu convenu.
Une installation neuve se prépare plus vite, mais laisse cette situation initiale inexplorée. Gardez les deux vérifications. Une nouvelle connexion au compte peut être voulue ; perdre une adresse enregistrée nécessite une investigation. Utilisez des données inventées pour éviter d’exposer les adresses de vrais clients dans les enregistrements et signalements.
Interrompez une tâche à un moment pertinent
Les recommandations qualité d’Android couvrent interruptions et variations du réseau. Pour la blanchisserie, commencez à modifier une consigne de collecte, passez à une autre application, puis revenez. Comparez le résultat à la promesse de sauvegarde des brouillons. Recommencez en verrouillant l’écran et relevez le moment précis d’une perte inattendue.
Ouvrez ensuite l’historique sur une connexion volontairement ralentie, puis coupez-la. Le client distingue-t-il les informations déjà chargées d’une actualisation échouée ? Rétablissez la connexion et vérifiez que la commande affichée appartient au même compte. Convenez des messages attendus avant les tests pour identifier les échecs de manière cohérente.
Incluez différents réglages des clients
Si l’application propose un raccourci de localisation, choisissez une adresse après avoir refusé cette autorisation. Essayez un texte agrandi et un lecteur d’écran, notamment après un retour depuis une autre application. Demandez à une personne connaissant cette technologie d’assistance de trouver et modifier l’adresse enregistrée sans aide.
React Native précise que les tests de composants JavaScript n’exécutent pas le code natif sous-jacent. Demandez une démonstration sur chaque plateforme mobile prise en charge. Le code partagé peut réduire le développement en double, mais une vérification réussie sur une plateforme ne remplace pas celle de l’autre.
Validez des preuves liées à une version précise
Gardez une courte fiche de version consultable ensemble par le propriétaire, le développeur et le contact d’assistance. Si une correction produit une nouvelle compilation, répétez les vérifications concernées et le parcours client essentiel avant validation.
- Notez la compilation testée et les versions antérieures utilisées pour les mises à jour.
- Conservez les résultats attendus et observés pour les adresses et l’historique.
- Listez interruptions, conditions réseau et réglages d’accessibilité testés.
- Attribuez aux problèmes non résolus un responsable et une décision explicite de publication.
- Désignez qui traite les signalements clients et examine les premiers échecs rapportés.