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.