Nous avions suggéré lors de la présentation de l’ATDD automatisé que nous puissions assimiler les principes agiles pour les US de la manière suivante :
Plusieurs sujets posent un vrai problème sur le terrain. Vouloir les ignorer ou rester dogmatique, ce n’est pas la bonne attitude et les problèmes surgissent.
Ce sujet pourrait paraître évident. En réalité, il ne l’est pas. Il y a, en fait, une grande incompréhension sur le terrain, de la définition
Nous voici arrivés en fin de l’étude ATDD pour comprendre ce dont il s’agit et pour montrer son utilisation en agile à l’aide d’un outil. Un
Voyons comment un outil ATDD peut traiter la validation d’un produit (toutes ses fonctionnalités doivent marcher), mais dans le cadre d’un développement agile. Test des
Evidemment le gros avantage d’un outil ATDD est de produire les scénarios de tests, puis les tests, à partir de la modélisation effectuée : les graphiques
Vous devez définir les « données » pour être précis dans votre spécification. Que dire de cette possibilité dans un outil d’ATDD ? Quelles données peut-on gérer ? Dans un
Voyons comment mettre des spécifications de test agiles dans un outil ATDD, tant au niveau les plus fins qu’au niveau des fonctionnalités les plus élevées.
L’ATDD comporte un aspect graphique qui permet d’identifier les éléments d’un système développé en agile et leurs dépendances fonctionnelles (mais sans en donner les règles).
Nous avons vu les différentes vues d’un système. Même en agile, il faut les avoir pour comprendre le système et le tester (PO et testeurs :
