Intro L’ATDD (Acceptance Test Driven Development) et le BDD (Behaviour Test Driven Development) sont des approches collaboratives, quasiment tout le temps implémenté dans des contextes
Terminons notre conclusion sur l’ATDD manuelle et l’ATDD automatisée : Structuration de la documentation et outillage Normalement une US INVEST donne lieu à une fonctionnalité
En conclusion de nos articles, d’une part sur l’ATDD avec un outil générant les scénarios de test et les tests (scénarios avec les valeurs spécifiques
Considérons maintenant deux exemples où une tâche est touchée par des modifications de spécifications internes (changements d’ergonomie, règles de gestion, … qui auraient dû être
Quels sont les différents cas particuliers à considérer pour bien appliquer l’ATDD manuelle en mode agile ? Voyons quelques réponses à travers la suite de
Envisageons la situation où nous sommes une équipe agile ayant à spécifier et tester un parcours client en démarche agile, et sans outil autre qu’un
Prenons l’exemple de la fonctionnalité F représentée par le schéma ci-dessous : Voyons comment traduire ce graphique dans une table ATDD qui nous fournira systématiquement
L’algorithme des tamis successifs laisse a priori un choix pour les alternatives. En fait, il y a une optimisation possible du nombre de scénarios générés,
Prenons le cas d’une fonctionnalité “F” du produit et essayons de concevoir des scénarios de test qui pourraient représenter leurs critères d’acceptation. En termes clairs
Les scénarios de test sont identifiés grâce à l’algorithme des tamis successifs. Reste à “valoriser” les scénarios de test (critères d’acceptation avec leurs valeurs intermédiaires)
