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 uneLire la suite 20 : De l’ATDD pratiquée manuellement à l’ATDD automatisée (2 / 2)
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éLire la suite 19 : De l’ATDD pratiquée manuellement à l’ATDD automatisée (1 / 2)
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 qualifierLire la suite 18 : Conseils d’application de l’ATDD en mode manuel et agile (3 / 3)
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 notre exemple. Intégrer de nouvelles US INVEST qui étendent une fonctionnalité Le sprint 2, par exemple, étend le modèle de la feature F3 (une seule US “s’authentifier de manière simple”,Lire la suite 17 : Conseils d’application de l’ATDD en mode manuel et agile (2 / 3)
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 outil de ticketing et un outil comme support des exigences et des tests (définition et exécution). C’est le cas le plus courant … Illustrons alors par un exemple l’approche deLire la suite 16 : Conseils d’application de l’ATDD en mode manuel et agile (1 / 3)
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 les scénarios de test et, accessoirement, montrera comment les exigences fonctionnelles pourraient s’énoncer en Gherkin comme des RG de haut niveau. Réaliser une table ATDD à partir du langage graphiqueLire la suite 15 : Concevoir rapidement et progressivement les scénarios de tests d’une fonctionnalité avec l’algorithme des tamis successifs (3 / 3)
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, pour être encore plus agile et arriver plus vite à la meilleure efficacité en anticipant les couvertures des alternatives. Successions de transitions entre 2 éléments fonctionnels : comment traiter leursLire la suite 14 : Concevoir rapidement et progressivement les scénarios de tests d’une fonctionnalité avec l’algorithme des tamis successifs (2 / 3)
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 “F” représente un macro-UC ou un UC (Use Case) du produit à un instant T de sa conception. Autrement dit, “F” intègre et synthétise tous les tickets de réalisation agilesLire la suite 13 : Concevoir rapidement et progressivement les scénarios de tests d’une fonctionnalité avec l’algorithme des tamis successifs (1 / 3)
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) pour obtenir les “tests” de l’US. Principe le plus courant de valorisation des données On pourra s’attacher à analyser chaque affirmation de chaque RG. Il existe, là encore, plusieurs solutionsLire la suite 12 : Des scénarios de test d’une US INVEST aux tests
Rappelons que le travail des 3 amigos (Développeur, testeur et Product Owner) va consister en ATDD à : Ce principe nous le reprendrons au niveau des autres éléments du produit et de la prise en compte des tickets agiles de plus grande granularité. Ainsi l’algorithme des tamis successifs, que nous préconisons (en réalité ayant unLire la suite 11 : Concevoir rapidement les scénarios de tests d’une US INVEST avec des “tamis successifs”
La taverne du testeur 