Un des principes fondamentaux du test logiciel évoqué dans ISTQB (International Software Testing Quality Board) est que les tests peuvent prouver la présence des défauts. Les tests réduisent la probabilité que des défauts restent cachés dans le logiciel mais, même si aucun défaut n’est découvert, ce n’est pas une preuve d’absence de défauts. On ne peut jamais certifier qu’un logiciel ne contient pas de bug.
Beaucoup d’études ont essayé de se pencher sur ce sujet: l’effet tunnel, l’effet papillon, les tests dans les méthodologies agile … pour tenter de minimiser le risque des bugs résiduels dans un produit mais un axe important systématiquement négligé: les biais cognitifs.
Les biais cognitifs
Un biais cognitif est un mécanisme de la pensée qui cause une déviation du jugement. Le terme biais fait référence à une déviation systématique de la pensée logique et rationnelle par rapport à la réalité. Les biais cognitifs conduisent le sujet à accorder des importances différentes à des faits de même nature et peuvent être repérés lorsque des incohérences apparaissent dans un raisonnement.
Comment ces biais peuvent-ils impacter les résultats d’un test ?
Quand un testeur commence les tests, il est déjà sous influence des biais cognitifs à travers ses jugements personnels: quelle partie du produit contient le plus de bugs, qui a développé la fonctionnalité, l’historique du produit …
Il est important de connaître ces biais afin de minimiser leurs impacts et de les gérer efficacement.
Le biais de négativité
Le biais de négativité est la tendance à donner plus de poids aux expériences négatives qu’aux expériences positives et à s’en souvenir davantage.
Il est difficile pour les testeurs de donner leur accord pour une release ou une mise en production, ils veulent toujours effectuer plus de test pour palier à un manquement (bug non détecté) lors de la version précédente ou des projets antérieurs.
Afin de diminuer l’effet de ce biais, Il est préférable de toujours analyser chaque projet / version en terme de risques et objectifs définis avant de commencer les tests.
Ce couple objectifs / risques permettra de définir des critères de sortie (permettant de définir si le produit est prêt pour la release) mesurables et sur lesquels un testeur peut se baser pour donner son accord pour la release ou la mise en production.
- Le biais de confirmation et des croyances
Le biais de confirmation est la tendance, très commune, à ne rechercher et ne prendre en considération que les informations qui confirment les croyances et à ignorer ou discréditer celles qui les contredisent.
En général, dans le monde des tests, si on pense que le code d’un développeur spécifique a plus de défauts que le code développé par les autres alors nous devrions passer beaucoup de temps à tester le dit module.
Être sous l’influence de ces croyances aura mécaniquement tendance à augmenter le risque de ne pas détecter des défauts dans les modules développés par les autres développeurs.
Afin de diminuer l’effet de ce biais, il est conseillé de revoir les cahiers de test, les plans de tests, les suites de tests par d’autre personne de l’équipe avant de commencer les tests.
- Le biais de cadrage
Le biais de cadrage est la tendance à être influencé par la manière dont un problème est présenté. Par exemple la décision de pratiquer ou non une opération chirurgicale peut être affectée par le fait que cette opération soit décrite en termes de taux de succès ou de taux d’échec, même si les deux chiffres fournissent la même information.
En d’autres termes, les testeurs ont tendance à ne valider que le comportement attendu et, par conséquent, les tests négatifs sont ignorés.
Lorsque des scénarios de test sont écrits, nous avons tendance à couvrir toutes les exigences avec leurs comportements attendus et à passer à côté des flux négatifs car tous les flux négatifs ne sont pas spécifiquement mentionnés dans les exigences.
Ils sont implicites dans l’exigence et il est pratiquement impossible de documenter tous les comportements des utilisateurs.
- Le biais d’autocomplaisance
Le biais d’autocomplaisance est la tendance à s’attribuer le mérite de ses réussites et à attribuer ses échecs à des facteurs extérieurs défavorables.
Ce biais contraindrait le testeur à rejeter les erreurs sur les autres. On entend tous les jours : “l’environnement fourni ne marche pas”, “ça fonctionne correctement sur mon pc”, …
Cette attitude a pour effet de tourner le dos à l’amélioration continu qui est une des clés de réussite des testeurs.
Afin de diminuer l’effet de ce biais, on doit appliquer le concept japonais d’amélioration continue KAIZEN qui consiste à se poser la question qu’est ce que j’aurais pu faire différemment pour minimiser ou résoudre ce problème de mon coté.
- L’illusion de savoir
L’illusion de savoir consiste à se fier à des croyances erronées pour appréhender une réalité et à ne pas chercher à recueillir d’autres informations. La situation est jugée, à tort, comme étant similaire à d’autres situations connues et la personne réagit de la façon habituelle. Ainsi, le testeur pourra sous-exploiter d’autres possibilités de tester le système ou de créer de nouveaux cas de test …
Ce biais oriente notre perception et limite notre capacité à sortir du cadre, ce qui a pour conséquence de rater certains bugs.
Afin de diminuer l’effet de ce biais, il est préférable poser des questions en cas de doute et de valider les spécification dès que les premiers draft sont disponibles.
Conclusion
Durant les phases d’analyse post projet, on analyse les chiffres et les livrables (doc, rapports, kpi, logiciel, …) et on a tendance à négliger ou à diminuer les effets psychologiques de la réussite ou l’échec d’un projet.
Parfois, le côté cognitif peut être la principale raison de la réussite ou l’échec d’un projet. On a démontré à travers ce blog l’impact potentiel de certains biais cognitifs sur l’activité de test logiciel.
Découvrez comment eXo Platform peut vous aider à transformer votre entreprise!
