Le sujet m’est venu il y a quelques années à la la lecture de ce livre fascinant “ Thinking, Fast and slow” de Daniel Kahneman (prix Nobel tout de même), mais aussi en consultant des billets de blog ou des articles (références à la fin).

Une liste de tous les biais cognitifs est disponible sur Wikipedia, mais elle est tellement longue et désorganisée que s’en servir pour un article comme celui-ci m’a vite rebuté, et je dois admettre que j’ai “procrastiné” plus que de raison. Puis, un article de Buster Benson m’a relancé. Grace à son congé de paternité, il a décidé d’organiser cette liste en quatre sections: “Trop d’informations”, “Pas assez de sens”, “Nécessité d’agir rapidement” et “De quoi devrions-nous nous souvenir?”.

Et maintenant tout est presque limpide…enfin presque si vous allez lire ceci.

Une visualisation impressionnante a été faite par John Manoogian III vous pouvez la commander ici.

Je vais utiliser cette classification et sélectionner quelques-uns de ces biais en les illustrant avec des situations que reconnaîtront les testeurs logiciels. Quelques exemples parlent de développeurs ou managers, parce qu’il est non seulement important de comprendre nos propres biais, mais aussi de comprendre les biais des autres membres de l’équipe.

La plupart des définitions citées en italique proviennent de Wikipedia et sont traduites en Français.

---

Trop d’informations

Biais de Disponibilité

La tendance à surestimer la probabilité d’événements avec plus de «disponibilité» en mémoire, qui peut être influencée par le côté récent, inhabituel ou chargé d’émotions des souvenirs.

Les testeurs de logiciels doivent évaluer les risques: le risque de panne de logiciel, le risque de perte de données, le risque qu’une interface utilisateur soit incompréhensible, le risque d’utilisateurs frustrés, le risque de faible performance, le risque d’interface cassée avec une certaine localisation, le risque d’injection de données ou de piratage, etc…

Si vous passez 2 mois sur des tests et l’amélioration de la performance du produit et sortez cette version, alors vous aurez le sujet de la performance encore en mémoire lorsque vous serez sur la prochaine version. Si c’est géré correctement, ce n’est pas un problème, mais vous devriez faire attention à ne pas négliger tous les autres aspects du produit, vos tests ne doivent pas être influencés par ces expériences antérieures, ou si oui seulement un peu et de façon réfléchie et intelligente.

De même, lorsque se produit une très mauvaise expérience, vous devriez avoir la possibilité d’aller de l’avant et ne pas être pollué par ces vieux souvenirs. Par exemple, si vous ne repérez pas une anomalie majeure dans la version 2.0 déjà en production, si par exemple l’interface a été réduite à une page blanche dans tous les navigateurs localisés en ZH (chinois), avez-vous vraiment besoin cette fois de tester toutes les localisations dans la version suivante du produit? Peut-être que le correctif est solide, et que quelques tests unitaires ou d’intégration ont été rajoutés; à ce moment-là vous avez probablement besoin de ne vérifier que 2 localisations pour avoir un niveau suffisant de confiance.

Effet d’Ancrage

Tendance humaine commune à trop compter sur le premier morceau d’information offerte (le «point d’ancrage») lors de la prise de décision.

L’effet d’Ancrage est partout. Dans une négociation sur le prix d’une maison, le vendeur fait le premier pas en fixant un prix et c’est un grand avantage dans la négociation. Sauf si ce prix est totalement aberrant, vous allez proposer un prix inférieur mais en vous basant inconsciemment sur l’ancrage défini par le vendeur.

Un autre exemple: votre manager rusé veut que vous estimiez le temps nécessaire pour les tests de la version n. Il vient et vous dit ceci:. “Mon cher testeur bien-aimé, cette version n ne contient que la correction de 4 problèmes majeurs, qui a été estimée à 4 jours par nos développeurs, que penses-tu de 2 jours pour les tests? Correct non?”….

OK, restez calme et détendez-vous. Même si vous pensez que 2 jours sont largement insuffisants, en raison de l’effet d’ancrage, vous aurez du mal à répondre avec une grande estimation… Alors peut-être que vous allez proposer un timide “4 jours”, peut-être même “6 jours” si vous êtes une sorte de rebelle. Mais quand vous allez y repenser plus tard, alors vous découvrirez que ces 4 évolutions ont un impact sur la base de données, donc vous aurez à tester toutes les mises à jour de base de données ainsi que les nouvelles installations. Et vous verrez que l’interface utilisateur est très affectée aussi, donc vos vérifications automatiques end-2-end seront probablement en échec et devront être modifiées. Et parce que vous ne pouvez pas vérifier automatiquement sur mobile, alors vous aurez à tester avec plusieurs Android et quelques iOS, au format smartphone mais aussi tablettes.

De plus, un testeur de votre équipe est en congés, l’autre est encore junior. Nous savons tous que le test ne peut pas facilement être estimé (lire mes fausses idées sur le test logiciel), mais après avoir réfléchi à cette version n alors vous concluez qu’au moins 10 jours seront nécessaires pour votre équipe. C’est juste un exemple, mais si vous êtes trompé par cet effet d’ancrage, alors vous aurez le malaise d’avoir à demander plus tard quelques jours de tests supplémentaires et c’est toujours pénible à justifier.

David Louapre l’explique très bien dans cette vidéo de sa chaine Science Etonnante.

Le biais de confirmation

Nous sommes plus susceptibles de prêter attention aux résultats qui confirment notre opinion.

Disons que vous avez une grande feuille de résultats de test. Avant de la consulter, vous avez probablement une idée de son contenu, et ce qui pourrait être considéré comme OK en raison des autres biais (voir «effet de Halo» ou la «loi de Murphy», par exemple). A cause de ce biais de confirmation, vous serez plus concentré sur les résultats que vous attendiez et non pas sur les autres résultats qui sont peut-être plus intéressants. Vous traiterez ces résultats qui confirment votre opinion d’abord, en négligeant les derniers.

Tous les résultats doivent avoir le même poids avant d’exécuter une analyse profonde. Votre avis en tant que testeur ne doit être conçu que lorsque vous avez une compréhension globale suffisamment pertinente… soyez cependant attentif au «biais de l’information” que nous verrons plus tard.

Réalisme Naïf

La tendance humaine à croire que nous voyons le monde autour de nous objectivement, et que les gens qui sont en désaccord avec nous doivent être mal informés, irrationnels, ou biaisés.

Tout le monde a son propre point de vue. La compréhension et les intérêts sont relatifs et différents selon que l’on soit développeur, responsable d’un produit ou testeur. Si la communication entre eux est mauvaise, chacun peut penser qu’il est le seul à posséder la vérité. Ainsi, afin d’éviter le «réalisme naïf», il faut communiquer, essayer de comprendre les développeurs, leurs problèmes et leurs difficultés, essayer de comprendre l’architecture du produit. Dans le même temps, essayer de comprendre l’entreprise, ce qu’attendent les utilisateurs, quels sont leurs besoins, ce qui est attendu dans 6 mois, 1 an, 3 ans … Vous allez prendre de bonnes décisions, et aider les responsables du produit avec vos informations, à condition de bien comprendre tout l’environnement et pas seulement les problèmes du logiciel.

---

Pas assez de sens

Illusion de validité

Une personne surestime sa capacité à interpréter et à prédire avec précision le résultat lors de l’analyse d’un ensemble de données, en particulier lorsque les données analysées montrent un modèle cohérent, lorsque les données “racontent” une histoire cohérente.

Vous êtes probablement victime de l’«Illusion de validité” lorsque vous testez une fonctionnalité avec un nombre limité d’environnements. Si vous ne trouvez aucun problème avec les 10 principaux environnements, le modèle est que la fonctionnalité fonctionne avec ces 10 environnements, l’histoire racontée par ces 10 résultats est qu’il n’y a pas de problème avec ce logiciel. Mais ces 10 environnements ne sont qu’une partie de toutes les possibilités, et si vous vous arrêtez là vous risquez de manquer quelque chose de très problématique. Le test peut être infini et vous ne serez guère en mesure de tester tout, mais il est de votre ressort de communiquer que vous ne pouviez pas tester tous les environnements et de donner un bon aperçu des risques.

Biais d’Autorité

Tendance à attribuer une plus grande précision à l’opinion d’une autorité (sans rapport avec son contenu) et être plus influencés par cette opinion.

Votre patron vient vous parler d’une partie du logiciel avec cet argument:

Le cas de test A est testé et est OK, il fonctionne. Pourriez-vous s’il vous plaît vérifier que le cas de test B (dérivé du cas de test A) est OK aussi?

Eh bien, c’est votre patron, il vous dit que le cas de test A est OK, pourquoi voudriez-vous vérifier? En tant que testeur, vous ne devriez jamais être sûr de rien. Qui a testé ce cas de test? Est-ce un bon testeur ou quelqu’un d’autre? Qu’a-t-il dit exactement à votre patron? Peut-être qu’il a juste dit: «Oui, je n’ai pas trouvé de problème pour le moment” mais n’a pas eu le temps de tester plus sérieusement.

Dans ce cas, peut-être devriez-vous avoir une conversation avec ce testeur du cas de test A , et en fonction de ce qu’il vous apprend au sujet de son test, vous devriez peut-être jeter un œil à son cas de test A . Votre patron ne vous blâmera pas si vous trouvez un problème dans ce cas, mais il pourrait vous reprocher de ne pas avoir vérifié en cas d’oubli. Faites bien attention à ce biais d’Autorité.

Biais de l’automatisation

Tendance à favoriser les suggestions des systèmes de prise de décision automatisées et d’ignorer des informations contradictoires faites sans automatisation, même si elle est correcte.

Les tests (checks) automatiques sont au vert, mais les testeurs ont trouvé des problèmes. Un testeur va tester le même scénario qu’un des tests automatisés, et, malheureusement, il ne fonctionne pas pour lui. Si les autres membres de l’équipe en charge de l’automatisation n’ont pas beaucoup de temps à investir pour vérifier, et si elles sont victimes du «biais de l’automatisation», alors ils vont probablement penser que le problème est dans la chaise, pas dans l’automatisation (PICNIC ). La probabilité qu’ils aient raison n’est pas nul, mais il a certainement besoin d’être évalué.

Effet de Halo

Impression générale d’un observateur d’une personne, une entreprise, une marque ou un produit influe sur les sentiments de l’observateur, mais aussi sur ses réflexions à propos du caractère de cette entité ou de ses propriétés.

Certaines personnes sont capables de vous vendre quoi que ce soit, c’est un talent. Certaines personnes avec un grand ego sont capables de vous influencer dans vos sentiments. Faites attention, vous ne devriez pas faire confiance plus à quelqu’un qu’à quelqu’un d’autre. Même les meilleurs développeurs du monde qui vous assurent qu’un changement n’a pas d’impact peuvent se tromper et avoir cassé le produit.

En outre, en tant que testeur avec une grande expérience et très respecté dans votre équipe, ne jouez pas avec cet “effet de Halo” pour essayer de convaincre tout autre membre de l’équipe si vous ne pouvez pas être sûr de ce que vous dites. Parce que si vous avez tort, vous pouvez dire adieu à votre réputation.

Vous pourrez trouver une vidéo sur le sujet faite par David Louapre pour sa série « Crétin de cerveau » ici.

Effet croisé de tribu

Tendance à reconnaître plus facilement les membres de sa propre tribu

Les discussions entre développeurs et testeurs ont souvent tendance à se résumer à un groupe d’appartenance contre l’autre. Vous serez plus disposés à croire ce que dit un autre testeur que ce qu’un développeur ou un utilisateur va vous dire. Et c’est également vrai pour un développeur parlant avec d’autres développeurs, auquel il accordera plus de confiance qu’à un testeur. En tant que testeur logiciel, vous devez être conscient de cela et ne pas donner plus de crédit à la personne plus semblable, vous devez être impartial.

La loi de Murphy

Tout ce qui peut aller mal, ira mal

Être un testeur de logiciel ne se résume pas à être le pessimiste du groupe. Dans la vraie vie, tout ce qui peut aller mal peut aussi aller très bien, les galères arrivent parfois et parfois non. Donc, même si vous trouvez un problème au moment de remplir ce champ avec une chaîne cyrillique et une longueur exacte de 255 caractères, cela ne signifie pas qu’un utilisateur le fera un jour. Et si un le fait, on peut imaginer que les 150.000 autres utilisateurs ne le feront pas. Alors il est parfois préférable de laisser un bug dans le produit et de se détendre, mais seulement avec l’aval du responsable produit qui saura gérer si le problème est effectivement remonté par la suite.

“Irreproducible bugs become highly reproducible right after delivery to the customer.” – Michael Stahl’s derivative of Murphy’s Law

Biais de gain de temps

La loi de Brooks prétend à propos de la gestion de projet logiciel que «l’ajout de main-d’oeuvre à la fin fait qu’il sera fini encore plus tard”.

Pour les testeurs, disons que vous estimé que vous avez 15 jours restants pour finir une tâche de test (tester une Release Candidate, tester une fonctionnalité avec tous les environnements,…). Votre patron pense que c’est trop long car il veut sortir la version en 5 jours, il suggère donc d’ajouter 2 autres testeurs sur la tâche. Mais ces testeurs ne connaissent pas ce composant, de sorte que vous aurez à les former. Ils trouveront de petits problèmes déjà connus, de sorte que vous devrez passer du temps à trouver pour eux la référence du problème dans l’outil de suivi d’anomalies. Et parce qu’ils découvrent ce module, ils seront naturellement plus lents que 2 clones de vous-même, de plus ils ne sont pas au courant des outils que vous utilisez, et comme tout le monde ils sont pleins de biais cognitifs dont ils n’ont pas connaissance (contrairement à vous qui lisez cet article). Si elles sont soumis au «biais de l’information», alors ils vont tout simplement polluer votre prochaine semaine.

Conclusion: votre patron a sans doute besoin que vous lui envoyez un ou deux exemplaires de “The mythical Man-Month” by Frederick P. Brooks Jr.

I bought my boss two copies of The Mythical Man Month so he could read it twice as fast — Randall Koutnik

---

Besoin d’agir rapidement

La compensation du risque

Théorie qui suggère que les gens ajustent généralement leur comportement en réponse à la perception du niveau de risque, en faisant de plus en plus attention là où ils sentent un risque plus élevé et en étant moins prudent s’ils se sentent plus protégés.

En tant que testeur de logiciels, vous pouvez vous sentir plus protégé si vous savez que beaucoup de tests unitaires, de tests d’intégration et de tests end-2-end sont joués à chaque build (et qu’ils sont verts et pas désactivés), mais cela ne signifie pas qu’il n’y a pas de risque à évaluer dans la nouvelle version, notamment si les nouveaux développements ont peu de tests automatisés (unitaires, intégration, e2e). Vous pouvez avoir plus de contrôle et en même temps devoir être toujours aussi vigilants avec ces nouveautés. Il est important de ne pas compenser le risque.

Appel à la nouveauté

Illusion dans laquelle on prétend prématurément qu’une idée ou une proposition est correcte ou supérieure, exclusivement parce qu’elle est nouvelle et moderne.

Avouons-le, nous aimons tous la nouveauté et ne voulons pas passer notre vie avec de vieilles méthodes et des outils anciens. Certains aiment à ne rien changer et vivre dans le passé (voir le « biais de Status Quo ») mais je suis sûr qu’ils ne lisent pas ce blog ou un autre similaire; ils ne sont pas intéressés à réfléchir à de nouvelles façons de s’améliorer dans leur métier, et pour eux, la nouveauté est à éviter, car ils ont toujours travaillé comme ça.

Par contre, être sans raison attiré par tout ce qui est nouveau est dangereux aussi. Vous verrez que certains développeurs sont en mesure de vous trouver une nouvelle bibliothèque presque tous les jours. En tant que testeur, vous trouverez également un grand nombre de nouveaux outils fréquemment, beaucoup de nouvelles techniques et il est toujours intéressant de les essayer.

Mais avant, vous devriez vous poser cette question: « Quel est le problème que je tente de résoudre? ». Si vous n’avez pas de véritable problème à résoudre, dans ce cas, vous devez peut-être envisager de continuer de la même façon. Toutefois, si le problème que vous avez peut être résolu avec quelque-chose de nouveau, vous devriez bien évidemment essayer, mais faites attention à ne pas passer trop de temps simplement parce que vous avez vu passer quelque-chose d’attirant et et séduisant.

Les coûts irrécupérables

Phénomène où les gens justifient l’augmentation des investissements dans une décision, fondée sur les investissement précédents, malgré de nouvelles preuves suggérant que la décision était probablement mauvaise.

Si l’exécution de ce projet coûte 10k€ chaque mois, un an après, la facture sera de 120k€. Le projet ne sera pas arrêté parce que cela serait interprété comme une perte de 120k€. Mais en y réfléchissant bien, il est déjà trop tard, et ces 120k€ sont déjà dépensée, ils sont déjà perdus. Si vous continuez, tout en sachant que vous allez droit dans le mur, ce sont encore 10k€ de plus qui seront perdus chaque mois … et ce, jusqu’à la fin.

Je l’ai vu à propos de certains composants externes utilisés alors qu’ils n’étaient pas de bonne qualité. Nous avons passé beaucoup de temps à l’intégrer dans notre produit, puis à essayer de le réparer. C’est toujours une décision difficile de se débarrasser de son propre travail (également en raison de l’”Effet Ikea”) et parce que l’illusion des “coûts irrécupérables” tente de nous convaincre que nous ne devrions pas jeter ce qui nous a demandé beaucoup de travail.

En tant que testeur, vos informations sur la qualité d’un composant qui doit être abandonné sont très précieux, vous pouvez aider les décideurs à ne pas être dupés par ce biais et les aider à comprendre ce que cela coûte vraiment.

Ce phénomène est également présenté par David Louapre dans cette vidéo.

Effet Ikea

Biais cognitif dans lequel les consommateurs accordent une valeur disproportionnée aux produits qu’ils ont partiellement créés.

Je suppose que vous connaissez Ikea, la société qui vous permet de vivre cette expérience unique de passer 2 heures dans un magasin de meubles, puis d’attendre une demi-heure pour récupérer les choses que vous voulez acheter, puis de rentrer à la maison et passer une autre heure pour assembler les meubles et parfois avoir à revenir au magasin pour une vis manquante. Et que se passe-t-il quand vous avez enfin terminé? Vous êtes si fier de vous que vous prenez probablement une photo pour la partager sur Facebook.

C’est la même chose que vous avez à combattre quand un développeur ne veut pas se débarrasser d’un bout de logiciel qui est manifestement inutile ou au moins inutilisable. Les gens qui ont partiellement ou complètement créé cette partie ne peuvent que difficilement imaginer la valeur réelle de celui-ci, ils la surestiment et en tant que testeur, il est toujours difficile d’être celui qui doit rétablir la vérité. Vous devez savoir cela, vous devez adapter votre communication afin de ne pas blesser les membres de l’équipe impliqués et qui ont pris des décisions que vous êtes en train de critiquer.

En tant que testeur, vous pouvez aussi être dupé par cet effet. Par exemple, avec les contrôles automatisés que vous avez écrit. Si l’un d’eux tombe en panne, vous blâmez le logiciel à tester en premier. Mais en réalité, la plupart du temps, c’est juste que quelque chose a changé dans le code du produit et qu’il a besoin d’une modification, ou peut-être que le test est trop fragile et échoue aléatoirement, et donc doit être réécrit pour être plus stable et durable.

À ce stade, il est facile de comprendre que cet “effet Ikea” contribue au biais des “coûts irrécupérables” avec cet exemple d’un manager ou d’un décideur qui continue à consacrer des ressources à un projet devenu inutile mais pour lequel il a passé beaucoup de temps et d’énergie.

Biais du Statu Quo

La tendance à aimer les choses qui restent relativement les mêmes.

Contrairement au biais “appel à la nouveauté”, le “biais de Statu Quo” tend à guider les gens à préférer ce qui est déjà existant et de bloquer toute nouvelle idée. Tout le monde n’est pas soumis à celui-ci, et il n’est jamais facile de trouver l’équilibre entre ne rien faire et le choix de la nouveauté. Rappelez-vous juste de vous demander si vous avez un problème à résoudre ou non.
Si votre architecture d’automatisation échoue 50% du temps, alors vous devriez regarder ce qui pourrait être fait à ce sujet et ne pas le laisser échouer. Mais si elle échoue 1% du temps sans raison facile à fixer, et si vous n’avez pas le temps et les ressources pour travailler sur ce sujet, alors je pense qu’il est préférable dans ce cas de relancer une seconde fois (retry).

Biais d’information

Un exemple de biais d’information est de croire que plus nous avons d’informations acquises pour prendre une décision, alors mieux c’est, même si ce supplément l’information est sans importance pour la décision.

Nous devons travailler avec beaucoup d’informations, et en voulons toujours plus pour nous aider à prendre les bonnes décisions. Ce “biais de l’information” concerne ce désir d’avoir toujours plus d’informations, même si elles sont totalement inutiles ou hors de propos. Vous voulez savoir qui a découvert le problème que vous retestez, vous voulez savoir qui a résolu ce problème, qui a relu le code, quels tests ont déjà été faits, quels sont les tests unitaires qui ont été écrits, etc. En quatre mots, vous voulez tout savoir. La plupart de ces informations sont utiles, mais certaines sont sans aucun doute inutiles et peut-être même dangereuses si vous vous souvenez de “l’effet de Halo” ou de l’”Illusion de validité”.

Essayez de ne recueillir que des informations pertinentes et essayez d’éviter le reste. Restez concentré sur les choses importantes.

---

De quoi devrions-nous nous souvenir?

Biais  de négativité

Quelque chose de très positif aura généralement moins d’impact sur le comportement et la cognition d’une personne que quelque chose d’aussi émotionnel, mais négatif.

Veillez à ne pas être trop négatif à propos du travail de quelqu’un d’autre, car il aura un plus grand impact que l’équivalent inverse en mots positifs. En raison de l’”effet Ikea”, tout le monde est très sensible au sujet de son propre travail et veut qu’il soit apprécié, pas critiqué. Nous, les testeurs de logiciels, avons cette responsabilité d’être de bons communicants en toutes circonstances; en cas de bonnes nouvelles, mais aussi pour les mauvaises. Aussi, faire preuve d’empathie sera toujours apprécié.

Biais de l’affaiblissement de l’affect

Plus communément appelé FAB (Fading Affect Bias), c’est un phénomène psychologique dans lequel des informations concernant les émotions négatives ont tendance à être oubliées plus rapidement que celles associées à des émotions agréables.

Celui-ci indique que si vous donnez trop d’émotions négatives dans les informations transmises, alors les informations auront tendance à être oubliées plus rapidement, ce qui n’est sans doute pas votre but. Vous souvenez-vous de ce problème critique que vous avez partagé avec le Product Owner et qui n’est toujours pas résolu, et même pas en haut du backlog ? Vous souvenez-vous comment vous l’avez communiqué ? Donnez-vous les informations en étant neutre, impassible et factuel ? Si non, si vous le communiquez avec un discours négatif, alors vous ne devriez plus vous étonner s’il n’est pas en priorité haute maintenant que vous avez conscience de ce biais de l’affaiblissement de l’affect.

Biais de Récence

A cause de ce biais, nous avons tendance à donner plus de crédibilité à la plupart des observations récentes.

Si par exemple vous avez découvert un problème il y a 6 mois, et le testez à nouveau en ayant un comportement différent, en quelle observation allez-vous avoir le plus confiance ? La plus récente sans doute car le produit a évolué et ce dernier test est probablement le plus juste. Et si vous aviez mal interprété la description qui avait été écrite il y a 6 mois ? Que faire si vous ne testez pas exactement le même scénario ce qui expliquerait que vous observez un comportement différent ?

Vous devez toujours faire attention face à des informations contradictoires et vérifier s’il y a une explication à cette évolution de comportement. Demandez aux développeurs, regardez dans le git log, recherchez dans votre outil de suivi d’incident, etc. Mais s’il vous plaît évitez de sauter à la conclusion hâtive que tout va bien maintenant simplement parce que vous ne réussissez pas à reproduire. Parfois, la réalité est loin d’être aussi simple que cela.

Biais de Primauté

Donner plus de crédibilité aux premières observations faites.

Après le “biais de Récence”, au contraire, ce biais de primauté donne plus de crédibilité aux premières observations. Pour le test logiciel, nous sommes habitués à tester les non-régression et donc on imagine assez facilement l’évolution d’un logiciel, mon sentiment est que ce biais est sans doute moins enclin à nous perturber et que nous ferons difficilement plus confiance à une observation ancienne, notamment la première.

Effet Google (amnésie numérique)

Tendance à oublier des informations qui peuvent être trouvées facilement en ligne en utilisant les moteurs de recherche Internet tels que Google. Selon la première étude sur l’effet Google les gens sont moins susceptibles de se rappeler certains détails qu’ils croient être accessible en ligne.

Le dernier mais pas le moindre, l’effet Google (qu’on pourrait aussi appeler « Effet Bing » ou « Effet Ecosia », etc…mais peu importe).

Dans notre esprit, nous ne tendons pas à essayer de nous rappeler le contenu de nos recherches, mais seulement la façon dont nous les avons trouvé. Est-ce vraiment un problème pour un testeur logiciel aujourd’hui ? Est-ce un problème quand vous savez que les résultats rapidement trouvés il y a 1 mois renvoient maintenant de bien meilleurs résultats. Si vous avez peur de perdre des choses, certains outils existent pour seconder votre cerveau: voir Evernote , Google keep ou Wallabag.

---

Conclusion

Je n’ai pas fait une liste exhaustive des biais cognitifs dans cet article, et le exemples que je donne ne sont que le fruit de mon imagination. J’apprécierais de lire vos retours, notamment si vous avez d’autres expériences à partager. Merci de votre lecture.

---

Les références

Buster Benson: «Biais cognitif”
Michael Bolton: «La pensée critique pour les testeurs” (PDF à télécharger)
Maaike Brinkhof: «Cartographie des biais des testeurs”
Wikipedia: “Liste des biais cognitifs”
Daniel Kahneman: «Penser, Vite et Lentement”
David Louapre: Science étonnante

---

Ecrit il y a quelques années pour le blog Lyon Testing et un peu mis à jour pour cette nouvelle publication par Stéphane Colson