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
Le vendredi 24 mars a eu lieu le 2ème webinaire de l’année de la taverne. Jérôme Khoualed (expert test et gestion des exigences) et Christophe
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
Le manifeste Agile est un outil simple, visuel et particulièrement puissant. Son objectif est pour moi assez similaire à celui des 7 principes du test:
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
La « valeur » au cœur de la qualité et donc du test en Agile Lorsque l’on parle des tests en Agile on parle généralement de qualité.
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)
Rappelons que le travail des 3 amigos (Développeur, testeur et Product Owner) va consister en ATDD à : Ce principe nous le reprendrons au niveau
Rappelons que la spécification des exigences fonctionnelles concerne le produit tel qu’il est ou tel qu’il sera à l’instant t et donc les artefacts à
