Embardées
[heuristics]
Une équipe crée un produit logiciel : il lui faut donc le tester. Sinon elle y laisse des plumes. Des défauts résiduels, qui provoquent plantages, pertes de temps, mécontentement, perte de confiance.
On fait donc des tests : on place le produit dans certaines situations, et on observe. On confronte les résultats observés avec ce que l’on pense être attendu.
C’est long, répétitif, fragile aux erreurs et peu efficace : on n’explore qu’une infime partie des comportements possibles, et on ramasse tout ce qui arrive.
En s’entêtant dans cette logique, on pourrait aboutir à un anti-pattern : la pure boîte noire. Comme testeurs, on ne sait rien de la structure et du fonctionnement interne du produit sous test. Tout ce qu’on peut en apprendre, on l’a tiré de déductions effectuées sur la base d’observations du produit.
On est entouré d’inconnues. Quoi, pourquoi, quand, comment, pour qui ? La surprise peut arriver de n’importe où. On ne peut pas prévoir combien de temps il nous faudra.
Pour éviter cet écueil, les testeurs échangent avec les concepteurs du produit (le Métier + la Tech) et font connaissance peu ou prou avec sa structure interne, le code. Pour aller plus loin, les concepteurs bâtissent une stratégie de vérifications automatisées :
- soit en intimité avec le code lui-même : on écrit des petits bouts de code qui vérifient automatiquement le comportement de petites parties du code
- soit aux interfaces du code avec son environnement : on écrit (ou on génère par capture) du code d’outil qui vérifie automatiquement des comportements de grosses parties du code via ces interfaces (ou via des “crochets”)
C’est efficace, rapide, répétable. Ça prend un certain temps à élaborer et à maintenir, mais le surcoût en vaut la chandelle. On arrive ainsi à faire des vérifications automatisées une véritable étape dans la chaîne d’intégration et de déploiement du logiciel. On est industriel !
En s’entêtant dans cette logique, on pourrait aboutir à un autre anti-pattern : la pure boîte blanche. Comme concepteurs, on sait tout de la structure et du fonctionnement du logiciel. On finit par croire que tout ce qu’on peut en apprendre, on le sait déjà. Il n’y a plus de mystère, plus de surprise possible : La couverture est à 100%.
Evidemment ça ne marche pas : On croyait tout comprendre et tout savoir, mais en fait la complexité propre de notre système finit par nous le rendre opaque à nouveau. On se sentait sûr de soi, et on est bien surpris : On maîtrisait les inconnues connues. On n’avait plus le soupçon des inconnues inconnues.
Ne vous fiez pas aux avis des influenceurs qui vous disent :
“Les tests auto, pouah, perte de temps, ce qui compte c’est le time to market !”
ni de ceux qui vous disent :
“Si vous avez encore des testeurs chez vous, votre CI/CD est obsolète, vous êtes ringards !”
Faites vos propres embardées. Observez. Oscillez.
