Gérer ses biais cognitifs en tant que testeur – 1ère partie

Gérer ses biais cognitifs en tant que testeur – 1ère partie

Cela faisait longtemps que je voulais écrire à propos des biais cognitifs. Le sujet m’est venu lors de 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 (Produit SlackHQ ) 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 …presque si vous allez lire ceci.

Une visualisation impressionnante a été faite par John Manoogian III et a depuis été ajoutée à la page Wikipedia.

cognitive_bias_codex _-_ 180_biases_designed_by_john_manoogian_iii_jm3

 

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.

Voici la première partie de cette série de quatre article avec les biais de la catégorie « Trop d’informations ».

 


 

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.

photo-256889_1280Les 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.

 

shipping-1573495_1280L’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 androids, quelques iOS et Windows Phone, au format smartphone mais aussi tablettes et phablets (espérons que Blackberry ne soit presque plus utilisé).

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

 

Le biais de confirmation

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

agree-1728448_640Disons 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.

b_1_q_0_p_0Tout 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.

 

 

 


 

Cette première partie est maintenant terminée. Nous verrons la prochaine fois les biais de la catégorie « Pas assez de sens » dans l’article Gérer ses biais cognitifs en tant que testeur – 2ème partie. En attendant, n’hésitez pas à laisser un commentaire.

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 »

3 réactions au sujet de « Gérer ses biais cognitifs en tant que testeur – 1ère 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.