Point Clés
Cet article constitue une introduction aux méthodes de spécification par le biais des tests, notamment la BDD, la TDD et l’ATDD.
LES TESTS COMME OUTIL DE SPÉCIFICATION, POURQUOI?
Dans une approche classique, l’analyse d’un besoin est traitée par des acteurs différents (MOA, développeur, testeur, ergonome…) qui travaillent séparément.
La démarche Agile Testing et son outillage proposent avant tout de traiter l’analyse de manière coopérative et progressive dans un langage naturel et exploitable par tous.
Des équipes pluridisciplinaires, sans cloisonnement, et impliquées pourront améliorer la qualité des tests grâce à des outils et méthodes tels que ATDD, BDD, TDD, etc.
Le degré de divergence est variable dans une équipe, mais existe probablement sur tout projet important et complexe.
Cette divergence est aggravée par des modes de fonctionnement qui favorisent un échange de documents plutôt qu’une réelle communication et peut faire perdre de vue la satisfaction de l’utilisateur final.
Vocabulaire
BDD: Behavioral-Driven Development
TDD: Test-Driven Development
ATDD: Acceptance Test-Driven Development
Nous proposons d’augmenter les échanges et favoriser la communication entre les acteurs clés du produit (on parle parfois des “3 amigos :)”) :
- Un Business Analyst
- Un Dev
- Un Quality Analyst
COMMENT SPECIFIER PAR LES TESTS
LES TESTS COMME OUTILS DE COMMUNICATION
- Le test présente les avantages d’être précis, non ambigu, déterministe, reproductible et exploitable directement.
- Spécifier par les tests revient à spécifier par l’exemple.
- La conception de cas de tests n’est plus limitée à une personne en particulier, chaque membre peut soumettre à l’équipe de nouveaux cas.
LA SPÉCIFICATION PAR LES TESTS
Source : Specification by Example par Gojko Adzic
Deriving scope from goals
- L’alignement des visions améliore la définition d’une solution qui répondra aux objectifs des utilisateurs. L’équipe travaille avec les utilisateurs pour déterminer la solution. Les utilisateurs se concentrent sur la valeur qu’ils attendent en sortie.
Specifying collaboratively
- La spécification en collaboration nous permet d’exploiter les connaissances et l’expérience de toute l’équipe. Il crée également une propriété collective des spécifications, ce qui rend chacun plus engagé dans le processus de livraison.
Specification with examples
- Au lieu d’attendre que les spécifications soient exprimées précisément pour la première fois dans un langage de programmation pendant la mise en œuvre, les équipes illustrent les spécifications en utilisant des exemples. Cela garantit que toutes les personnes impliquées ont une compréhension partagée de ce qui doit être livré, en évitant les mauvaises interprétations.
Executable specification
- Au début de la mise en œuvre de la fonctionnalité, le test basé sur cette spécification échoue car il n’est pas encore automatisé et le code n’est pas encore produit. Une fois le test implémenté, la spécification devient exécutable.
Living documentation
- Toutes les spécifications pour toutes les fonctionnalités mises en œuvre sont validées fréquemment, grâce à un processus automatisé de construction. Cela permet d’éviter les problèmes de régression fonctionnelle tout en garantissant que les spécifications restent à jour.
UNE SPÉCIFICATION CLAIRE SOUS FORME D’EXEMPLE
- Langage naturel compréhensible par tous
- Utilisation du DSL : GIVEN – WHEN – THEN
- Permet l’automatisation avec des outils (Cucumber)
- Règles claires et sans ambiguïté.
- Focus sur le fonctionnel et non la solution.
- Verrouillage de la fonctionnalité en amont.
Exemple de User Story : En tant qu’utilisateur privé, je souhaite activer mon compte en ligne afin d’accéder aux services du portail Cortex Exemple de test d’acceptance:
L’APPROCHE ACCEPTANCE TEST-DRIVEN DEVELOPMENT (ATDD)
L’ATDD, ou Acceptance Test-Driven Development, fonctionne en rédigeant des tests d’acceptation avant de coder.
Les exemples sont rédigés avant le début des développements (du Sprint) et font partie de la définition du Done. Ils aident à la compréhension du besoin et assurent aux développeurs le respect des critères d’acceptance.
Voici comment cela marche :
- Discussion en équipe : Les développeurs, testeurs et responsables métier définissent ensemble les critères d’acceptation pour les fonctionnalités à créer.
- Rédaction des tests : On écrit des tests d’acceptation dans un langage clair pour tous. Ces tests servent de spécifications exécutables.
- Écriture du code : Les développeurs créent le code nécessaire pour réussir les tests d’acceptation.
- Exécution des tests automatiques : Les tests d’acceptation sont automatiquement lancés chaque fois que des modifications sont apportées au code. Cela garantit que le code respecte toujours les critères d’acceptation.
- Réflexion et amélioration continue : L’équipe se réunit régulièrement pour discuter des résultats des tests, résoudre les problèmes et s’assurer que les critères d’acceptation restent pertinents.
En bref, l’ATDD encourage la collaboration en assurant une compréhension commune des besoins. Les tests d’acceptation sont des spécifications vivantes et automatisées, assurant une validation continue du code par rapport aux attentes métier. Cela conduit à un développement de meilleure qualité et à une réduction des erreurs de compréhension.
Exemple de cycle ATDD
0 commentaires