Si vous êtes familier avec TDD alors ATDD est en quelque sorte TDD avec un niveau de test plus élevé et avec plus de parties prenantes impliquées, en d’autres termes c’est plus un test d’acceptation que des tests unitaires. Si vous voulez en savoir plus sur TDD alors veuillez consulter le post suivant:
Le développement piloté par les tests d’acceptation (ATDD) est une méthodologie de développement basée sur la communication entre les clients métiers, les développeurs et les testeurs. ATDD englobe un grand nombre des mêmes pratiques que la spécification par l’exemple, le développement guidé par le comportement (BDD), le développement guidé par l’exemple (EDD) et le développement guidé par le support également appelé développement guidé par le test de l’histoire (SDD). Tous ces processus aident les développeurs et les testeurs à comprendre les besoins du client avant la mise en œuvre et permettent aux clients de pouvoir converser dans leur propre langage de domaine.
Vraiment mis en œuvre au sein des équipes Agile, l’ATDD est une pratique où les analystes métier, les développeurs ,les testeurs et les utilisateurs travaillent ensemble pour définir les critères d’acceptation de chaque story (ou fonctionnalité) à un stade précoce du processus de développement (Avant que le codage ne commence). Cette approche permet à toutes les parties prenantes d’avoir et de maintenir le même niveau de résultats attendus avant que tout développeur ne commence à coder.
Je sais que nous avons tous entendu ce stéréotype de « Les développeurs ne se soucient pas de la spécification et les testeurs ne veulent pas faire l’automatisation » mais avec ATDD, cela permettra d’économiser beaucoup de temps perdu et d’argent en s’assurant que les développeurs sont plus impliqués dans les premières étapes de la spécification et que les testeurs automatisent les tests d’acceptation.
Comment ATDD est mis en œuvre dans la « vraie vie »?
Vous utilisez SCRUM ? Si oui alors vous faites déjà la plupart du travail en ATDD. si non alors l’exemple suivant doit nourrir votre curiosité :
Exemple
Supposons que le propriétaire du produit ou le client ait demandé la fonctionnalité suivante dans notre application mobile : « En tant qu’utilisateur, je veux contourner l’écran de connexion pour pouvoir utiliser l’application de manière anonyme » Après avoir examiné cette demande avec toute l’équipe (Business analyst, Développeurs, Testeurs…) et avec plus de détails ajoutés à la story ou à la fonctionnalité, nous aurons quelques tests « d’acceptation » ou « fonctionnels » similaires à ceci (Veuillez noter que ce n’est qu’un exemple, de nombreux tests d’acceptation sont manquants pour cette fonctionnalité) :
- Critères d’acceptation 1 : L’application accepte facultativement le login/mot de passe pour se connecter
- Critères d’acceptation 2 : Le contournement du bouton permet à l’utilisateur de naviguer dans l’application sans connexion.
- Critères d’acceptation 3 : Lorsque le bouton bypass sélectionné, l’application ne stocke ni n’affiche aucune information spécifique à l’utilisateur.
- Critères d’acceptation 4 : Lorsque le login/mot de passe est utilisé, l’interface graphique de l’application doit être adaptée aux paramètres de l’utilisateur.
Bénéfices
1- Alignement client-vendeur : En ayant les critères d’acceptation ci-dessus comme information d’entrée, nous (chaque membre de l’équipe) sommes maintenant sûrs que l’application maintiendra sa fonctionnalité de connexion/mot de passe et ajoutera seulement un bouton pour permettre à l’utilisateur de contourner l’écran de connexion.
2- Qualité et rentabilité : Les tests ci-dessus peuvent être facilement automatisés avant même que les développeurs ne commencent à coder.
3- Temps de mise sur le marché : Une fois les tests mis en œuvre, les développeurs peuvent valider leurs tâches requises avant d’annoncer qu’ils ont terminé.
ATDD ne nécessite pas d’outils spécifiques. Il est important de savoir, que PAS tous les tests d’acceptation doivent être automatisés. L’automatisation de vos tests dépend de multiples aspects tels que : les défis techniques, le délai et le coût.
Des outils recommandés ?
ATDD ne nécessite pas d’outils spécifiques. Il est important de savoir, que PAS tous les tests d’acceptation doivent être automatisés. L’automatisation de vos tests dépend de multiples aspects tels que : les défis techniques, le délai et le coût.
Dans cette section, je vous donnerai juste un aperçu des outils d’automatisation les plus utilisés sur ATDD :
FitNess : Le wiki autonome entièrement intégré et le framework de test d’acceptation
Robot framework : framework générique d’automatisation des tests d’acceptation et de développement piloté par les tests d’acceptation (ATDD)
Calabash : Tests d’acceptation automatisés pour les applications mobiles – Sachez que ce framework peut ne pas supporter la dernière version du système d’exploitation (au-dessus d’Android O )
.