Tester une application mobile : sur quels appareils, et comment

Une application testée uniquement sur le téléphone du développeur fonctionne parfaitement — sur le téléphone du développeur. C’est généralement l’appareil le plus récent, le plus rapide, avec le meilleur réseau et la batterie la mieux chargée du projet.

Voici comment je constitue un parc de test utile, sans y consacrer un budget déraisonnable.

Trois appareils suffisent, s’ils sont bien choisis

L’idée d’un parc de vingt téléphones est séduisante et improductive : personne ne teste réellement sur vingt appareils, et l’entretien du parc devient un sujet en soi.

Ce que je recommande, par plateforme :

Le modèle le plus répandu chez vos utilisateurs. Cette information n’est pas une supposition : les magasins la fournissent une fois l’application publiée, et un parc d’entreprise est connu de la DSI. C’est l’appareil sur lequel un défaut touche le plus de monde.

Un appareil ancien de milieu de gamme, trois à quatre ans, mémoire limitée. C’est lui qui révèle les problèmes de performance, les fermetures par manque de mémoire et les temps de démarrage inacceptables. Sur Android, c’est de loin l’appareil le plus rentable du parc.

Le plus récent, pour les nouveaux formats d’écran, les découpes et les évolutions du système.

Sur iOS, la diversité matérielle est faible : deux appareils couvrent l’essentiel, à condition d’en avoir un ancien encore supporté. Sur Android, la diversité vient moins du matériel que des surcouches constructeurs — c’est là qu’il faut porter l’effort.

Ce que le simulateur ne montre pas

Le simulateur est excellent pour développer : rapide, scriptable, pratique pour parcourir les écrans. Il ne remplace pas un appareil pour cinq raisons.

Les performances. Il tourne sur un processeur d’ordinateur. Une animation fluide au simulateur peut saccader lourdement sur un téléphone d’entrée de gamme.

Le matériel. Appareil photo, capteurs, lecture de codes, communication sans contact : rien de tout cela n’est fidèlement reproduit.

Le réseau réel. Le simulateur utilise la connexion de la machine, généralement excellente. Il ne reproduit ni la latence mobile, ni les pertes de paquets, ni la bascule entre réseaux.

La gestion de la mémoire. Un système mobile ferme les applications en arrière-plan quand il manque de mémoire. Le simulateur, avec la mémoire d’un ordinateur, ne le fait presque jamais — et c’est précisément ce qui provoque les pertes de saisie signalées par les utilisateurs.

Les surcouches constructeurs. C’est le point le plus important sur Android. Plusieurs fabricants appliquent des politiques d’économie d’énergie très agressives qui suspendent les tâches de fond et bloquent les notifications d’applications jugées peu utilisées. Ce comportement n’existe sur aucun émulateur, et il explique une grande partie des « ça ne marche que chez certains utilisateurs ».

Les réglages qui trouvent le plus de défauts

Avant de tester des fonctionnalités, je passe l’application dans six configurations. Elles prennent dix minutes et trouvent plus de défauts que des heures de parcours nominal.

Taille de police système au maximum. C’est le réglage qui casse le plus d’interfaces : textes tronqués, boutons superposés, écrans qui ne défilent pas. Et il est réellement utilisé par une part non négligeable des utilisateurs.

Mode sombre. Même quand il n’a pas été prévu, le système l’applique partiellement. Le résultat est souvent un texte gris clair sur fond blanc, ou l’inverse.

Réseau très dégradé, pas coupé. Les outils système permettent de simuler une connexion lente. C’est là qu’on découvre les écrans qui se figent et les doubles envois.

Autorisations refusées. Position, appareil photo, notifications : refuser chacune et vérifier que l’application reste utilisable et l’explique. Un écran blanc parce qu’une autorisation manque est un défaut fréquent.

Rotation et retour d’arrière-plan. Passer l’application en arrière-plan pendant une saisie, ouvrir autre chose, revenir. La saisie doit être là. Sur Android, l’option pour développeurs qui détruit les activités en arrière-plan reproduit en une seconde ce que les utilisateurs vivent comme des pertes aléatoires.

Stockage presque plein. Cas rarement testé et pourtant courant, notamment sur les appareils anciens : l’écriture échoue, et l’application doit le dire plutôt que perdre la donnée.

Photo : domaine public (CC0).

Les tests automatisés : où les mettre

Automatiser toute l’interface d’une application mobile coûte cher et casse souvent. Je répartis l’effort différemment.

La logique métier en tests unitaires, sans interface. Calculs, règles, transformations, gestion de la file de synchronisation. C’est rapide, stable, et cela couvre la partie où les erreurs coûtent le plus.

Trois à cinq parcours critiques en tests d’interface automatisés, exécutés à chaque modification : connexion, création d’un élément, synchronisation. Pas plus. Ces tests sont lents et fragiles ; au-delà de quelques-uns, l’équipe finit par les ignorer.

Tout le reste à la main, sur un scénario écrit, avant chaque publication.

Il existe des services qui exécutent les tests sur des dizaines d’appareils réels à distance. C’est utile pour une application grand public à large diffusion ; c’est disproportionné pour une application métier destinée à un parc connu.

Photo : davide ragusa — licence CC0.

La phase de test interne, indispensable

Avant toute publication, une version part à un groupe de testeurs réels — des personnes qui n’ont pas participé au projet, sur leurs propres appareils, avec leurs propres réglages.

C’est la seule façon de découvrir ce qu’aucun scénario ne prévoit : une langue système différente, un clavier tiers qui se comporte autrement, un gestionnaire de mots de passe qui interfère avec la connexion, un appareil dont le fabricant a modifié le comportement du bouton retour.

Deux semaines et une dizaine de testeurs suffisent. C’est le meilleur investissement qualité de tout le projet mobile, et il ne coûte que de l’organisation.

Tester la mise à jour, pas seulement l’installation

Un angle mort presque systématique : on teste toujours l’application fraîchement installée, jamais la mise à jour depuis la version précédente.

Or les utilisateurs, eux, ne réinstallent pas. Ils mettent à jour, avec leurs données déjà présentes sur l’appareil — une base locale à l’ancien format, des préférences enregistrées, une session ouverte, parfois des éléments en attente de synchronisation.

Ce que je vérifie avant chaque publication : installer la version actuellement en production, créer des données, se connecter, laisser des éléments non synchronisés, puis installer la nouvelle version par-dessus. Tout doit être là.

C’est là que se trouvent les incidents les plus graves d’une application mobile, parce qu’ils sont irréversibles côté utilisateur : une migration de base locale qui échoue efface des saisies qui n’étaient pas encore remontées au serveur. Personne ne peut les récupérer.

Un cas voisin mérite le même traitement : la mise à jour depuis une version très ancienne. Certains utilisateurs sautent plusieurs versions. Si les migrations de base locale n’ont été testées qu’en série continue, le saut direct peut échouer.

Ce que je regarde après la publication

Les tests ne s’arrêtent pas à la mise en ligne — les magasins fournissent gratuitement ce qui manque le plus : les données réelles.

Le taux de plantage par version et par modèle, avec le détail technique de chaque incident. La répartition réelle des appareils et des versions de système chez vos utilisateurs, qui permet d’ajuster le parc de test. Et les temps de démarrage mesurés sur le terrain, qui sont toujours plus élevés qu’en interne.

Je consulte ces rapports dans les quarante-huit heures suivant chaque publication. C’est à ce moment qu’un défaut touchant une famille d’appareils apparaît — et qu’on peut encore arrêter le déploiement progressif avant qu’il n’atteigne tout le monde.