Battle d’IA : qui est la plus buggée ?

En 2023, ChatGPT est un nom qui revient sur toutes les lèvres ! Depuis peu, Bard vient un peu lui voler la vedette. Ces IA surpuissantes vont-elles remplacer les QA, les devs, le monde entier, personne ?

Cet article n’est pas là pour répondre à cette question, mais pour présenter quelques réponses erronées et amusantes des robots conversationnels les plus affolants de ce début d’année ! De quoi dédramatiser un peu.

Les IA font leur cinéma

Le cinéma du coin propose les offres promotionnelles suivantes :

  • Gratuit le jour de l’anniversaire de la personne (valable uniquement pour la personne et pas pour celles qui l’accompagnent)
  • -50 % pour les personnes de moins de 18 ans
  • -25 % pour les 18-25 ans et pour les plus de 60 ans

Ce cinéma ouvre sa billetterie en ligne où le tarif s’adapte en fonction de l’âge de la personne inscrite.

La question que l’on se pose, et que même un enfant trouverait très simple, est la suivant : Regina fête ses 54 ans aujourd’hui ; aura-t-elle droit à une réduction ?

Réponse courte : bien sûr, une réduction de 100 %, puisque c’est son anniversaire !

Une réponse plus longue préciserait que cette réduction (ou plutôt, exonération) ne s’applique que sur sa place.

ChatGPT : la règle de gestion de trop

ChatGPT n’est pas de cet avis.

Bard : « et » au lieu de « ou »

Fun fact, Bard aussi se trompe ! (Nous lui avons posé la question en anglais vu que le français n’était pas encore supporté lors de l’expérience)

Bard comprend que la gratuité le jour de l’anniversaire n’est valable que si la personne se trouve dans l’une des tranches d’âge sujettes à des promotions. Ce qui est évidemment erroné.

Dates : l’ambiguïté classique

« Jusqu’à » est une expression qui met la communauté du test en émoi.

Est-ce que cela veut dire qu’on inclut ce qui suit, ou qu’on l’exclut ?

ChatGPT ne veut pas que j’aille à la plage

ChatGPT ne partage pas cette anxiété et répond comme s’il n’y avait pas d’ambiguïté.

Bard m’incite à sécher le travail

Après avoir posé la même question à Bard (en anglais toujours), force est de constater que cette IA comprend l’inverse de ChatGPT et ne voit pas de problème à ce que j’aille à la plage. Une fois encore, l’ambiguïté du terme n’est pas relevée !

Le défi des trous de paille

« Combien de trous a une paille ? » est une question simple qui permet de se rendre compte de la diversité des points de vue. Il n’y a pas de bonne réponse, ou plutôt, toutes les réponses ci-dessous sont bonnes.

  • 2 trous : une entrée et une sortie !
  • 1 trou : car il n’y a qu’un « chemin » dans cette paille
  • 0 trou : sinon la paille aurait des fuites !

ChatGPT tombe dans le piège

ChatGPT ne se trompe pas vraiment dans sa réponse, mais elle ne détecte pas le piège que constitue l’ambiguïté de la question.

On ne la fait pas à Bard

En revanche, Bard a su détecter la feinte, puisant dans les innombrables ressources accessibles via Google et évoquant cette question épineuse.

Compte les QA

Une liste de 26 prénoms féminins est fournie, et les IA doivent les compter. Facile ou pas ?

ChatGPT ne sait pas compter.

Hélas, ChatGPT n’en compte que 25. Ce n’était même pas cela le piège envisagé 😀

Bard débloque

Le même exercice traduit en anglais est fourni à Bard. Pourquoi compte-t-il 18 prénoms au lieu de 25 ? Et surtout, quelle est la logique derrière « The names you provided are all female names, so we can assume that they are all testers. » ? Un sentiment d’étrangeté émane de cette réponse.

Deuxième chance : testeuse ou testeur

Une autre liste est fournie, et cette fois-ci le compte est bon. Toutefois, le raisonnement qui suit a de quoi semer la confusion !

Le même exercice ne peut pas être fourni à Bard, étant donné que le mot anglais « tester » peut se traduire aussi bien par « testeuse » ou « testeur ».

Conclusion

Les IA sont impressionnantes. Ce sont d’excellents outils qui permettent de nous accompagner dans nos tâches les plus diverses, mais ils contiennent, comme tout logiciel, des défauts. C’est aussi en prenant conscience de ces défauts que nous devenons capables de les utiliser au mieux !

(On leur repose les mêmes questions d’ici un an ? Il est bien possible que leurs réponses soient plus pertinentes quelques mois !)

_________________________

L’image de couverture a été générée avec Midjourney.

Votre gestion des bugs est-elle buggée ?

La gestion des anomalies, c’est tout un art ! Ci-dessous sont listées 16 situations courantes dans la vie d’un projet, qui touchent à cette activité. Des situations qui ne sont ni confortables, ni productives, et qui soulèvent aussi bien fausses questions que réponses fallacieuses. Combien d’entre elles avez-vous déjà vécues ? (Une idée d’atelier serait de présenter ces situations sous forme de bingo des bugs !)

1) Le bug controversé

Deux personnes de l’équipe se chamaillent car l’une a trouvé un bug et l’autre considère que ce n’est pas un bug. On ne sait donc plus quoi faire du ticket. Remarquez qu’il n’y a jamais ce genre de controverse pour les US, personne ne dit « Non, c’est pas une US ! », « Si, c’en est une ! » Cela révèle la nature complexe de ce qu’on appelle « bug ».

2) La spécification déguisée en bug

Quelqu’un a ouvert un rapport de bug, mais c’est en fait une demande de modification déguisée. La notion de bug est utilisée comme une sorte de coupe-file. De fois ça marche, et d’autres fois, on ne sait pas trop quoi faire du ticket, et cela peut même donner lieu à une controverse (cf point 1).

3) Le gros tas de bugs

La pile des bugs est très longue, chaque bug a été reconnu comme valide (quelle aubaine !), mais personne ne semble avoir prévu de les corriger. Peut-être sont-ils là pour décorer le backlog. En tous cas, à un moment donné, on ne sait plus quoi en faire.

4) Le bug qui est en fait une remarque

Quelqu’un ouvre un rapport de bug (peut-être vous) mais sans trop savoir « Si c’est un bug ou pas, en tous cas ça vous semble bizarre, mais si ce n’est pas un bug oubliez ce que j’ai dit, faites comme vous voulez ». On ouvre un rapport de bug pour faire une remarque. Et au bout d’un moment on ne sait plus trop quoi faire de ce ticket : cette remarque n’est-elle pas légitime ?

5) Le nettoyage de printemps (à l’acide chlorhydrique)

L’équipe veut faire en sorte de fermer le plus de rapports de bugs possible, voire de n’avoir aucun bug ouvert, et en plus des corrections, ça passe par d’infinies négociations avec les personnes qui ont créé les tickets. Le rapport de bug est vu comme une menace pour l’intégrité de l’équipe.

Chaque personne souhaite en savoir plus sur la qualité de l’applicatif, et chaque rapport de bug contient de l’information sur l’applicatif. Mais si on souhaite se débarrasser de ces rapports uniquement des métriques projet plus agréables… n’est-ce pas un peu contradictoire ?

6) Le fayotage à la noix

Une personne veut montrer à quel point elle est assidue au sujet de la qualité et va ouvrir une farandole de bugs doublonneux. Le rapport de bug est vu comme un trophée par celui qui le crée.

7) Le débat épistémologique

Un bug d’UX est ouvert et ça lance une interminable controverse. Est-ce que c’est un bug, est-ce que ce n’en est pas un, est-ce qu’on peut parler de bug quand il s’agit d’UX, etc. Bref on se lance dans une bataille d’opinions, et on ne sait plus quoi faire du ticket.

8) Le gaspillage de paires d’yeux neufs

Une personne nouvellement arrivée dans l’équipe ouvre un rapport de bug car ce qu’elle voit lui semble déroutant. Quelqu’un clôture le rapport car le comportement est conforme à l’attendu. Le ticket d’anomalie est analysé de manière dogmatique et potentiellement on étouffe dans l’œuf une possibilité d’amélioration.

9) Le ticket « bug et méchant »

Quelqu’un a ouvert un rapport de bug car un comportement constaté contredit ce qui est demandé dans une User Story, mais ce comportement ne ressemble pas à un bug quand on n’a pas connaissance de la User Story. Une approche dogmatique qui ne bénéficie pas au projet.

10) Le débogage comme passe-temps

L’équipe corrige les bugs quand elle a du temps pour le faire. Les bugs tiennent un rôle de bouche-trou quand les devs s’ennuient. Comme c’est dommage !

11) L’heure de la sieste

Lors des revues, le fait que des bugs aient été corrigés n’intéresse pas grand-monde. Ce qu’on veut voir absolument, ce sont les nouvelles fonctionnalités. Et les corrections de bugs ne sont pas considérées comme des nouvelles fonctionnalités, même si elles incorporent des choses qui n’étaient pas là auparavant. Les bugs sont des citoyens de seconde zone.

12) Le bug microscopique

Quelqu’un a ouvert un bug mais l’anomalie est tellement petite que ça ne vaut quasiment pas le coup de la corriger.

13) Le bug marginal

Quelqu’un a ouvert un rapport de bug, mais l’anomalie ne concerne qu’une portion minuscule de la population visée, par exemple les personnes utilisant un appareil mobile avec l’OS Android 5.1.1. Ce type de bug est l’un des écueils des tests de portabilité.

14) Le bug en voie de disparition

Quelqu’un a ouvert un rapport de bug, mais l’anomalie est vouée à disparaître à court terme car la règlementation va changer, ou encore qu’une refonte graphique va être réalisée.

15) Le bug qui pousse le bouchon

Quelqu’un a ouvert un rapport de bug mais l’anomalie est justifiée par des standards que l’équipe n’a pas choisi d’adopter. Par exemple, un bug d’accessibilité qui s’appuie sur le standard WCAG n’est pas nécessairement légitime aux yeux des autres personnes de l’équipe si personne n’a formulé d’exigences sur l’accessibilité en amont du projet.

16) Le bug du roi

Un bug est ouvert par une personne influente (typiquement, la ou le CEO), mais il se trouve que ça concerne une fonctionnalité qui se comporte comme ça par design. Et donc, on ne sait plus quoi faire du ticket.

___

Le constat est posé : en plus d’être tout un art, la gestion des anomalies est un sport qui n’est pas de tout repos ! Que mettez-vous en place dans vos organisations pour fluidifier cette activité ? Avez-vous rencontré d’autres situations où les rapports de bugs font débat, font trop de vagues ou pas assez ?

NB : Cet article reprend par écrit une partie de la conférence « La notion de bug est buggée », présentée par une de nos expertes il y a quelques années à l’occasion de la conférence Frug’Agile France. Cette conférence est à découvrir ou redécouvrir ici !

Image de couverture générée avec Midjourney