Stratégies

J’allais détailler pourquoi je jette aux gémonies la pyramide des tests, et la couverture des tests avec elle, mais inutile : le dernier billet de Laurent Bossavit met en lumière le problème bien mieux que je ne l’aurais fait. Lisez-le !

Vous l’avez lu ? Lorsque nous réduisons un potentiel problème de qualité à un rapport de quantité, nous raisonnons à l’emporte-pièce, et notre stratégie s’en ressent.

Traverseriez-vous une rivière profonde d’1 mètre en moyenne ?

“18 heures d’indisponibilité ! Et pourtant notre coverage est en amélioration constante, je ne comprend pas”. Famous last words.

△

Je n’ai donc pas de conseil à donner en taille de couverture ou en forme de pyramide. Mais ça ne m’empêche pas de formuler certaines réflexions, et de les partager. 😅

Nous posons des tests sur un système et nous le testons (ce n’est pas la même chose) en vue de réduire autant que possible le potentiel de problèmes que ce système présentera eu égard à ses objectifs et au contexte dans lequel il devra fonctionner.

En écrivant des tests, nous cherchons à nous prémunir contre des inconnues connues : ce sont tous les problèmes que nous pouvons anticiper à la conception, les erreurs que nous savons que nous risquons de faire, la complexité que nous ne voulons pas laisser dans l’ombre. Nous voulons mitiger les effets connus de cette complexité.

▶️

— j’écris un test: testApres12StrikesScoreEgale300() et il va échouer parce que le programme ne tient pas encore compte de la règle du 10ème frame.

⏸

En testant, nous cherchons à nous prémunir contre des inconnues inconnues : ce sont toutes les surprises que nous réserve le produit, qui échappent à notre compréhension limitée de ce système à l’instant t. Nous allons à la rencontre de sa complexité (avant que celle-ci ne frappe nos utilisateurs).

▶️

— La QA a réussi à produire une facture avec un montant négatif! Ils sont trop forts !

⏸

Pour des raisons culturelles, sociologiques, historiques, mais aussi techniques, nous focalisons cette activité de “test” sur deux centres d’intérêt à peu près distincts :

• le comportement du système avec l’extérieur, i.e les interactions Humains/Machine 🖥🤔
• le comportement “interne” du système, i.e les interactions Machine/Machine ⚙️🤖

Ces deux partages :

• inconnues connues / inconnues inconnues
• interactions H/M / interactions M/M

divisent en 4 zones l’étendue du territoire dans lequel le mot “test” revêt du sens pour le développement de logiciel. Dans chacune des zones, les états de l’art, les procédés, les pratiques, les process sont différents, et à juste titre. Cf le diagramme en illustration. Cette carte heuristique, ce “mind-map”, permet de détecter rapidement des erreurs de stratégie. Je me suis permis de mentionner dans chaque zone ma stratégie préférée.

Prochainement sur cette chaîne, un quizz pour valider ou infirmer ce modèle. Stay Tuned ! 📡

publié sur Linked In le 23/08/2023