Gérer ses biais cognitifs en tant que testeur – 3ème partie

Gérer ses biais cognitifs en tant que testeur – 3ème partie

Dans la première partie de cette série consacrée aux biais cognitifs, nous avons vu une liste dédiée à la catégorie des biais avec Trop d’informations. Ensuite, dans le second, les biais cognitifs dûs au Manque de sens. Si vous ne les avez pas encore lu, je vous suggère de commencer par là. Dans cette troisième partie, nous allons voir que le « besoin d’agir rapidement » peut aussi conduire à des biais.

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.

catEn 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 unitaires, des tests d’intégration inutiles et pas de tests de bout en bout. 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.

 

changeAvouons-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 fausse.

 

Money

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 sur son blog Science Etonnante.

 

Effet Ikea

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

 

eiffel-ikea_o_93837Je 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.

 

america-743574_1280Contrairement 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 2% 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 ce qui a échoué.

 

 

 

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.

 

InformationsNous 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 essayer d’éviter le reste. Restez concentré sur les choses importantes.

 


 

Le prochain article sera le dernier de la série et traitera des biais de la catégorie « Que devrions-nous nous souvenir? ». Vous le trouvez à cette adresse, n’hésitez pas à réagir en laissant un commentaire dans un article de la série.

 

Références
Buster Benson: « Cognitive bias cheat sheet – Because thinking is hard »
Michael Bolton: « Critical thinking for testers »
Maaike Brinkhof: « Mapping biases to testing »
Wikipedia: « List of cognitive biases »
Daniel Kahneman: « Thinking, Fast and Slow »

Une réaction au sujet de « Gérer ses biais cognitifs en tant que testeur – 3ème partie »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.