Comment l’ATDD peut améliorer votre approche agile ?

Définition de l’ATDD

L’ATDD signifie « Acceptance Test Driven Development” est une approche de développement logiciel qui vise à améliorer la qualité du logiciel en se concentrant sur les exigences du client. 

C’est un mnémonique créé avec l’agile pour aboutir, in fine, à : 

• Fournir aux développeurs les scénarios de test afin qu’ils puissent développer avec une approche dite TDD (Test Driven Development). 
• Fournir aux différents « testeurs » les tests à exécuter. 

Mais cette définition orientée sur les résultats cache en réalité bien plus d’avantages. Elle permet, en effet, de : 

• S’assurer de la qualité des spécifications fonctionnelles : leur clarté, leur cohérence (absence de contradictions), et leur complétude, ce qui est fondamental avant même de tester ! 
• Générer les tests automatiquement à partir des spécifications préalablement vérifiées, ce qui garantit leur pertinence. On peut dire que la démarche fournit « les meilleurs tests possibles » pour un délai donné. Elle évite aussi d’éventuelles incohérences entre les documents décrivant le système et ceux de test. 
• Analyser le taux de couverture des tests, ce qui donne la possibilité de poser des critères d’arrêt des tests. Il s’agit de maîtriser leur nombre ou de les adapter aux risques encourus. 

L’ATDD : Pour qui ? Dans quel contexte ?

1. L’ATDD : une approche qui profite à tous les membres de l’équipe de développement

Disons, tout d’abord, quelques mots sur Le BDD (Behaviour Driven Development) pour le différencier de notre sujet. Cette approche recommande une expression textuelle des spécifications de « User Stories » (US) en agile. Elle s’assimile souvent à un canevas à respecter pour définir tout scénario de test, appelé « Gherkin ». Cette expression des « critères d’acceptation » est connue en agile comme un préalable à la programmation des US en mode en TDD. 

La démarche ATDD, de son côté, va proposer, non seulement un mode textuel de spécification pour les User stories, mais aussi un mode graphique pour tester les fonctionnalités (plus ou moins grandes) du système. Ceci concerne, en particulier, les métiers (jusqu’aux « tests de bout en bout » par exemple). 

D’autre part, nous le verrons, l’ATDD cherche à renforcer l’expression des exigences fonctionnelles, et des scénarios qui en découlent, bien au-delà de quelques mots clés imposés. Ceux-ci sont en effet largement insuffisants pour l’ensemble des acteurs qui doivent bien comprendre les spécifications fonctionnelles, ne pas oublier de règles à implémenter, et produire des tests efficaces.

2. L’ATDD s’applique en agile, mais aussi en mode cycle en V

Certes l’agile s’est emparé de l’ATDD car vise à accélérer les itérations de développement, mais la démarche peut très bien s’appliquer dans un projet « traditionnel » et lui faire gagner ainsi du temps. 

Quel outil utiliser pour ATDD ?

L’ATDD peut être une démarche simple et efficace à respecter : c’est « l’ATDD manuelle ».  

Elle peut également être outillée en faisant l’acquisition d’un outil spécialisé. 

Il existe de nombreux outils qui peuvent être utilisés pour mettre en œuvre l’ATDD (Acceptance Test-Driven Development). Voici quelques exemples d’outils populaires : 

• Yest
• Agile Requirements Designer (ARD)…  

Il est important de choisir l’outil qui convient le mieux à vos besoins et à votre équipe de développement. Après le choix d’un outil, il est essentiel de se former. 

Formation ATDD : découvrez les bénéfices de cette approche de développement logiciel

Notre formation sur l’ATDD vise à :

1. Comprendre les spécificités du mode agile au regard des spécifications. Celles-ci sont déterminantes, nous l’avons vu, pour l’ATDD. Ce ne sont donc pas des remarques anodines qui seraient formulées comme un simple rappel sur l’agilité, mais structurantes. Elles couvrent tous les niveaux de spécifications, tous les types de tickets (artefacts) agiles.

    

2. Expliquer comment spécifier ! Notre formation donne un cours sur le formalisme BML (Business Modeling Language) mis en place par Didier JOLIOT sur 30 ans et sur tout type de projet (depuis les logiciels temps réels critiques jusqu’aux projets de SI, des plus simples aux plus complexes, dans le domaine Banque-Assurance). Le but est d’avoir des spécifications non seulement compréhensibles, non ambiguës,  mais aussi vérifiables !
3. Montrer comment aboutir ensuite, à partir des spécifications en BML, aux tests. La formation s’appuie sur la description d’une démarche précise et facile à appliquer : l’algorithme des tamis successifs. Elle explique comment faire dans deux situations : en mode traditionnel et en agile.De plus la solution touche aussi bien les tests des nouveautés livrées que les tests de non-régression. Ce point, qui est complexe, est expliqué en général de manière floue. Le sujet demeure mal maîtrisé. L’approche décrite formule des solutions simples et pragmatiques.

    

4. Décrire, pour terminer, l’offre des outils ATDD. Il ne s’agit pas de faire un cours sur chaque outil, mais de vous donner un aperçu de leurs fonctionnalités, de leurs avantages mais aussi de leurs inconvénients. Dès lors vous serez armés pour faire vos choix. 

L’ATDD : quelles sont les questions les plus fréquemment posées par les développeurs ?

Vous êtes manager, développeur, testeur … Vous avez des attentes légitimes : 

• Puis-je « agiliser » mes projets de cycle en V ou compléter l’approche agile DEVops ?  
• Puis-je mieux maîtriser les spécifications et automatiser les analyses d’impact ? 
• Comment avoir des spécifications pouvant permettre un vrai dialogue entre développeurs, testeurs et Scrum masters sans rester ambigu ou être trop formel ? 
• Peut-on gagner en productivité en réfléchissant sur le fond de la solution à implémenter et en accélérant ce qui peut l’être, c’est-à-dire la conception des tests ? 

• Comment puis-je trouver rapidement les tests de mes dernières évolutions, mais aussi ceux de non-régression ? 
• Peut-on trouver la bonne adéquation entre génération des tests et risques ? 
• Comment adapter les activités de spécifications et de tests pour des Maîtrises d’Ouvrage (cycle en V) ou des Product Owners (en agile) ? 
• Quels sont mes choix d’investissement ?  Démarche ATDD manuelle ? automatisée ? Quels risques dans chaque cas ? 

Vous vous posez ces questions sur l’ATDD ? Nous avons les réponses et bien plus !