Résumé des bogues #4 : tests QA d'applications mobiles

Les tests QA d’applications mobiles demandent en général si une fonctionnalité marche. Ce qu’ils manquent, c’est tout ce qui l’entoure : un signal perdu, une interruption, un client qui a déjà épuisé son essai gratuit. Ces conditions ont produit la quasi-totalité des bogues que nous avons trouvés dans 14 produits le mois dernier.

Ces situations sont parfaitement ordinaires. La plupart des applications les rencontrent toutes dans les jours qui suivent leur lancement. Pourtant, un plan de test couvre ces cas en dernier, et bien des équipes n’arrivent jamais jusque-là. Trouver ces bogues est précisément le travail hebdomadaire de nos ingénieurs en test d’applications mobiles.

Voici les quatre défaillances qui méritent votre attention, et le produit qui a remporté notre bogue du mois.

Applications couvertes dans ce résumé :

Les sept autres produits que nous avons passés au crible en août se trouvent dans l’archive complète du bug crawl.

Des publicités qui vous enferment dehors quand le signal s'en va

Applications : Isle Survival : Land Builder, Extreme Makeover : Home Edition (toutes deux iOS)
Gravité : Critique
Type : Publicité et connectivité

Les deux jeux enregistrent à l’avance une publicité vidéo sur le téléphone pour qu’elle se lise ensuite sans à-coups. Cette partie fonctionnait, mais tout ce qui était bâti autour supposait qu’Internet serait toujours là.

Notre testeur a mis Isle Survival en mode avion, a touché Regarder et a suivi la vidéo en entier. L’écran de boutique censé suivre ne pouvait pas se charger sans connexion, et aucun bouton Fermer n’est apparu non plus. Il n’y avait aucun moyen de revenir dans le jeu. Un joueur qui regarde une publicité de bonne foi se retrouve coincé derrière elle.

Extreme Makeover : Home Edition a échoué de la même manière avec une fin différente. Sa publicité enregistrée s’est également lue hors ligne, puis le retour au jeu a produit un écran noir où plus rien ne répondait.

Les joueurs lisent les deux cas comme une défaillance du jeu plutôt que du réseau, et cette différence coûte de l’argent. Celui qui blâme le produit le désinstalle, alors qu’un signal coupé est en général pardonné.

Ce qu’il faut vérifier de votre côté : Testez toute publicité pouvant être enregistrée à l’avance avec la connexion coupée, et poursuivez les tests au-delà de la vidéo elle-même. La sortie ne doit jamais dépendre d’un écran qui ne peut apparaître que si Internet fonctionne. Lorsqu’une récompense ne peut vraiment pas être accordée hors ligne, masquez l’offre plutôt que de laisser un joueur gagner quelque chose que vous ne pouvez pas lui remettre.

Comment cela se détecte : Tests exploratoires sur du matériel réel, avec quelqu’un qui coupe délibérément la connexion aux moments les plus gênants. Les suites automatisées tournent sur un réseau sain et ne rencontrent jamais cela. Notre travail de test de jeux traite la publicité comme un domaine à part entière, et non comme une fonctionnalité qui se trouve à l’intérieur du jeu.

Résumé des bogues #4 : ce que les tests QA d’applications mobiles manquent

Des applications qui oublient où vous vous étiez arrêté

Applications : SUN AI : Audiobook &amp ; Podcasts (Android), Grounds : Fitness App for Women (iOS)
Gravité : De critique à majeure
Type : Interruptions et reprise

Tous les téléphones endorment les applications. Un appel arrive, quelqu’un consulte un message, et votre produit reste tranquillement en arrière-plan pendant une demi-minute. Ce qu’il fait au retour de la personne est une fonctionnalité, que quelqu’un l’ait conçue comme telle ou non.

SUN AI a géré l’interruption de la pire façon. Notre testeur est passé à autre chose, est revenu un instant plus tard et a trouvé un écran blanc qui ne répondait à rien du tout. Le seul remède était de fermer complètement l’application et de recommencer.

Grounds a échoué plus doucement. Notre testeur a lancé une séance, ouvert la page de détail d’un exercice, changé brièvement d’application, et s’est retrouvé sur la liste générale à la place.

Aucun des deux produits n’a compris qu’il avait été interrompu, et c’est là le fil commun. Cela explique aussi pourquoi cela passe si souvent à travers les mailles : un test écrit ne reçoit jamais d’appel téléphonique, donc on ne demande jamais à l’application d’y survivre.

Ce qu’il faut vérifier de votre côté : Quittez chaque écran qui contient quelque chose en cours, pas seulement l’écran d’accueil. Attendez quelques minutes avec d’autres applications ouvertes, assez longtemps pour que le téléphone commence à libérer la vôtre de la mémoire. Vérifiez ensuite trois choses au retour : l’écran est là où vous l’avez laissé, tout compteur en cours affiche la bonne valeur, et tout contenu audio ou vidéo est en lecture ou en pause exactement comme la personne l’a choisi.

Comment cela se détecte : Tests de régression qui intègrent l’interruption aux cas de test existants au lieu de la traiter comme un exercice distinct. Ces défaillances se concentrent sur les écrans qui maintiennent quelque chose en cours, et c’est donc là que l’effort doit porter.

Quand le chronomètre et l'application ne sont pas d'accord

Applications : Grounds : Fitness App for Women, January : AI Health Tracker (toutes deux iOS)
Gravité : De critique à majeure
Type : Chronométrage et suivi de progression

Un nombre qui grimpe promet que quelque chose est mesuré. Deux produits ont rompu cette promesse en août, et ni l’un ni l’autre n’a donné le moyen de s’en apercevoir.

January : AI Health Tracker a produit la version la plus troublante. Notre testeur a lancé un enregistrement vocal, une alarme s’est déclenchée, et il a continué à parler pendant toute sa durée. Le compteur a continué de tourner, ce qui indiquait que l’enregistrement se passait bien, mais pas un mot prononcé pendant cette alarme n’a atteint la transcription finale. L’application rendait compte d’un travail qu’elle avait discrètement cessé d’accomplir.

Grounds avait le problème le plus lourd. À mi-séance, notre testeur a réorganisé l’ordre des exercices. La coche indiquant quel exercice était déjà terminé est restée à son ancienne place au lieu de suivre le mouvement. Ainsi, un exercice que personne n’avait effectué apparaissait comme terminé, tandis que celui réellement accompli semblait intact.

Cette application a également laissé tourner son chronomètre de séance pendant que notre testeur réorganisait la liste, si bien que le temps passé à organiser a été enregistré comme du temps d’entraînement.

Pour des produits dont toute la valeur tient à un relevé honnête de ce que vous avez fait, c’est le pire résultat possible. Un chiffre erroné fait plus de dégâts qu’une absence de chiffre, parce que les gens agissent en conséquence.

Ce qu’il faut vérifier de votre côté : Interrompez tout ce qui mesure le temps ou la progression. Ouvrez un autre écran, passez à une autre application, déclenchez une alarme, prenez un appel. Comparez ensuite ce qui est rapporté à ce qui s’est réellement passé, et assurez-vous qu’un chronomètre se met en pause au moment même où l’activité s’arrête. Si le téléphone peut retirer discrètement le microphone, votre application doit s’en apercevoir et le dire.

Comment cela se détecte : Des tests fonctionnels construits autour des interruptions plutôt que des exécutions sans accroc. Il faut quelqu’un prêt à saboter délibérément sa propre tentative, ce qui est rarement la façon dont un plan de test s’écrit.

Des essais gratuits dont le produit ne sait pas tenir le compte

Applications : OLY : Personal Fitness Coach (iOS)
Gravité : Majeure
Type : Abonnements et facturation

C’est le seul bogue trouvé en août qui a réellement pris de l’argent à un client.

OLY a montré à notre testeur un mur de paiement avec un bouton indiquant Démarrer mon essai gratuit de 7 jours, et il l’a touché. Seulement, il avait déjà utilisé son offre de bienvenue, si bien qu’il ne restait aucun essai à lui accorder. Confirmer l’achat l’a facturé pour une année entière à la place. L’écran promettait une chose et le paiement en a livré une autre. Notre résumé précédent a trouvé la même faille dans les tests d’achats intégrés, où l’argent passait et rien n’arrivait.

C’est précisément le schéma que surveillent les régulateurs américains. La FTC a continué de poursuivre des affaires d’abonnement avec les pouvoirs dont elle dispose déjà, tout en retravaillant la Negative Option Rule, et l’une des plaintes porte sur un bouton d’essai gratuit ayant conduit à un débit. Un bogue ici ressemble exactement à la pratique poursuivie. Ni le client qui a payé, ni le régulateur qui en entend parler ne peut distinguer un accident d’une tromperie délibérée.

Le bogue lui-même est assez simple : le mur de paiement d’OLY était conçu pour un visiteur venant pour la première fois et n’a jamais demandé à qui il s’adressait.

Ce qu’il faut vérifier de votre côté : Testez chaque écran d’abonnement en tant que client qui revient, et pas seulement en tant que nouveau client. Vérifiez ce que votre mur de paiement propose à quelqu’un ayant déjà bénéficié d’un essai, et confirmez que le débit qui suit correspond à l’offre affichée. Traitez la promesse et le paiement comme deux faits distincts à comparer.

Comment cela se détecte : En testant toute la vie d’un compte, avec les systèmes de paiement de test des boutiques et des comptes à différents stades de leur historique. Nos tests de conformité à l’App Store couvrent les règles de plateforme auxquelles ces écrans répondent, aux côtés des règles commerciales.

Test QA d'applications mobiles : ce qu'il faut ajouter à votre checklist

Chaque point ci-dessous provient d’un bogue trouvé en août. Transmettez la liste à la personne qui teste vos versions.

Chaque publicité enregistrée : lisez-la avec la connexion coupée, puis confirmez qu’il existe encore un chemin de retour vers l’application.
Chaque écran contenant quelque chose en cours : quittez-le plusieurs minutes, puis confirmez que l’écran, les chiffres et l’audio reviennent correctement.
Chaque compteur : interrompez-le par un appel, une alarme ou un autre écran, puis comparez ce qu’il rapporte à ce qui s’est passé.
Chaque mur de paiement : consultez-le en tant que personne ayant déjà utilisé un essai, et vérifiez que le débit correspond à l’offre.
Chaque écran de chargement : lancez-le hors ligne et confirmez qu’il s’explique au lieu d’attendre indéfiniment.

Bogue du mois

Notre choix se porte sur Weglot, une plateforme de traduction. Les entreprises la connectent à leur site pour que les visiteurs puissent lire le contenu dans leur propre langue. Livrer cette page traduite est la mission première du produit, et les deux bogues trouvés signifient que l’application y échoue.

Le premier est apparu sur un site de test que notre testeur avait construit avec le plugin Weglot connecté. La mise en page se cassait dès qu’il passait de la langue d’origine à une autre. Ce niveau de défaillance a été jugé critique car il anéantissait la promesse principale de l’application en endommageant la structure du site.

Le second concerne les corrections faites à la main. Weglot traduit un site automatiquement, et le propriétaire peut corriger manuellement ce que le logiciel a mal rendu. Notre testeur a fait exactement cela, puis a indiqué à la plateforme de cesser d’utiliser la sortie automatique afin que seule la version corrigée à la main s’affiche. Aucune de ces corrections n’est apparue sur le site.

La mention honorable revient à Isle Survival. Un joueur endure une publicité entière, ne peut pas revenir dans le jeu et doit le fermer. Beaucoup se contenteront de le supprimer.

Personne n’a envie d’apprendre l’existence de tels bogues par un client. Parlez-nous de votre application et nous les trouverons avant lui.

FAQ

Qu'est-ce que le test QA d'applications mobiles ?

Le test QA d’applications mobiles consiste à vérifier qu’un logiciel se comporte correctement sur des appareils réels avant que les clients ne l’utilisent. Il couvre le bon fonctionnement des fonctionnalités, mais aussi la façon dont le produit réagit lorsqu’il est interrompu, perd le signal ou rencontre quelqu’un qui s’en est déjà servi. Ces conditions imprévues causent les problèmes les plus graves, car elles apparaissent rarement dans une exécution de test scriptée.

Pourquoi tant de bogues d'applications n'apparaissent-ils que hors ligne ?

Parce que la plupart des tests se déroulent avec une bonne connexion, si bien que personne n’observe jamais ce que fait une application sans elle. Les produits sont construits pour réussir, et ils gèrent en général une requête qui échoue franchement, mais peu d’équipes décident de ce qui se passe entre les deux. Un écran attend indéfiniment, un bouton ne fait rien, ou une publicité enregistrée se lit alors que le reste de l’application ne peut pas se charger.

Les tests automatisés peuvent-ils détecter les bogues hors ligne et d'interruption ?

Ils en détectent certains, pas la majorité. L’automatisation est efficace pour confirmer qu’une fonctionnalité marche toujours et pour repérer les différences entre versions. Elle peine avec les sessions interrompues, les connexions absentes et tout ce qu’une personne doit juger à l’œil. Cela demande quelqu’un tenant un vrai téléphone, et c’est pourquoi les tests exploratoires restent une composante de tout plan sérieux.