BDD est-il réellement accessible en écriture par des non-programmeurs?

Le développement axé sur le comportement avec sa syntaxe emblématique de scénarios «Given-When-Then» a récemment été très médiatisé pour ses utilisations possibles en tant qu'objet frontière pour l'évaluation des fonctionnalités du logiciel.

Je suis tout à fait d'accord pour dire que Gherkin , ou le script de définition de fonctionnalité que vous préférez, est un DSL lisible par l' entreprise , et fournit déjà une valeur en tant que telle.

Cependant, je ne suis pas d'accord qu'il est accessible en écriture par des non-programmeurs (comme Martin Fowler ).

Quelqu'un a-t-il des comptes rendus de scénarios écrits par des non-programmeurs, puis instrumentés par des développeurs?

S'il y a effectivement un consensus sur le manque d'écriture, verriez-vous un problème avec un outil qui, au lieu de commencer par les scénarios et de les instrumenter, générerait des scénarios lisibles par l'entreprise à partir des tests réels?

Mise à jour: en ce qui concerne l'outil "générateur de scénarios", il ne devinerait bien sûr pas le langage des affaires comme par magie;) Mais, tout comme nous utilisons actuellement des comparateurs d'expressions régulières pour créer des tests dans une approche descendante (sur la dimension d'abstraction), nous pourrions utiliser constructeurs de chaînes pour créer des scénarios dans une approche ascendante.

Un exemple «pour donner une idée seulement»:

Given I am on page ${test.currentPage.name}
And I click on element ${test.currentAction.element}
…

Je l'ai vu. N'a pas bien fini.

Je pense que le concombre est une abstraction lourde (<- lol: D) pour cette raison exacte. Trop difficile pour les non-techniciens d'écrire par eux-mêmes; trop verbeux pour les techniciens.

Les personnes non techniques n'ont tout simplement pas appris à penser comme des programmeurs. C'est notre privilège de comprendre les connaissances abstraites, de les décomposer, de les reconstruire et de pouvoir fuir avec succès l'ambiguïté. C'est pour cela que nous sommes payés.

S'il y a effectivement un consensus sur le manque d'écriture, verriez-vous un problème avec un outil qui, au lieu de commencer par les scénarios et de les instrumenter, générerait des scénarios lisibles par l'entreprise à partir des tests réels?

L'outil lui-même ne pourra pas les générer. L'ordinateur ne sait rien du domaine de l'entreprise. En fin de compte - le programmeur serait responsable de dessiner ce qui doit être généré de toute façon et même alors - ces scénarios seraient probablement trop verbeux / cryptiques pour leurs utilisateurs finaux.

Une partie de la difficulté pour le client à rédiger un document de spécifications est que le client ne sait souvent pas comment traduire les choses qu'il veut dans une langue qui décrit réellement ce dont le client a besoin. Bien que le client puisse dire qu'il souhaite qu'un certain comportement existe dans un système, il ne se préoccupe généralement pas des détails tant qu'il n'a pas vu, utilisé et expérimenté le logiciel fonctionnant d'une manière qui, selon le client, ne correspond pas tout à fait à son Besoins.

Lorsque les clients décrivent un processus métier, ils laissent souvent de côté beaucoup d'informations pertinentes. Souvent, ces informations concernent des éléments d'un processus qui sont généralement compris dans le domaine particulier du client et qui sont donc considérés comme acquis et souvent non relayés au programmeur. À d'autres moments, le client ne sait pas vraiment comment gérer toutes les conditions aux limites d'un système et se tourne vers le programmeur pour obtenir des conseils. Parfois, il s'agit d'un simple cas d'utilisation, le client pensant qu'il veut que quelque chose fonctionne d'une manière, mais changeant ensuite d'avis lorsqu'il devient plus clair que les choses devraient fonctionner différemment.

Ok, donc assez de "relations clients 101 pour les programmeurs". La question est de savoir s'il est toujours utile que le client utilise un DSL lisible par l'entreprise pour définir comment définir une spécification. Je pense qu'avec des conseils, la réponse est un «oui» provisoire, et je dis provisoire parce que la question suivante qui me vient à l'esprit est la suivante: pourquoi voudriez-vous qu'un client crée une DSL alors qu'un programmeur peut en définir plus facilement une qui fournir à un client un langage simple mais riche pour définir comment un système doit fonctionner?

Lorsque vous avez fourni à un client un langage pour décrire comment il aimerait qu'un système fonctionne, vous allez vous retrouver avec des déclarations qui disent quelque chose comme:

"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".

Ce type de déclaration finit par décrire une exigence d'une manière très claire, en fournissant la forme globale que le client souhaite essentiellement que le système prenne, ou une autre façon de voir les choses est que le client décrit ce qu'est le système. Si vous souhaitez que votre client réfléchisse un peu plus aux choses, vous pouvez alors lui demander de décrire les règles auxquelles la fonctionnalité doit obéir en utilisant un certain nombre de déclarations similaires peut-être à:

"Given 'some system state', When 'some action occurs', Then expect 'some result'

Encore une fois, des descriptions très claires, cette fois sur la façon dontle système doit se comporter. Le fait est que cela ne remplacera pas la nécessité pour un développeur de logiciels de remplir tous les espaces vides et de révéler d'autres détails dont le client ne peut être conscient qu'à la périphérie. Bien que le client puisse être `` formé '' par le programmeur pour décrire les fonctionnalités et les comportements dans un format convivial et convivial, le client n'aura pas vraiment les compétences ou les connaissances pour générer des cas de test significatifs, ni pour fournir l'implémentation code. C'était, je pense, le point de l'article de Martin Fowler auquel l'OP a fait référence. Donc, oui, le logiciel lui-même n'est pas accessible en écriture par le client, mais la description du logiciel peut très certainement - et à mon humble avis devrait - être écrite par le client. Pour ce que ça vaut, je n'ai pas lu l'article de Fowler comme disant que le client ne devrait pas

Je pense que nous, les programmeurs, pouvons parfois oublier que nos clients sont généralement très intelligents en termes de compréhension de leurs activités et de leurs processus métier, certainement beaucoup mieux que nous. Quand ils n'ont pas de programmeur pour leur dire comment construire un système logiciel, les clients recourent généralement à d'autres moyens, peut-être moins efficaces, pour résoudre leurs problèmes particuliers de gestion d'entreprise. J'entends par là de simples bases de données (pensez à Access) ou des feuilles de calcul, ou même des livres écrits à la main, et avec des règles et des procédures bien définies pour gérer ces processus. Ce qui manque à de nombreux clients n'est pas un moyen de déterminer comment un système doit fonctionner, mais plutôt comment il doit être construit , et plus important encore, comment décrire efficacement les règles de comportement d'un système aux personnes quin'ont les compétences nécessaires pour construire réellement le système.

S'il y a effectivement un consensus sur le manque d'écriture, verriez-vous un problème avec un outil qui, au lieu de commencer par les scénarios et de les instrumenter, générerait des scénarios lisibles par l'entreprise à partir des tests réels?

Je pense que cela examine la question dans le mauvais sens. Je verrais un gros problème avec un outil qui génère de la documentation à partir de tests si cette documentation était destinée à représenter une spécification de quelque manière que ce soit. Pour tester un scénario, vous devez le comprendre, par conséquent, le scénario doit déjà exister pour que vous puissiez à la fois définir un test pour celui-ci. Si vous décrivez le scénario dans une syntaxe BDD, vous l'avez déjà spécifié et vous ne pouvez donc instrumenter les scénarios qu'après coup. Si d'un autre côté vous aviez un outil qui permettrait au client de décrire un système dans une belle DSL conviviale pour la programmation, et si cet outil pouvait être utilisé pour générer les modèles de code qui seraient utilisés comme suite de tests, alors je '' Je dirais qu'il y aurait une grande valeur dans un tel outil. Cela ne verrait pas le client retirer les programmeurs de l'équation, et cela aiderait à réduire l'effort requis pour répondre aux souhaits du client et générer des exigences codées pour les tests de manière BDD, et pourrait peut-être rendre les souhaits du client plus faciles à comprendre. Ce ne serait cependant pas un substitut à la présence d'un développeur de logiciels expérimenté pour aider le client à séparer les besoins du client de ses désirs.

J'ai vu des développeurs écrire des scénarios; les testeurs écrivent des scénarios et même un propriétaire de produit écrit des scénarios. J'ai également eu des conversations explicitement conçues pour faire ressortir des scénarios - "Étant donné <cet autre contexte>, quand que devrait-il se passer alors?" - et écrit les mots utilisés par l'entreprise.

Les meilleurs résultats que j'ai obtenus ont été d'avoir eu une conversation avec le propriétaire du produit pendant qu'il était au bureau, de les capturer sur un wiki puis de les lui envoyer afin qu'il puisse les corriger et en ajouter d'autres. Il a trouvé un couple que nous avions manqué dans nos conversations. Cela a basculé.

Les pires scénarios que j'ai vus sont ceux que les développeurs se sont écrits sans aucune conversation avec l'entreprise. Je peux le dire, car ils utilisent des termes comme «lorsque j'effectue une recherche» ou «lorsque je soumets le formulaire avec une date d'aujourd'hui + 3». Ce ne sont généralement pas des scénarios très intéressants, beaucoup trop nombreux, un niveau de détail trop faible et donc complètement irréalisables. L'entreprise ne les lit pas non plus.

Mieux vaut se concentrer sur les conversations OMI. J'ai vu quelques équipes le faire maintenant depuis quelques mois avec d'énormes améliorations de la qualité, indépendamment de l'automatisation. Une équipe a réussi à faire fonctionner l'automatisation dans un environnement très difficile quelques semaines plus tard, à la grande joie du testeur! Mais vraiment, tant que l'équipe a des conversations et utilise des scénarios pour en tirer d'autres, je ne pense pas que ce soit important de savoir qui les écrit.

D'après mon expérience, il est préférable de laisser au BA (Business Analyst) le soin d'écrire les GWT ( Given-When-Then ) (expérience avec SpecFlow). Le BA peut traduire les exigences du client dans le GWT et l'entreprise peut le lire. Les clients comprennent les systèmes, mais ils n'ont pas la technologie nécessaire pour rédiger les exigences d'une manière que nous pouvons utiliser.

Idéalement, le BA rédigerait des GWT, je ferais des révisions, le BA réviserait / réviserait la répétition jusqu'à ce que le BA et les entreprises soient confiants dans la couverture. Pratiquement le BA me donnerait une ébauche que je nettoyerais et ferais travailler. L'entreprise haussa les épaules en disant bien sûr, puis se demande pourquoi elle n'a pas couvert certains domaines auxquels personne n'a pensé.