En septembre, nos testeurs ont consigné 38 bugs dans six produits en ligne, et aucun n’a provoqué de plantage. Chacun était une défaillance plus discrète, comme un enregistrement de réunion avec un blanc ou une longue description qui refuse de s’enregistrer. Les exemples de bugs logiciels de ce type échappent à une vérification rapide des fonctionnalités principales, car les ennuis ne commencent que lorsqu’il se passe quelque chose d’inhabituel, comme un appel entrant ou un utilisateur supprimé.
Chaque produit ci-dessous est passé par un bug crawl, au cours duquel l’un de nos ingénieurs utilise l’application comme le ferait un nouveau client et consigne tout ce qui ne fonctionne pas. Des tests manuels de ce genre trouvent ce que les vérifications automatisées manquent, car un script ne suit que le chemin que quelqu’un a écrit à l’avance.
Applications couvertes par ce résumé :
- Workdeck (SaaS)
- Truck Simulator: World (iOS)
- Bluedot AI Note Taker (Android)
- Laxis (web)
- Venue: Relaxing Design Game (iOS)
- AI Chatbot & Keyboard: Sage AI (iOS)
Les rapports précédents se trouvent dans l’archive Bug Crawl.
Un utilisateur Workdeck supprimé recevait une erreur au lieu de l'écran de connexion
- Application : Workdeck (SaaS)
- Gravité : Critique
- Type : Accès au compte et messages d’erreur
Il a fallu deux comptes pour trouver le bug le plus grave de Workdeck. Connecté en tant qu’administrateur, notre testeur a supprimé un coéquipier qui avait encore une session active. Chaque clic depuis le compte supprimé affichait ensuite « Error! Unexpected error », alors que Workdeck aurait dû déconnecter cette personne et afficher la page de connexion.
Plusieurs autres bugs se trouvaient dans les formulaires que Workdeck utilise pour les projets d’équipe et les paramètres. Cocher la case Timesheet produisait un avis technique brut qui commençait par « Invalid value ‘true’ supplied to ». Soumettre une politique de dépenses sans nom envoyait la requête deux fois et empilait deux messages « Error! Invalid request » identiques, dont aucun ne mentionnait le champ Policy Name vide.
Ce qu’il faut vérifier de votre côté : Supprimez un compte ou retirez des droits à un utilisateur pendant que cette personne travaille encore, puisque la session devrait prendre fin au moment même où l’accès prend fin. Ensuite, déclenchez chaque erreur que votre backend peut renvoyer et lisez ce qui arrive à l’écran. Un vidage de validation brut ou un message en double signifie que l’interface transmet les réponses du serveur directement à l’utilisateur, sans les traduire.
Comment cela se détecte : Des tests d’applications web qui se connectent avec chaque rôle pris en charge par votre produit, y compris quelqu’un dont l’accès a disparu il y a une minute.
Truck Simulator: World jouait de la musique malgré le mode silencieux
- Application : Truck Simulator: World (iOS)
- Gravité : Majeure
- Type : Paramètres de l’appareil et parcours de compte
Notre testeur a lancé une session de conduite dans Truck Simulator: World, puis a passé l’iPhone 12 en mode silencieux. La musique du jeu a continué. Quiconque coupe le son de son téléphone dans un train ou en réunion s’attend à ce que toutes les applications se taisent en même temps.
Le mode Photo du jeu ne s’en sortait pas mieux, puisqu’un appui sur Capture ou Share faisait simplement scintiller l’écran, sans enregistrer d’image ni ouvrir le menu de partage.
Dans les paramètres, un joueur qui ne s’était jamais connecté pouvait tout de même ouvrir l’option Account Deletion, alors qu’aucun profil n’existait à supprimer. Apple et Google examinent ce parcours de près, comme l’explique notre analyse des exigences de suppression de compte dans les applications.
Ce qu’il faut vérifier de votre côté : Traitez le téléphone lui-même comme une partie du produit. Le bouton du mode silencieux, la photothèque et le menu de partage du système se trouvent en dehors de votre code, mais les joueurs accusent le jeu dès que l’une de ces pièces se comporte mal. Ensuite, ouvrez l’application en tant qu’invité et vérifiez que la suppression de compte et les autres options réservées aux membres restent masquées jusqu’à la connexion.
Comment cela se détecte : Des tests de jeux sur de vrais iPhone, où les testeurs appuient sur les boutons physiques qu’un joueur actionne sans y penser.
Bluedot enregistrait du silence pendant un appel téléphonique
- Application : Bluedot AI Note Taker (Android)
- Gravité : Majeure
- Type : Interruptions et transcription
Notre testeur a lancé un enregistrement Bluedot sur un Samsung Galaxy A35, puis a répondu à un appel entrant et est resté en ligne environ 25 secondes. Le minuteur a continué de tourner tout du long, si bien que rien à l’écran ne laissait soupçonner un problème. La lecture a pourtant révélé un blanc à l’endroit où aurait dû se trouver la conversation. L’application n’avait donné aucun avertissement indiquant que le micro ne captait plus le son.
De tous les exemples de défaillances logicielles de ce mois-ci, ce blanc est celui qui fait le plus de dégâts. Les utilisateurs ne découvrent l’audio manquant qu’en revenant à ce passage de l’enregistrement. Nous avons vu la même défaillance dans le résumé du mois dernier, où January: AI Health Tracker continuait de compter pendant une alarme et perdait chaque mot prononcé par-dessus la sonnerie. Deux produits en deux mois laissent penser que les interruptions sont un angle mort des applications d’enregistrement.
Les transcriptions posaient aussi problème, puisque Bluedot attribuait chaque ligne au premier interlocuteur, y compris ce qu’avait dit une autre personne. Même l’e-mail qui accompagne un fichier partagé se trompait de durée, en présentant un enregistrement de 16 secondes comme durant 1 minute.
Ce qu’il faut vérifier de votre côté : Reliez chaque indicateur de progression à l’audio réellement capté, car un minuteur qui continue de compter alors que le micro a décroché dit aux utilisateurs que tout va bien. Prendre un appel en plein enregistrement est le moyen le plus rapide de tester ce lien. Testez ensuite avec deux voix et comparez tout ce que le produit indique, des étiquettes d’interlocuteur à la durée dans un e-mail partagé, avec ce qui s’est réellement passé.
Comment cela se détecte : Des tests d’applications mobiles sur de vrais téléphones Android et iPhone, où un appel entrant peut réellement interrompre l’enregistrement.
Laxis laissait saisir 1 024 caractères mais n'en enregistrait que 500
- Application : Laxis (web)
- Gravité : Majeure
- Type : Validation des saisies et commandes de réunion
Notre testeur a rempli le champ Description d’un nouveau modèle d’IA dans Laxis jusqu’à ce que le champ cesse d’accepter du texte à 1 024 caractères. Un clic sur Save a ensuite affiché une erreur indiquant que la limite était de 500. L’assistant de réunion avait fixé deux limites différentes pour le même champ, si bien que l’utilisateur ne l’apprenait qu’après avoir tapé deux fois plus que ce que l’application allait conserver.
Le nommage des dossiers posait un autre problème de validation : les noms trop courts comme les noms trop longs déclenchaient « Folder creation failed », sans aucune indication sur ce qu’il fallait changer. Repérer un message aussi peu utile relève du test négatif, qui soumet volontairement une application à de mauvaises saisies et vérifie sa réponse.
Les commandes d’enregistrement ont elles aussi échoué : appuyer sur Pause n’arrêtait pas la capture, et une réunion silencieuse de 10 à 20 secondes est restée bloquée sur « Processing » pendant des jours.
Ce qu’il faut vérifier de votre côté : Notez les limites qu’affiche votre interface et celles qu’applique votre serveur, puis cherchez tout écart entre les deux listes. Chaque écart signifie qu’un utilisateur fait d’abord le travail et tombe sur l’erreur ensuite. Soumettez les commandes d’enregistrement au même examen avec des cas que personne ne prévoit, comme une pause en pleine capture ou l’enregistrement d’une réunion sans parole.
Comment cela se détecte : Des tests fonctionnels qui mettent chaque formulaire à l’épreuve avec des valeurs vides, des textes trop longs et d’autres saisies qu’un vrai utilisateur pourrait tenter.
Venue accusait son serveur quand le téléphone était hors ligne
- Application : Venue: Relaxing Design Game (iOS)
- Gravité : Majeure
- Type : Connectivité et parcours de compte
Notre testeur a activé le mode avion, puis a tenté dans Venue une action qui nécessite Internet. Le jeu de décoration d’intérieur a affiché une erreur serveur sans rien dire de la connexion manquante. Un joueur ne peut rien faire contre une panne du côté de l’entreprise, mais réactiver le Wi-Fi ne prend que quelques secondes. Le message trompeur cache la seule démarche qui aiderait.
Venue partageait aussi le bug de compte invité de Truck Simulator: World, en allant un cran plus loin. Un joueur qui ne s’était jamais inscrit pouvait aller jusqu’au bout de la suppression, sans aucune explication sur les données locales qui seraient effacées. Sur les écrans de décoration, par ailleurs, certains aperçus de tissus ne se chargeaient pas et apparaissaient vides.
Ce qu’il faut vérifier de votre côté : Donnez à chaque défaillance que votre application peut rencontrer son propre message, d’une connexion perdue à une image manquante, car une erreur fourre-tout envoie les utilisateurs chercher la mauvaise solution. Appliquez le même soin aux étapes destructrices, afin qu’avant qu’un invité supprime quoi que ce soit, l’écran précise exactement ce qui va disparaître.
Comment cela se détecte : Des tests d’utilisabilité qui coupent la connexion en pleine tâche sur de vrais téléphones et vérifient si chaque message aide un joueur à s’en sortir.
Ce que ces exemples de bugs logiciels ajoutent à votre plan de test
Chaque ligne ci-dessous renvoie à un bug de ce mois-ci, et l’ensemble de la liste couvre les types de bugs logiciels que nous rencontrons le plus souvent.
- Chaque message d’erreur : Le texte doit nommer la cause réelle, comme une connexion perdue, un champ vide ou un compte supprimé, et dire aux gens quoi faire ensuite.
- Chaque limite : L’interface et le serveur doivent s’accorder sur le même chiffre.
- Chaque indicateur de progression : Un minuteur ou un libellé d’état doit refléter ce que l’application a réellement capté ou traité.
- Chaque événement du téléphone : Le passage en mode silencieux, un appel entrant et une perte de signal doivent chacun recevoir une réponse appropriée de l’application.
- Chaque état de compte : Testez chaque écran en tant qu’invité, en tant qu’utilisateur ordinaire et en tant que personne dont l’accès vient d’être retiré.
- Chaque conversation avec l’IA : Les résultats de recherche doivent ouvrir la bonne conversation, et les questions de suivi doivent conserver le sujet d’origine.
Bogue du mois
Notre choix se porte sur Sage AI, un assistant pour iPhone doté de chatbots pour des tâches comme la rédaction, la traduction et la préparation de voyages. Deux bugs trahissaient la promesse la plus élémentaire du produit : ce qui s’affiche à l’écran doit être la conversation que vous avez demandée.
D’abord, notre testeur a recherché un mot-clé dans l’onglet Chats, a touché le résultat correspondant et s’est retrouvé dans une autre conversation. Le second bug venait de l’assistant Travel Buddy, qui a répondu à une question sur un voyage au Mexique avant de perdre le fil. Quand notre testeur a enchaîné avec « what’s the weather there in December? » (quel temps fait-il là-bas en décembre ?), la réponse a porté sur la Thaïlande et les conditions de visa.
Une recherche qui ouvre la mauvaise conversation fait douter les gens de tout le reste de l’écran. Un assistant qui oublie le sujet un message plus tard oblige les utilisateurs à tout recommencer. Vérifier comment un produit d’IA garde le contexte tout au long d’une conversation est au cœur de notre travail de test d’IA.
La mention spéciale revient à l’enregistrement Bluedot devenu muet pendant un appel. Pour une application de prise de notes, un passage de réunion manquant est le bug que les utilisateurs pardonnent rarement.
Nous trouvons des bugs comme ceux-ci chaque mois en utilisant les produits comme le font les clients. Confiez-nous le test de votre application.
FAQ
Quels sont des exemples courants de bugs logiciels ?
Parmi les exemples courants de bugs logiciels figurent des boutons qui ne font rien, des formulaires qui rejettent des saisies valides, des messages d’erreur qui pointent vers la mauvaise cause et des données mal enregistrées ou pas enregistrées du tout. Beaucoup des bugs les plus coûteux ne font jamais rien planter. Ces bugs survivent à une campagne de tests de routine et n’apparaissent que lorsque de vrais utilisateurs tombent sur une interruption, un réseau faible ou un état de compte inhabituel.
Quels sont les principaux types de bugs logiciels ?
Les principaux types de bugs logiciels sont les bugs fonctionnels, d’utilisabilité, de compatibilité, de performance et de sécurité. Les bugs fonctionnels empêchent une fonctionnalité de faire son travail, tandis que les bugs d’utilisabilité rendent confus des écrans qui fonctionnent. Les bugs de compatibilité n’apparaissent que sur certains appareils, navigateurs ou paramètres système. Les bugs de performance se manifestent par des écrans lents ou des plantages sous charge, et les bugs de sécurité exposent des données ou des accès qui devraient rester protégés.
Quelle est la différence entre un bug et une défaillance logicielle ?
Un bug est un défaut dans le code ou la conception, et une défaillance est ce que vit l’utilisateur une fois que cette erreur est déclenchée. Parmi les exemples typiques de défaillances logicielles figurent une page de paiement qui ne se charge pas, un document qui disparaît après l’enregistrement et une facture au total erroné. Un même bug peut provoquer de nombreuses défaillances, ou aucune si personne n’effectue jamais les étapes exactes qui déclenchent le problème.
Vous voulez un bug crawl pour votre application ?
Nous y affecterons l'un de nos ingénieurs QA et vous enverrons un rapport détaillé et reproductible avec preuves vidéo.
