Vérifications Automatisées
[TDD]
Dans mes posts sur TDD, j’utilise le terme “vérification automatisée” plutôt que “test”, pourquoi ?
En 50 ans notre culture s’est imprégnée de logiciel, et donc aussi de ses stéréotypes.
Le plus populaire :
📸 “Développer, c’est écrire du code”
a envahi nos entreprises, qui sont plus promptes à séparer les “doers” des “thinkers” qu’à réformer la façon dont elles apprennent.
En 2ème place vient l’idée que
📸 “Tester, c’est vérifier”
Depuis l’industrialisation de nos CI/CD, il est devenu courant de dessiner des pyramides des tests, d’expliquer le pourquoi de leur forme et de prôner un usage parcimonieux des “tests manuels”, puisque (littéralement) écrire des tests automatisés, “c’est la base”.
Le test manuel, c’est la tâche que le Développeur confère à son Autre : le Testeur Manuel, celui qui s’est enfermé dans un labeur interminable, fragile à l’erreur et fastidieux, par faute de ne pas maîtriser l’art d’automatiser, qui est le Mana de notre civilisation.
Cet Autre qui sert (avec le Pi..eur de Code) de repoussoir dans le système de valeurs du Développeur a pour fonction de masquer la difficulté formidable de notre industrie : comment traduire un système conceptuel ambigu, ouvert, inachevé, capricieux même, en un produit stabilisé ? (Cette difficulté essentielle est également à l’origine du fantasme : les Testeurs Assurent la Qualité).
Dans le modèle qui a ma préférence,
ℹ️ Tester, c’est rechercher dans un produit ce qui menace sa valeur, et communiquer le résultat de cette recherche d’une façon qui aide à prendre des décisions.
Que vient faire cette activité dans un système de développement adéquatement muni de régulateurs ? Des vérifications automatisées protègent la conception contre toute régression. Des relectures de code éliminent les derniers bruits tout en renforçant l’état de l’art appliqué là. What could go wrong ?
Pour qu’un système régule son activité au moyen d’un réducteur de bruit, il lui faut un modèle du bruit à réduire. Un correcteur de pitch par ex. est construit selon ce principe. Dans son modèle, le bruit constitue une inconnue connue.
Les testeurs cherchent précisément des réponses à cette question : What Could Go Wrong. Ils recherchent les inconnues inconnues. Non pas les bruits qu’auraient détectés vos régulateurs habituels, pour peu qu’ils soient mis en place, mais les bruits dans le modèle général, beaucoup plus vaste et flou, qui régit votre conception elle même.
Clara, testeuse professionnelle, recherche des problèmes qui peuvent casser les illusions sur votre produit. C’est son métier. Lorsqu’elle déclare :
🎟 À l’ouverture du formulaire, “Client is not defined at Object.anonymous”
Elle est mobilisée sur une voie d’eau qu’une vérification aurait pu détecter il y a des mois.
Si Clara ne fait plus que cela, ou pire que son poste est supprimé, qui va découvrir les problèmes intéressants ?
Des amateurs très peu motivés, râleurs et colériques : vos utilisateurs.
Stay Tuned!