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

Gérer ses biais cognitifs en tant que testeur – 2è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 dus à Trop d’informations. Je vous suggère de le lire si vous ne l’avez pas encore lu. Dans cette seconde partie, nous allons voir que le « manque de sens » peut aussi conduire à des biais.


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.

waveVous ê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.

authorityVotre 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 oeil à 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érifier 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.

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

haloCertaines 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’à un 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 faites par David Louapre sur son blog Science Etonnante.

 

Effet croisé de race

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

disagreeLes 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’avec 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

plane-crash-1431189_1280Ê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.

 

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

time-1752164_1280Pour 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 caractéristique 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 le 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 pour aider le, et comme tout le monde ils sont pleins de biais cognitifs. Si elles sont soumis au «biais de l’information», alors ils vont tout simplement polluer votre prochaine semaine.

Ne pas oublier dans ce cas de lui envoyer un ou deux exemplaires de « The mythical Man-Month » by Frederick P. Brooks Jr.

 


Merci d’avoir lu ce second article de la série des biais cognitifs. La prochaine fois nous parlerons des biais induits par le « besoin d’agir rapidement » dans l’article « Gérer ses biais cognitifs en tant que testeur – 3ème partie. Pendant ce temps, n’hésitez pas à réagir en laissant 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 »

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.