Résumé des Bugs QAwerk #3 : Échecs Tests Achats Intégrés

Les tests d’achats intégrés ont un angle mort, situé juste après le paiement. Une fois l’argent transféré, le travail semble terminé, si bien que l’échange qu’il devait acheter reste non vérifié.

Nous en avons vu un exemple dans Idle Cash – Merge Tycoon. L’application propose un échange clair : regarder la publicité, obtenir le skin, pourtant nous avons trouvé les deux sens cassés en une seule exploration. Notre testeur a regardé une publicité complète et reçu des gemmes, l’objet promis arrivant avec 10 à 15 minutes de retard. Lors d’un second essai, il a sauté la publicité et a quand même fait tourner la roue encore et encore, accumulant des récompenses non méritées.

Aucun des deux cas n’a signalé l’échec, si bien que le coût apparaît dans ce que les gens font ensuite. Un plantage dit au moins à quelqu’un que la tentative a échoué, il sait donc qu’il doit réessayer plus tard. Ne rien recevoir en retour les laisse en revanche dans l’incertitude, et ils réessaieront, supposeront qu’un débit a eu lieu, ou abandonneront.

Repérer ces échecs avant vos joueurs, c’est à cela que sert notre travail de tests de jeux. Aujourd’hui, nous rapportons les résultats de l’équipe QAwerk Bug Crawl, qui a testé neuf produits et enregistré 55 bugs. Quatre étaient des jeux iOS, un une application Android, et le reste des outils web. Le même schéma est apparu dans beaucoup d’entre eux.

La plupart de ces échecs se situent sur l’un de quatre échanges entre un produit et son utilisateur. L’argent devrait acheter un droit, la monnaie premium un avantage, une impression publicitaire une récompense, et une demande de restauration le retour de l’accès. Ces explorations ont carrément cassé trois des quatre, et le dernier a échoué avant même qu’un paiement puisse commencer. Le même schéma apparaît ensuite là où aucun argent ne circule du tout, dans les permissions et dans le rapport de statut.

Applications couvertes dans ce résumé :

Monnaie Premium qui n’Achète Rien

Applications : Hay Day, Idle Golf Club Manager Tycoon (les deux iOS)
Gravité : Critique à Majeure
Type : Monétisation et monnaie premium

Hay Day est le simulateur de ferme de Supercell, avec une note de 4,7 sur 642 000 avis et plus de 700 000 téléchargements. Il vend l’un des échanges les plus familiers du jeu mobile : payer de la monnaie premium, terminer plus tôt.

Notre testeur a commencé à produire un repas et a attendu que le minuteur apparaisse. Il avait assez de monnaie premium en main, puis a appuyé sur Accélérer. Rien ne s’est passé.

Le minuteur n’a pas baissé et la production ne s’est pas accélérée. En conséquence, le joueur se retrouve à appuyer sur un bouton que le jeu présentait comme fonctionnel. Que la monnaie ait été dépensée pour rien ou n’ait jamais bougé, impossible de le savoir. Clarifier cette question passe en premier, car elle distingue un bouton mort d’un débit silencieux.

Pendant ce temps, Idle Golf Club Manager Tycoon a produit la même forme d’échec sur un compteur de récompenses. Son écran Récompenses affichait des tours disponibles alors que le bouton Tourner restait inactif. Le jeu se contredisait aussi sur le compte, en affichant quatre à un endroit et 0/5 utilisés à un autre. Aucun chiffre n’explique l’autre, si bien que les joueurs finissent par deviner.

Pourtant, le vrai problème n’est pas l’action bloquée mais ce qu’un utilisateur en conclut. Un compteur affirmant que vous possédez quelque chose, relié à un bouton qui ne le dépense pas, apprend aux joueurs à douter de l’interface. Une fois que les acheteurs cessent de croire aux autres soldes et minuteurs, vos extras payants commencent à ressembler à un mauvais pari.

Ce qu’il faut vérifier de votre côté : Les tests d’achats intégrés commencent par une assertion de bout en bout sur chaque dépense de monnaie, pas une vérification de l’état du bouton. Confirmez trois choses à la fois : le solde a correctement baissé, l’avantage s’est appliqué, et l’interface affiche les deux. Exécutez ensuite les cas négatifs : trop peu de monnaie, une dépense interrompue en plein vol, et deux appuis rapides. Tout chiffre apparaissant sur plus d’un écran mérite une comparaison partout où il apparaît en une seule session.

Comment cela se détecte : Des tests fonctionnels manuels, par quelqu’un qui dépense la monnaie puis cherche ce qu’elle a acheté. L’automatisation confirme que le bouton se déclenche, mais rarement que la production s’est réellement accélérée. Notre guide sur les tests de fonctionnalité des jeux couvre la construction d’une couverture autour de l’économie et des flux de récompense plutôt que des écrans.

Publicités Récompensées qui Échouent dans les Deux Sens

Application : Idle Cash – Merge Tycoon (iOS)
Gravité : Majeure (deux constats)
Type : Publicités récompensées et droits

C’est le constat le plus instructif de l’ensemble, car un système a échoué à la fois pour le joueur et pour l’éditeur.

Notre testeur a choisi un skin gratuit offert pour une publicité récompensée, l’a lancée, et l’a laissée se terminer. De retour sur l’écran Skins, rien ne s’était débloqué. Des gemmes étaient arrivées à la place, accompagnées d’un message indiquant qu’une autre publicité n’était pas encore disponible. Le skin est apparu environ 10 à 15 minutes plus tard, bien après que le joueur l’a mérité.

Dans le second constat, notre testeur a utilisé le seul tour gratuit, puis a appuyé de nouveau sur le bouton. Il affichait une icône publicitaire, une publicité aurait donc dû être obligatoire. La roue a tourné quand même. Appuyer à répétition a produit d’autres tours, sans aucune publicité à aucun moment.

Mettez cela ensemble et vous obtenez un système de monétisation qui ne sait pas ce qui s’est passé. Aucune cause profonde n’apparaît dans l’exploration, bien que les deux constats pointent dans la même direction. L’événement publicitaire, l’octroi du droit et l’état du bouton ne concordent pas. Une direction retarde la récompense du joueur au-delà du moment où il l’a méritée. À l’inverse, l’autre distribue des tours que l’impression publicitaire n’a jamais payés.

Ce qu’il faut vérifier de votre côté : Les tests d’achats intégrés devraient traiter chaque échange récompensé comme un contrat à deux faces. Prouvez que les deux côtés se déclenchent exactement une fois. Regardez une vidéo récompensée jusqu’au bout et confirmez que l’objet promis arrive immédiatement, pas un substitut et pas avec un délai. Attaquez ensuite le sens inverse en appuyant à répétition, en appuyant pendant le chargement d’une publicité, en en fermant une tôt, et en mettant l’application en arrière-plan. Après chaque tentative, vérifiez si la récompense est arrivée quand même et si le temps de recharge a survécu.

Comment cela se détecte : C’est le terrain des tests de régression, délibérément visé sur le SDK publicitaire plutôt qu’autour. La propre recommandation de l’exploration couvrait les récompenses retardées, les appuis répétés, les publicités interrompues, les changements de réseau et la mise en arrière-plan de l’application. C’est précisément la matrice qu’un plan de chemin heureux saute. La médiation publicitaire se comporte différemment sur du matériel physique dans des conditions réseau réelles. Cela nécessite des tests d’applications mobiles sur appareils plutôt que sur simulateurs.

Résumé des Bugs QAwerk #3 : Échecs des Tests d’Achats Intégrés

Le Même Bug de Restauration d’Achat dans Trois Jeux Sans Rapport

Applications : Idle Golf Club Manager Tycoon, Idle Cash – Merge Tycoon, Clear Age (toutes iOS)
Gravité : Majeure à Mineure
Type : Restauration d’achat

Dans le Résumé des Bugs #1, nous avons publié une checklist de couverture. Une ligne soulignait ceci : « Chaque flux IAP, y compris Restaurer l’Achat : afficher les indicateurs de chargement, les états de réussite et les erreurs. » Deux résumés plus tard, nous voyons les mêmes problèmes dans un ensemble complètement différent de produits testés. Trois des quatre jeux que nous avons explorés livraient une restauration cassée, un rappel frappant de l’étendue persistante du problème.

Idle Golf Club Manager Tycoon ne rendait absolument rien. Appuyer sur Restaurer l’Achat ne produisait aucune confirmation, aucun indicateur de chargement, aucun message de réussite et aucune erreur. Les utilisateurs ne peuvent pas distinguer « restauré » de « rien à restaurer » de « ce bouton est mort ».

Idle Cash – Merge Tycoon répondait, mais de façon incohérente. Appuyer sur la même option faisait clignoter l’écran. Rien d’autre n’est enregistré, et ce que le testeur attendait était une confirmation, un indicateur de chargement ou un message d’erreur.

Clear Age était le plus léger des trois et manquait quand même la même exigence. N’ayant rien à récupérer, appuyer sur Restaurer les Achats ne donnait aucune confirmation, réussite ou message informatif.

Cela compte plus qu’il n’y paraît. Restaurer l’Achat est l’endroit où atterrit un client payant quand quelque chose a déjà mal tourné : une réinstallation, un nouvel appareil, un droit perdu. Rester silencieux ici coûte cher, car celui qui appuie dessus vous a déjà payé et essaie de le prouver. Les propres App Store Review Guidelines d’Apple attendent des applications qu’elles permettent aux utilisateurs de récupérer les achats non consommables et les abonnements. Cela fait de ceci une surface de conformité boutique, pas seulement d’ergonomie.

Ce qu’il faut vérifier de votre côté : Les tests d’achats intégrés doivent traiter Restaurer l’Achat comme quatre résultats plutôt qu’un seul. Couvrez les achats trouvés et rendus, rien trouvé, un échec réseau en pleine requête, et une seconde tentative consécutive. Chacun mérite son propre message visible, et le contrôle a besoin d’un état de chargement pendant qu’il fonctionne. Exécutez-le sur une installation fraîche connectée à un compte possédant des achats, un scénario qu’un build de développement ne voit jamais.

Comment cela se détecte : Un plan qui traite la restauration d’achat comme un flux de première classe, exécuté à la main sur un appareil vierge. Les chemins de restauration cassent silencieusement et peuvent ne jamais apparaître dans l’analytique. Les utilisateurs qui les rencontrent sont déjà frustrés, et certains partiront simplement. L’étendue compte ici, et les tests de conformité App Store s’inscrivent dans la même mission que notre travail sur les jeux.

Hors Ligne Est un État, pas un Message d’Erreur

Applications : Clear Age, Idle Cash – Merge Tycoon (les deux iOS)
Gravité : Majeure à Mineure
Type : Gestion hors ligne et boutique

Clear Age : Clean to Grow Stronger a une note de 4,4 sur 158 avis et plus de 20 000 téléchargements. Son gameplay a bien tenu entre nos mains, mais pas la boutique.

Avec l’appareil hors ligne, notre testeur a ouvert la section Era Offer. Le bouton d’achat affichait un prix de 0 et restait cliquable. L’appuyer produisait une tentative échouée. Zéro n’est pas un espace réservé neutre, car il se lit comme gratuit sur un contrôle que l’application invite toujours à presser.

Le second constat est la même absence de l’autre côté. Ouvrir n’importe quelle offre en jeu hors ligne laissait l’application charger indéfiniment, sans rien indiquant qu’une connexion était nécessaire.

Idle Cash – Merge Tycoon a inversé l’erreur. Au premier lancement, avec l’appareil sur un réseau stable, elle affichait quand même une erreur « Non connecté ». Un produit ne peut pas vous dire qu’il est hors ligne quand il l’est, et l’autre le dit quand il ne l’est pas.

Autrement dit, une connexion perdue n’est pas une erreur à intercepter et avaler mais un état que l’interface doit représenter. Quand la récupération du prix échoue, vous désactivez soit le contrôle, soit vous expliquez pourquoi. Un écran qui ne peut pas charger son contenu devrait le dire clairement plutôt que tourner indéfiniment.

Ce qu’il faut vérifier de votre côté : Exécutez chaque surface d’achat et de boutique avec le réseau désactivé, puis avec une coupure en pleine requête. Confirmez que l’application affiche un état réel à chaque fois, jamais une valeur d’espace réservé et jamais une roue de chargement infinie. Tout chiffre provenant d’un appel distant a besoin d’un repli clairement identifiable comme n’étant pas un prix. De bons tests d’achats intégrés couvrent aussi l’inverse, confirmant que l’application ne prétend pas être hors ligne alors qu’elle est connectée.

Comment cela se détecte : Des tests d’utilisabilité associés à une manipulation réseau délibérée sur du matériel réel. Cette classe de bug est presque invisible dans un bureau avec un wifi fiable, ce qui est une des raisons pour lesquelles elle atteint la production. Notre aperçu des tests de compatibilité des jeux couvre la construction d’une matrice d’appareils et de réseau qui exerce délibérément ces chemins.

L’Interface Offre ce que le Backend Refuse

Applications : Chefadora : Recipes & AI Chef (Android), Read AI (SaaS)
Gravité : Critique à Majeure
Type : Échec de soumission et UX des permissions

Chefadora est une plateforme de recettes avec un assistant IA, et a produit la plus grande exploration de cet ensemble avec 15 bugs. Deux de ses constats critiques sont le même bug à deux endroits, et les deux correspondent à ce schéma.

Sur une page de recette, notre testeur a fait défiler jusqu’à « Vous avez essayé cette recette ? Partagez votre expérience », choisi une note en étoiles, et appuyé sur Ajouter un avis. Avec le champ de texte laissé vide, la soumission a renvoyé « Request failed with status code 400 » et rien n’a été enregistré.

Cet échec s’est répété à la fin du flux Cuisiner Étape par Étape. Parcourez-le, atteignez l’écran « Enjoy your meal », choisissez une note, et le même 400 revient.

L’interface a accepté une note sans texte, et le backend l’a refusée. Personne n’a dit à l’utilisateur quelle règle était réelle, et un code de statut brut n’est pas un message de validation.

Read AI a montré le même échec dans ses permissions. Un utilisateur avec un accès Viewer, en lecture seule à un dossier, voyait quand même une option Modifier, l’ouvrait, et effectuait des changements. Seul Enregistrer l’arrêtait, échouant avec « Failed to update folder. Please try again. » Le même produit nous a aussi laissé choisir des rapports d’exemple en lecture seule lors de la création d’un dossier, puis a renvoyé « Failed to update folder reports. Please try again. »

Ce dernier mérite une pause. L’action a été refusée et le message n’a rien nommé, si bien que les utilisateurs ne peuvent pas distinguer un mur de permissions d’une fonctionnalité cassée. Dans les deux cas, l’interface les a invités à dépenser des efforts sur quelque chose qui n’allait jamais aboutir. Refuser correctement une action n’est pas la même chose que la refuser d’une manière sur laquelle quelqu’un peut agir.

Ce qu’il faut vérifier de votre côté : Les règles de validation doivent correspondre des deux côtés de l’appel, afin que le client bloque ce que le serveur refuserait. Toute action que le niveau d’accès actuel interdit doit être cachée ou désactivée, pas présentée puis refusée. Chaque erreur qu’un utilisateur voit doit nommer le problème réel : quel champ, quelle permission, quoi changer. Un code de statut nu ou une invite de nouvelle tentative générique laisse le travail à moitié fait.

Comment cela se détecte : Des tests exploratoires de chemin négatif, effectués par quelqu’un qui soumet délibérément des formulaires incomplets et utilise le produit à chaque niveau de permission. Travailler en tant qu’utilisateur du plus bas privilège fait partie des habitudes les plus rentables ici, et l’une des plus faciles à sauter.

Rapports de Statut Auxquels Vous ne Pouvez pas Vous Fier

Applications : Bluedot (SaaS), Slite (SaaS), Fathom AI (SaaS)
Gravité : Majeure à Mineure
Type : Retour d’information et statut manquants

Le schéma dépasse l’argent. Sur trois outils web, le produit a laissé les gens sans réponse claire sur ce qu’il avait fait.

Bluedot, un assistant de réunion IA avec une extension Chrome, a donné l’exemple le plus frappant. Son minuteur d’enregistrement se réinitialisait après une pause et une reprise, finissant par afficher 00 :00 alors que la capture continuait. Comme il décompte depuis 60 :00, l’élément rapportant le temps restant était activement faux.

Le même produit a aussi géré les téléversements sans un mot. Ajouter un logo d’espace de travail via Paramètres et Général ne produisait aucun signe que le transfert avait commencé. Aucun indicateur de progression n’apparaissait, et un fichier invalide ne déclenchait aucune erreur de validation.

Nous avons déclenché une synchronisation manuelle depuis la page Sources de l’Agent de Slite, et « Dernière synchronisation » est resté inchangé jusqu’à ce que quelqu’un rafraîchisse manuellement. Que la tâche elle-même se soit terminée ou non reste invisible pour l’utilisateur. L’ancien horodatage persistait simplement, si bien que quiconque vérifiait ses sources obtenait une réponse obsolète.

Fathom AI est arrivé au même point par une autre voie. Son champ Nom de clé API n’a pas de validation de longueur maximale, si bien qu’une entrée trop longue renvoie « Failed to generate API client ». L’utilisateur apprend que l’opération a échoué et n’obtient aucun chemin pour la faire fonctionner.

Aucun de ces cas ne prend l’argent de personne, et le dommage est réel quand même. En conséquence, les utilisateurs ne peuvent pas savoir si le produit a fait ce qu’ils ont demandé. Cette incertitude est ce qui génère des tickets de support, des actions dupliquées, et des flux de travail abandonnés.

Ce qu’il faut vérifier de votre côté : Tout ce qui traverse le réseau a besoin de trois états visibles : en cours, réussi et échoué. Donnez à chaque transfert de fichier un signal de progression et un message de rejet. Toute valeur représentant la fraîcheur doit se mettre à jour à partir de l’action elle-même plutôt que d’un chargement de page. Cela couvre les heures de dernière synchronisation, les horloges en cours, et les badges de statut.

Comment cela se détecte : Des tests d’applications web effectués par une personne plutôt qu’une suite, car quelqu’un doit remarquer une absence. Remarquer ce qui n’est pas là est plus difficile que d’attraper un plantage, et cela n’apparaît jamais dans une trace de pile. Dans le Résumé des Bugs #2, nous avons signalé un gel de dix secondes sans retour pour la même raison, car le silence se lit comme une panne.

Checklist de Tests d’Achats Intégrés Basée sur ces Explorations

Prenez une capture d’écran de ceci et partagez-la avec votre équipe.

Chaque dépense de monnaie : confirmez que le solde a changé, que l’avantage s’est appliqué, et que l’interface affiche les deux. Un bouton qui répond ne prouve rien de tout cela.
Chaque publicité récompensée : vérifiez que l’objet promis arrive au moment où la lecture se termine. Confirmez ensuite que personne ne peut l’obtenir sans en regarder une.
Chaque Restaurer l’Achat : testez les achats trouvés, rien à restaurer, un échec réseau, et une seconde tentative. Chacun a besoin de son propre message.
Chaque prix distant : définissez un repli que personne ne pourrait confondre avec un vrai chiffre. Désactivez le contrôle d’achat tant que le montant est inconnu.
Chaque surface boutique hors ligne : confirmez qu’elle affiche une erreur déclarée plutôt qu’un chargement sans fin. Vérifiez ensuite qu’elle ne signale pas une connexion perdue alors qu’elle est en ligne.
Chaque compteur affiché à deux endroits : comparez la valeur partout où elle apparaît au sein d’une même session.

Bug du Mois

Notre choix est la logique de publicité récompensée d’Idle Cash – Merge Tycoon, car elle a échoué dans les deux sens au sein de la même exploration. Quelqu’un qui a regardé une publicité complète n’a pas obtenu le skin au moment où il l’a mérité. Des gemmes sont arrivées à la place, avec un message indiquant qu’une autre publicité n’était pas encore disponible. Quiconque a sauté complètement la publicité pouvait continuer à faire tourner la roue quelle que soit l’icône sur le bouton. Un système a lésé le joueur et a distribué des tours que l’impression publicitaire n’a jamais payés. Un flux récompensé ne fonctionne pas simplement parce que la publicité se joue et que le bouton répond. L’événement publicitaire, le droit et l’interface doivent tous s’accorder sur ce qui vient de se passer.

Mention honorable pour le Accélérer de Hay Day. Un joueur avec assez de monnaie premium appuie dessus, et la production continue sans changement. C’est la version la plus courte de ce schéma. Le produit a proposé un échange, le joueur a accepté, et rien n’a suivi.

Si vous préférez détecter cela avant vos utilisateurs, dites-nous ce que vous livrez et nous cadrerons les tests d’achats intégrés autour de cela.

FAQ

Comment Teste-t-on les Achats Intégrés sur iOS ?

Exécutez les tests d’achats intégrés sur de vrais comptes sandbox StoreKit sur des appareils physiques, jamais des simulateurs, et traitez chaque achat comme une chaîne. Confirmez que le paiement se termine, que le droit arrive, qu’il survit à un redémarrage et à une réinstallation, et que l’interface reflète chaque étape. Couvrez ensuite la restauration, les achats interrompus et les tentatives hors ligne. De nombreuses lacunes se situent après la réussite du paiement, pas pendant.

Que Doivent Couvrir les Tests d’Achats Intégrés Au-delà d’un Paiement Réussi ?

La couverture doit suivre le droit, pas le reçu. Une fois qu’un paiement passe, confirmez que ce qui a été acheté apparaît réellement et persiste à travers les sessions et les appareils. Prouvez ensuite que cela ne peut pas être obtenu sans payer, car une récompense donnée gratuitement vous coûte aussi. Les deux sens ont échoué quelque part dans cet ensemble.

Les Tests Automatisés Peuvent-ils Détecter les Bugs d’Achats Intégrés ?

En partie. L’automatisation confirme qu’un appel d’achat se déclenche et renvoie une réponse, et vérifie par régression l’état du droit dans le temps. Elle est faible précisément sur les échecs que nous avons trouvés ici, où l’appui s’enregistre et l’avantage n’arrive jamais. Les sandbox de boutique, la médiation publicitaire, et les conditions réseau réelles résistent à une automatisation fiable, donc la couverture la plus solide reste manuelle et exploratoire.

À Quelle Fréquence Faut-il Retester les Flux de Publicités Récompensées ?

Chaque build touchant le SDK publicitaire, la logique de récompense, ou la configuration de médiation, plus une passe de régression planifiée de toute façon. Les flux récompensés s’appuient sur des composants tiers qui évoluent en dehors de votre cycle de version. Quelque chose qui passait le mois dernier peut échouer ce mois-ci sans aucune modification de votre part. Cela rend une suite permanente bien plus sûre que des vérifications ponctuelles au moment de la sortie.