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


24

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}
…

Il faudra beaucoup de temps avant que les humains soient capables de proposer un langage commun lisible par d'autres humains de manière exacte, même après que les ordinateurs seront déjà capables d'écrire du code pour les ordinateurs.

Ironiquement, JBehave 1 (le premier outil BDD) a commencé par générer des scénarios lisibles par l'entreprise. Nous n'avons pas analysé l'anglais jusqu'à Cucumber. Je pense que JBehave 1 a été utile pour rappeler aux gens qu'ils devaient d'abord en parler ...
Lunivore

Réponses:


20

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.


20
Non technical people just haven't learned to think like programmers. La vérité. Ce même concept a été médité et réinventé à plusieurs reprises au cours des 20 dernières années et il aboutit presque toujours à de mauvais résultats. Les entreprises aiment le concept d'obtenir des logiciels sans avoir à payer ces développeurs de logiciels de sangsue gourmands, mais ils oublient que la partie la plus difficile du développement de logiciels est la plupart du temps de comprendre les règles métier plus profondément et de manière plus complexe que les hommes d'affaires eux-mêmes.
maple_shaft

2
«Les gens non techniques n'ont tout simplement pas appris à penser comme des programmeurs.» Oui, la capacité de décomposer les problèmes et de les exprimer dans des termes logiques atomiques spécifiés est probablement ce qui fait de nous un programmeur / analyste. L'idée que ressembler à l'anglais rend Gherkin utilisable par n'importe qui me semble incroyablement naïve. Merci de l'avoir confirmé :) Computer knows nothing about business domain.Bien sûr. Je n'ai pas précisé mon idée, désolé. J'ajouterai des informations à la question.
MattiSG

8
@maple_shaft: Les 20 dernières années? Essayez les 60 dernières années. Une partie du battage médiatique autour de COBOL était que les gens d'affaires pouvaient l'écrire, éliminant ainsi le besoin de programmeurs. Lorsque cela n'a pas eu lieu, les gens ont trouvé un tas de ce qu'ils appelaient des langages de quatrième génération qui étaient censés faire la même chose.
David Thornley

11

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.


"Pour tester un scénario, vous devez le comprendre, donc le scénario doit déjà exister pour que vous puissiez tous les deux définir un test." Je suis d'accord. Ce que je me demande, c'est si l'application des contraintes linguistiques vaut quelque chose. Je ne prétends pas que nous devrions écrire uniquement des tests; mais je me demande si nous ne devrions pas accepter le fait que la description de l'entreprise sera (et devrait probablement) toujours être une description simple et libre . Par conséquent, nous aurions des descriptions commerciales pures et générerions des scénarios lisibles, permettant aux humains de décider s'ils correspondent; plutôt que de faire semblant, nous utilisons des descendants réels pour tester.
MattiSG

@MattiSG ...whether enforcing language constraints is worth anything. C'est une bonne question. Les descriptions de forme libre sont plus expressives et naturelles pour l'écrivain, mais entraînent des commentaires décousus qui nécessitent une dissection afin de dériver une spécification utile. En définissant des «règles» formelles (également appelées DSL) pour la rédaction des exigences et des spécifications, vous disposez d'un langage commun que le client et le programmeur peuvent comprendre, ce qui limite les malentendus. Si vous obtenez les bonnes descriptions, elles peuvent être utilisées textuellement comme modèle pour vos tests. Ainsi pas besoin d'outils complexes pour "générer" quoi que ce soit.
S.Robins

@MattiSG FWIW, en utilisant un DSL et un BDD est le système que j'utilise moi-même. Les exigences sont définies comme des instructions Entity-Feature-Benefit et sont suivies d'une spécification qui étend les instructions initiales des exigences à l'aide d'instructions AAA (Ie: Given-When-Then) ... essentiellement des instructions de scénario. La difficulté lorsque vous tentez de décoder du texte libre est que sans DSL, vous n'avez pas de moyen facile de définir un algorithme capable de générer des scénarios de collecte significatifs. Mon point était que l'utilisation des tests comme point de départ pour générer des scénarios est un peu à l'envers.
S.Robins

5

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.


+1 La communication est vraiment la clé, et les scénarios doivent vraiment être dans les termes que les gens d'affaires nous, donc conformément à la question des PO, si nous créons une DSL, cela doit vraiment être en mesure d'être plus proche à ce que le client va dire, et non à ce que les programmeurs pensent que le client devrait dire.
S.Robins

0

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é.


Pourriez-vous expliquer ce que GWT signifie pour vous? :)
MattiSG

@MattiSG: devinez que c'est pour Given-When-Then (voir OP).
sleske

@MattiSG - Mise à jour de la bonne capture du message.
SoylentGray
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.