SAND-framework/data/doc-prince-book-generation/doc/tome2/Contents/dev-conclusion.md

1.9 KiB

Le mot de la fin : le pouvoir du canard !

Connaissez-vous le "Duck Typing" (traduit par "typage canard") ? La légende veut que le poète James Whitcomb Riley soit à l'origine de cette expression :

Si je vois un animal qui vole comme un canard, cancane comme un canard, et nage comme un canard, alors j'appelle cet oiseau un canard

Ce principe peut s'appliquer au test logiciel : si un module fonctionnel semble avoir le comportement attendu, possède l'apparence souhaitée, ne génère pas d'erreur, est utilisable facilement, a été utilisé par plusieurs personnes... Alors on peut sans risque penser que ce module fonctionnel est correct et cohérent.

Cette analogie est importante car elle permet de comprendre que tout ne peut (et ne doit) pas être testé par un logiciel. Traduire un besoin fonctionnel en tests automatisés prend du temps ; et ce temps, en général, vous ne l'aurez pas. Il faut donc faire des choix : ne testez pas tout, ayez parfois confiance au travail de l'humain, et concentrez-vous sur ce qui est essentiel ou sensible dans l'application que vous avez à développer.

N'oubliez pas non plus que l'ensemble des pratiques que nous avons évoqué concernent avant tout une démarche. Le développement piloté par le Comportement est une démarche de travail avant de reposer sur des outils. Non, les outils ne comptent pas, seule la communication entre les différents acteurs d'un projet est essentielle.

Enfin, et c'est le plus important, rappelez-vous qu'un projet informatique consiste à produire un service qui sera utilisé par des humains (utilisateurs finaux). C'est à ces personnes qu'il faut penser en priorité. Toutes les pratiques, toutes les recettes fonctionnelles et techniques qui peuvent être mises en place dans un projet ne consistent qu'à optimiser et à améliorer le service rendu par un Produit. A vous de faire en sorte que ce Produit soit le plus efficace possible.