La taverne du testeur

Testons les principes du test!

Je ne vais pas y aller par 4 chemins, pour moi s’il y a une chose à retenir dans le monde du test, c’est les 7 principes.

C’est un peu notre manifeste Agile à nous, nos valeurs, notre phare qui permet de faire des choix aussi efficients que possible. Néanmoins, tout comme le manifeste Agile ou tout élément fondateur il est important de savoir se l’approprier, connaitre ses faiblesses et aussi savoir l’adapter.

Afin d’aller au bout de cette logique je vous propose donc aujourd’hui une analyse critique et un test de ces principes !

N’hésitez pas à faire également cet exercice et vos propositions !

Les tests montrent la présence de défaut

Ce principe rappelle que les tests sont là, à la manière d’un détecteur de métal qui permet de trouver des pièces, pour détecter des défauts mais qu’en aucun cas ils peuvent montrer une absence de ces derniers.

Partant de ce principe on peut vite se trouver défaitiste en se disant, ce qui est vrai, qu’il y aura toujours des défauts. On peut alors se demander s’il y a vraiment un intérêt à tester.

On arrive ici à une limite de ce principe. En effet ce n’est pas parce que l’on ne peut pas assurer une absence de défaut que l’on ne peut pas fournir une information de valeur. Les tests donnent de l’information sur un niveau de qualité. Je préfère largement avoir en production 10 bugs mineurs plutôt qu’un bug majeur voire même critique.

On pourrait donc reformuler ce principe en :

Les tests ne peuvent pas montrer l’absence de défauts, par contre des bons tests peuvent assurer une présence non gênante de défauts !

Les tests exhaustifs sont impossible

Ce principe relève du bon sens. Il rappelle que les parcours et contextes d’utilisation possibles sont infinis. Il est donc impossible de tout tester…

Si l’on va plus loin, l’ensemble des tests possibles étant infini, la couverture de test doit toujours être négligeable et considérée à 0%. Dès lors on peut se demander s’il y a un vrai intérêt à tester.

Là encore, il faut se rappeler que le rôle des tests est de donner de l’information. Ce principe est là pour nous aider à faire des choix et réduire de façon consciente le périmètre de test (qu’est-ce que l’on teste et qu’est que l’on ne teste pas). Cette approche permet alors de définir des couvertures d’un ensemble fini et de procurer une information de valeur.

On pourrait donc reformuler ce principe en :

Les tests exhaustifs sont impossibles, il est nécessaire de choisir ce que l’on va tester

Tester tôt

Ce principe est peut-être celui que j’utilise le plus concrètement. On le voit notamment avec le BDD, l’automatisation de l’exécution des tests pour exécuter les tests plus tôt ou l’importance d’avoir des environnements et données de test.

Néanmoins, en appliquant à la lettre ce principe on peut tomber sur des contradictions comme le fait de ne pas faire des tests jugés tardifs dans le processus de développement. Ou encore, le refus du shift right qui peut apporter une vraie valeur ou même la suppression des tests d’acceptation avec uniquement des tests unitaires et des tests d’intégration.

Ces dérives viennent évidemment d’une mécompréhension de ce principe. Les différents types de tests sont complémentaires et il peut être primordial, dans certains contextes, de faire des tests en production… simplement car ces tests ne peuvent pas être faits avant.On pourrait donc reformuler ce principe en :

Tester aussi tôt que possible

Le regroupement de défaut

Ce principe rappelle que de nombreux défauts sont liés et que certaines parties du logiciel sont plus propices à l’apparition de défauts que d’autres. Ce principe est une des bases du RBT (Risk Based Testing) qui identifie des faiblesses pour concentrer son effort de test sur ces derniers et tester efficacement.

Une dérive de ce principe c’est que l’on peut vite se retrouver à ne tester QUE là où l’on a trouvé des défauts et oublier de tester dans d’autres zones où de nouveaux défauts peuvent apparaitre ou grossir… ce qui nous emmène d’ailleurs vers l’usure des tests !

On pourrait donc reformuler ce principe en :

Les défauts sont en général regroupés mais peuvent apparaître là où on ne les attend pas

L’usure des tests

Anciennement appelé « paradoxe des pesticides » ce principe est là pour nous rappeler que plus on fait des tests moins ces derniers ont de chances de remonter des défauts. Si l’on reprend le principe précédent, multiplier les tests dans une zone sur une longue période rend cette zone beaucoup plus résistante aux défauts.

L’idée de l’usure des tests est de rappeler qu’il faut faire évoluer ses tests si l’on souhaite continuer à être efficace dans sa recherche de défauts. Néanmoins, certains tests restent nécessaires. Il peut être intéressant de les faire évoluer mais uniquement à la marge. Les tests réglementaires (ex : RGPD ou couverture liée à une norme), des parcours basiques mais essentiels ou encore des tests liés à des fonctions vitales sont des tests qu’il est nécessaire de conserver et ce même s’ils ne détectent pas de défauts.

On pourrait donc reformuler ce principe en :

Les tests s’usent mais pas tous à la même vitesse. Certains sont inoxydables

Les tests dépendent du contexte

Ce principe est peut-être le plus instinctif ! De plus il est en parfaite synergie avec les précédents. On ne peut pas tout tester donc il faut adapter ses tests. Les tests s’usent il va donc falloir les adapter…

Les tests dépendent évidemment du contexte et en fonction de ce dernier l’approche ne sera pas la même.

Sachant cela on peut vite arriver sur des approches étonnantes mais efficaces. Néanmoins cela amène à 2 types de situations contre-productives:

  • Des situations avec de la personnalisation à outrance qui entraine une absence d’écoute et de renseignement sur ce qui se fait ailleurs
  • Une absence d’évolution des pratiques… alors que le contexte évolue

On pourrait donc reformuler ce principe en :

Les tests dépendent d’un contexte qui évolue

L’illusion d’absence d’erreur

Ce principe est là principalement pour rappeler que les tests sont là pour s’assurer que le logiciel répond à un besoin. Qu’il est nécessaire de connaitre ce besoin afin de s’assurer que le service qui a été développé répond à ce besoin.

Ce principe est peut-être un des principes qui a le plus gagné avec l’agile et la notion de valeur pour l’utilisateur. Il y a maintenant des équipes avec une forte conscience de l’intérêt des utilisateurs et qui font de nombreuses études en production pour comprendre les comportements. D’ailleurs on note des dérives avec la multiplication des enquêtes de satisfaction.

Ces processus de vérification mis en place servent de valeurs étalons qui sont malheureusement trop souvent perçues comme des vérités absolues alors qu’elles ont également leurs limites (ex : satisfaction uniquement si note supérieure ou égale à 9/10).

On pourrait donc reformuler ce principe en :

L’illusion d’absence d’erreur du logiciel, de nos processus et nos indicateurs

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

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

culture générale

Ce que nous apprend la mythologie sur les tests: Cassandre

L’idée de cette série m’est venue suite à l’excellent article de Zoé Thivet. Présentation de la série Les mythologies ont de nombreux intérêts. Je note par exemple ces 2 points: l’intérêt historique permettant de comprendre ce que les personnes croyaient au moment où ces mythologies étaient des religions l’intérêt histoire

Lire la suite »
ISO 25010

Types de tests (ISO 25 010): les tests de sécurité (6/8)

Après les tests fonctionnels, de performance, de compatibilité et d’utilisabilité au sens ISO – 25 010, je m’attaque dans cet article à la famille des tests de sécurité afin de savoir exactement à quoi correspond la « sécurité » dans le cadre de la qualité logicielle. Pour avoir plus d’informations sur

Lire la suite »