# 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.