Question

L'une des affirmations de développement de style BDD est qu'il comble l'écart entre le propriétaire du produit et les développeurs: le propriétaire du produit écrit une histoire, qui peut être convertie dans un "cadre" de test automatisé équivalent qui devrait éventuellement passer.

Ce que j'aimerais entendre, c'est comment continuer à combler l'écart après cela: une fois qu'il y a des tests automatisés en place, comment aidez-vous le propriétaire du produit à les examiner? Ou est-il suffisant pour que le propriétaire du produit sache que le test passe, sans regarder le code de test lui-même?

En bref, à quel point le propriétaire du produit devrait-il être intime avec les tests réels mis en œuvre et comment le maintenez-vous impliqué de manière productive dans les tests au-delà de l'écriture initiale de l'histoire?

La raison de cette question est le double. Premièrement, entre le journal et les détails de la mise en œuvre, certaines hypothèses peuvent se faufiler et avoir l'auteur de la revue de l'histoire, le test peut être inestimable. D'un autre côté, l'implémentation introduit également un peu de bruit et nécessite que le PO devienne assez technique (lire le code, exécuter des tests). La mise en œuvre du test est-elle un "détail du développeur", ou est-il juste de demander au PO de devenir un peu développeur dans ce domaine?

Ensuite, dans la plupart des cas, le PO peut réellement valider le test sans le test automatisé, en utilisant simplement l'application. Cependant, certaines histoires sont "sans tête" et ne peuvent être vérifiées que via le code, donc à moins que le PO ne sache comment lire et exécuter des tests, il ne pourra jamais dire qu'il a vérifié l'histoire complète.

Pas de solution correcte

Licencié sous: CC-BY-SA avec attribution
scroll top