L’ATDD est la contraction de Acceptance Test Driven Developpement (Pilotage par les tests métiers en français). Il s’agit d’une approche efficace de développement logiciel.

Tout a commencé par des questionnements successifs en interne sur la démarche à adopter pour résoudre de gros problèmes méthodologiques d’un de nos clients. Dans un développement logiciel, de quoi avons-nous vraiment besoin ? Que constate-on dans les modèles traditionnels de développement logiciel ? Quelles en sont les problématiques ?
Qu’entreprendre pour diminuer le taux d’échec des projets ?

I. État des lieux dans nos organisations

Dans nos méthodologies actuelles de développement logiciel, nous avons besoin de documentations et d’équipes:

  • Le cahier des charges décrit le besoin général, réalisé par la MOA (maîtrise d’ouvrage)
  • Les spécifications fonctionnelles générales décrivent le besoin par des règles de gestion, réalisées par la MOA  ou l’AMOA (assistance à maîtrise d’ouvrage)
  • Les spécifications détaillées décrivent le besoin en termes quasi d’implémentation (algorithme de calcul, maquette écran, …); souvent réalisées par la MOE (Maitrise d’oeuvre), elles sont “censées être validée” par la MOA avant les développements.
  • Les cahiers de recette décrivent le besoin par des scénarios de tests, réalisés par l’équipe de recette
  • D’autres documentations qui… décrivent le besoin d’un point de vue singulier

De cet inventaire, il y a deux constats à faire. D’abord, il y a un phénomène de reformulation du même besoin, tâche très chronophage dont le temps de réalisation augmente proportionnellement avec la complexité fonctionnelle et technique de l’application. Ensuite, les équipes fonctionnelles (MOA, AMOA et Recette) et techniques (MOE) ne partagent jamais un même document, chacune se créant, de fait, son propre référentiel de travail.

Vu les ratios (COCOMO, etc.)  généralement utilisés pour estimer les charges des projets informatiques, les charges de développement pur d’une application représentent environ 40%, voire 45%, des charges totales du projet. Plus de la moitié du temps est, ainsi, consacré à la rédaction de documentations! Le livrable le plus important serait-il la documentation qui aura servi à réaliser le logiciel ?

Les charges de recette représentent bien 15% des charges globales pendant les phases d’estimation mais retombent souvent à moins de 5% vers la fin du projet afin de rattraper les retards (90% des projets informatiques). Pas étonnant que plus de 50% des projets SI n’aboutissent pas et qu’il y a un tel décalage entre le niveau de qualité perçue par les utilisateurs et le coût des projets IT !

Ne faut-il pas, pour faire diminuer ce taux d’échec, répondre rationnellement à ces deux problématiques ? D’une part, commençons par considérer que le livrable principal d’un projet informatique est le logiciel et que, d’autre part, les tests  sont essentiels pour atteindre la qualité logicielle et ne doivent pas être la dernière roue du carrosse !

II. Vers une gestion de projet IT plus efficiente

L’ATDD ou Acceptante Test Driven Developpement (Pilotage par les tests métiers en français) est une approche de développement logiciel itérative et incrémentale basée sur un principe fondamental : les tests sont au coeur du projet :

  • Les tests servent aux spécifications générales du logiciel
  • Les tests sont donc créés et automatisés en amont du développement
  • Le développement est ensuite réalisé en fonction des tests
  • Les tests sont exécutés automatiquement et permettent de définir lorsque le code est terminé (lorsque tous les tests sont au vert) !

C’est un procédé itératif pour impulser de la réactivité et du dynamisme aux équipes (comme initié dans l’Agile) et incrémental car il y a une capitalisation sur les tests créés dans les itérations (les tests automatisés de l’itération 1 serviront aux tests de non régression des itérations suivantes).
Acceptante Test Driven Developpement

Schématisation de l’ATDD

III. Retour d’expérience sur le sujet

Evoluant dans un contexte règlementaire extrèment fort, notre client voulait réorganiser et, de facto, améliorer ses processus internes de gestion de projet informatique entre les diverses équipes fonctionnelles (MOA, recette, diffusion) et techniques (développement, intégration). Comme souvent dans ce genre de cas, l’audit d’organisation réalisé a mis en avant des problématiques profondes d’industrialisation et de communication.

La transition vers l’ATDD dans cette organisation ne s’est pas faite sans effort. Inutile de dire que le changement est, avant tout, d’ordre organisationnel et non technologique. Aussi, même si l’ATDD doit s’accompagner de la mise en place d’un outil ou plateforme d’automatisation des tests, il impose d’abord et surtout une collaboration de toutes les équipes à des étapes phares du projet, comme la conception des cas de tests par exemple. Sans cette coordination et participation active, le projet ne prend pas. C’est le premier pilier de la réussite.

Lorsque ce facteur d”entreprise collaborative” a été acquis, alors effectivement la question de l’outillage s’est posée. Directement connecté aux couches services du code et aux tables des bases de données par du code appelé “fixture”, l’outil permet de créer des tests, des jeux de données et d’exécuter automatiquement les tests métiers, d’un simple clic… Fonctionnant comme un wiki, il est accessible et destiné aux équipes (fonctionnelles et techniques), rendant les résultats transparents en temps réel, élément très appréciable lorsque, comme dans notre cas, les équipes fonctionnelles et techniques sont géographiquement éclatées.

Il existe 3 outils principaux sur le marché : FitNesse, Cucumber et Green Pepper. Ci-dessous une liste non-exhaustive des avantages et inconvénients de chaque outil… (à compléter donc)

Outil Avantages Inconvénients
FitNesse
http://fitnesse.org/
  • Open source
  • Forme tabulaire pour limiter l’aspect rédactionnel et faciliter l’exhaustivité des cas de test.
  • Interface utilisateur manquant d’attrait
  • Absence d’options très utiles (impression, classement des tests par dossier)
Cucumber
http://cukes.info/
  • Open source
  • Expression des scénarios de test sous forme littéraire facilitant la compréhension
  • Fixture écrites dans le langage Ruby relativement peu répandu
  • Peu documenté
Green Pepper
www.greenpeppersoftware.com
  • Gestion des versions des tests
  • Interface très agréable
  • Suite applicative complète
  • Expression des scénarios de test sous forme littéraire facilitant la compréhension
  • Licence

C’est FitNesse qui a été retenu pour notre projet. Plateforme la plus utilisée par les entreprises aujourd’hui pour supporter l’ATDD, elle représente le plus faible investissement et donc le ROI le plus visible.

Au sein des équipes opérationnelles, après diverses séances de coaching et d’accompagnement opérationnel, certaines questions se sont posées et ensemble, nous avons pu répondre à chacune d’entre elle et adresser des bonnes pratiques.  Voici quelques unes des plus importantes :

Phase projet Questionnement Bonne pratique associée
Présentation de l’ATDD Comment concrètement  intégrer cette méthodologie sur un projet ? Il y a deux problématiques distinctes : les anciens développements (projet d’évolution fonctionnelle ou technique) et les nouveaux développements.
Pour les nouveaux développements, la mise en place de l’ATDD se fait naturellement en commençant par cadrer l’organisation projet (vision du projet, objectifs à atteindre, mise en place des équipes, outillage) et plan projet (livraison des itérations).
Pour les anciens développements, l’ATDD se fait par étapes et progressivement. Une bonne pratique est de partir des anomalies les plus récurrentes et d’automatiser les tests associés progressivement.
Coaching des équipes métiers Comment discuter avec des développeurs lorsque l’on ne parle pas le “même langage” ? L’ATDD a l’avantage de mettre les tests en avant. Ils servent d’exemples aux spécifications. Il n’y a donc plus d’inquiétude d’interprétation entre ce qui est dit et ce qui est perçu, surtout lorsque les équipes utilisent des langages différents : Fonctionnel VS Technique. Avec des exemples concrets, la fonctionnalité est décrite le plus objectivement possible, avec un vocabulaire commun compris par tous.
Coaching des équipes de qualification Quelle sera notre rôle une fois que tous les tests seront  automatisés ? L’automatisation des tests fonctionnels permet à l’équipe de qualification de réaliser des tests “intelligents”, des tests non automatisables ou de travailler directement à l’optimisation des tests. L’ATDD permet de valoriser le testeur en lui confiant de nouvelles responsabilités.
Coaching des développeurs Où-trouvera t-on le temps de coder des fixture en plus du code métier ? Le ROI de l’ATDD est presque immédiat. En effet, lorsque coder des fixture équivaut à une charge de travail supplémentaire, réduire le temps de correction des anomalies du code constitue un gain réel et important (tant en termes de durée qu’en termes financiers). Rappelons-le, la correction d’une anomalie coûte 2 fois plus cher en phase de recette qu’en phase de développement.

IV. Les 3 idées clés à retenir de cet article :

  • L’ATDD crée un cadre collaboratif pour toutes les équipes opérationnelles en charge d’un projet informatique, ce qui permet une grande transparence.
  • Les tests métiers servent d’exemples aux fonctionnels pour spécifier, de critères de validation du code pour les développeurs et de tests de non-régression automatisés pour les testeurs.  La productivité des équipes est, donc, accrue.
  • La qualité logicielle peut, enfin, être atteinte.

Liens vers billets internes :

Pour approfondir le sujet :