Vous avez raison. BDD n'élimine pas les problèmes d'ambiguïté linguistique - pas du tout. Comme d'autres l'ont souligné, les extraits qui sont traduits doivent être mis en correspondance en les définissant correctement, mais cela ne résout pas non plus le problème d'ambiguïté sous-jacent.
Maintenant, pourquoi BDD vaut-il vraiment la peine malgré le fait de ne pas résoudre ce problème? Il y a quelques raisons et cette liste n'est certainement pas complète.
L'ambiguïté n'est pas résolue
Ce n'est ni une raison pour ni pour le BDD. Mais lorsque vous le comparez à d'autres approches comme les user stories ou les exigences, toutes les approches de développement SW souffrent d'une ambiguïté linguistique car elles commencent toutes d'une manière ou d'une autre avec une formulation en langage naturel.
Techniquement, le problème de l'ambiguïté des langues a été résolu avec des langues artificielles comme le lojban , mais là encore, vos clients et développeurs ne connaîtront probablement pas cette langue.
Langage omniprésent
BDD va de pair avec l'idée d'une langue omniprésente. Être en mesure de spécifier des scénarios avec tous les clients, testeurs et développeurs donne à BDD un avantage sur les autres approches.
Considérez un ingénieur des exigences traditionnel notant toutes les exigences. Une fois que vous, en tant que testeur ou client, obtiendrez ce document de 300 pages rempli d'exigences à examiner, vous aurez beaucoup plus de problèmes urgents que la terminologie qui y était utilisée.
Les histoires d'utilisateurs font un peu mieux à cet égard, car elles incluent également tous les acteurs dans leur création. En termes de langage omniprésent, je ne dirais pas que le BDD ou les histoires d'utilisateurs sont meilleurs - bien qu'ils diffèrent considérablement au point suivant.
Testabilité
Un aspect majeur de BDD est que vos spécifications sont réellement exécutables (via Cucumber ou similaire). Ni les exigences ni les user stories n'offrent cette fonctionnalité. Pour moi personnellement, c'est le principal argument de vente du BDD.
Cela contraste avec les exigences traditionnelles - nous disons aux ingénieurs des exigences depuis des siècles que leurs exigences doivent être testables. Pourtant, chaque projet voit un cas où quelque part en aval, les testeurs se rendent compte qu'ils n'ont aucune idée de comment tester une certaine exigence.
Les user stories, si elles sont bien faites, incluent des testeurs dans leur première phase de création pour s'en assurer. Malheureusement, il s'agit d'un cas de théorie en conflit avec le monde réel, où j'ai vu de nombreuses histoires qu'aucun testeur n'a jamais vues auparavant.
BDD d'autre part vous donne automatiquement un scénario de test exécutable. Il n'y a aucune excuse et aucun moyen de contourner cela (enfin à moins que vous ignoriez complètement les couches d'automatisation et que vous écriviez simplement des scénarios pour la poésie de fantaisie).
Plus généralement, Test First est un principe qui a été très enrichissant à toutes les étapes du développement logiciel et BDD est son application à la couche la plus externe du développement (par rapport à f.ex. TDD au niveau de l'unité).
Sommaire
En résumé, BDD ne vous élève pas des problèmes d'ambiguïté du langage naturel. Cependant, cela vous aide à résoudre ce problème via deux points importants: se concentrer sur un langage omniprésent afin de réduire les ambiguïtés (cela ne les éliminera pas complètement, mais cela aide une tonne!) Et en vous forçant à écrire un exécutable Caractéristiques. Ce dernier point aide à résoudre les problèmes d'ambiguïté, principalement parce que c'est le point où les ambiguïtés commencent à apparaître comme des problèmes autrement.