Tester c'est vérifier
“La plupart des équipes QA disparaîtraient si chaque équipe avait une stratégie de test adéquate. Repasser l’activité de test à une autre équipe c’est faire preuve d’un manque de responsabilité.” (Expert TDD)
“Donc t’es en train de me dire… que je dois écrire du code pour savoir si le code que j’ai écrit plus tôt fonctionne bien ?” (Mème)
“Tester le code automatiquement, très bien, mais qui teste les tests ?” (Un collègue que j’essayais futilement de convaincre d’essayer TDD)
Vous le reconnaissez ? Il est sous-jacent dans chacune de ces gemmes, c’est le cliché universel à propos du test :
Tester c’est vérifier
Un cliché d’autant plus nocif qu’il comporte une part de vérité : beaucoup d’activités de test impliquent bien une forme de vérification, c’est à dire la confrontation d’un observé avec un attendu, d’une hypothèse avec des faits.
Mais tester, c’est faire bien plus que des vérifications. Ou bien c’est faire des vérifications, mais sur la base de prémisses indéfinies, imaginées, introuvables dans le peu de documentation que comporte le projet, impossibles à déduire mécaniquement du code source.
C’est vendredi, jeu-quizz :
On s’apprête à déployer un programme en production, qui permettra à l’entreprise qui l’a fait créer de vendre ses services et de faire des profits. On vous a recruté (au tarif Linked In ! €10K !) pour tester ce programme avant le déploiement. Vous y passez le temps que vous voulez. On souhaite déployer dans exactement 5 jours.
Que faites vous ?
🄰 Je fouille la base de code à la recherche des tests auto, et je les lance. S’ils passent tous, je vérifie la couverture. Si elle est de 100%, j’ai fini de tester, je touche €10K
🄱 Je me fais une copie de la “doc” du projet : user stories + critères de recette + anomalies, puis je définis des cas de test, puis des jeux de données, puis des scripts pour vérifier tout ça. Sacré boulot, mais bon, €10K, il faut savoir ce qu’on veut.
🄲 Je soumets le code à une IA de génération de cas de tests afin que cette IA détecte les problèmes à ma place. De loin la solution la plus reposante.
🄳 Je demande à l’équipe de développement si elle sait faire A). Je demande au PO de me décrire le programme du point de vue de son utilisation, en n’oubliant pas les anomalies. Je demande aux développeurs ce qui a été le plus dur à mettre au point, et pourquoi. Ce qui a été surprenant de facilité. Je rencontre le sponsor, les utilisateurs, je leur demande quelle parties du système sont absolument critiques pour l’entreprise. Je scanne l’ensemble de la correspondance sur le projet à la recherche des mots “juste”, “simple”, “option”, “changement”, etc.
J’explore les pistes ainsi établies, en m’outillant selon mes besoins, à la recherche de comportements ou de résultats problématiques voire inacceptables, et dont la connaissance vaudrait largement €10K pour mon client.
🄴 Tester, c’est douter. Je nettoie un peu le code et j’améliore les perfs.
Moi, je prends l’option D.
Pas vous ?