Tous les articles

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é dans le produit, c’est-à-dire “une tâche métier”. Les “corrections de spécification” devraient être traitées comme pour les bugs. Ce sont des tickets à évaluer, attachés au plus bas, c’est-à-dire une tâche existante.  Si vous les considérez comme des US (ce que nous avons dénoncé dans un article précédent, elles ne sont plus INVEST), plusieurs US de nature différente (les INVEST et les corrections) pointent sur la même tâche et sa documentation. Concernant les tickets de “haut

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 en conditions et observations), d’autre part une approche ATDD qui spécifie et teste de manière systématique et rapide les exigences, que pouvons-nous dire ? Le test agile doit rester centré sur le produit à livrer Souvent on pense que le test en agile c’est le test des US, celles-ci étant souvent créées même lorsqu’elles ne sont pas INVEST. La série d’articles, je l’espère, rectifie cette vision. Le nombre de scénarios de test doit être proportionnel aux

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 pris en compte au sein de l’US INVEST initiale). Elles ne peuvent pas être qualifiées d’INVEST … Les US étant déjà  de tailles très faibles, le PO ne peut qualifier ces détails de “fonctionnalité”. Il pourrait dire, par analogie à la physique, que ce sont juste des particules élémentaires d’un atome de la réalisation informatique. Rappel : Nous conseillons donc d’utiliser un ticket adapté (ex: correction d’US). Scénarios de test et de régression pour une US