Comment apprendre/enseigner le cornichon pour le concombre

StackOverflow https://stackoverflow.com/questions/1704641

Question

J'aimerais permettre aux analystes commerciaux de pouvoir rédiger toutes leurs spécifications pour les fonctionnalités, les scénarios et les étapes qui sont compatibles avec Cucumber à l'aide de Gherkin.

J'ai lu certaines informations de base sur le site github pour Cucumber et après avoir effectué une recherche rapide sur Google, mais je voulais savoir s'il existait des ressources recommandées pour permettre aux personnes non techniques d'écrire un BDD complet à l'aide de Gherkin (je suppose que c'est la langue préférée pour la création des tests Cucumber).

Merci.

Était-ce utile?

La solution

Ce que je l'ai fait avec les analystes d'affaires dans notre société était de leur enseigner la structure en leur donnant les mots-clés: Vu , Lorsque , Ensuite , pour les scénarios et pour , En et Je veux Caractéristiques.

Alors je leur ai donné un exemple simple et leur ai dit d'écrire leurs propres caractéristiques comme ils pensaient qu'ils devraient être écrits. De façon surprenante la structure était explicite et les caractéristiques qu'ils ont écrit est devenu un grand début.
Le seul gros problème était qu'ils avaient contenu à beaucoup de logique dans chaque étape du scénario. Je résolu qu'en demandant itérativement « pourquoi? » qui, dans la plupart des cas ont révélé la fonctionnalité de base qu'ils étaient après et nous re-écrit les scénarios accordantly.

En leur donnant les directives et les laisser écrire les traits eux-mêmes, ils ont les mains sales et ont été contraints de penser à ce qu'ils ont écrit. Aujourd'hui, ils ont une bien meilleure compréhension et le « pourquoi? » itérations ne sont pas plus que commun.

Ofcourse vous devez avoir les analystes d'affaires et les développeurs de travailler en étroite collaboration et les caractéristiques des analystes écrivent ne devraient agir comme un début. Rappelez-vous que les caractéristiques de concombre sont juste un langage commun entre les analystes et les développeurs. Ils ont encore besoin de se réunir souvent pour être en mesure de parler les uns aux autres:)

Autres conseils

http://cukes.info est une grande ressource pour enseigner aux gens comment les écrire. Ben Mabey a également fait une belle présentation sur le concombre à Mountain West Conférence Ruby 2009.

Après avoir travaillé sur un tout projet agile en utilisant le concombre pour la première fois, je pense que la meilleure façon d'apprendre et de concombre cornichon est de se salir les mains.

Je peux me tromper mais je l'impression de votre question, vous êtes désireux de former vos baccalauréats à écrire Gherkin; alors ils écriront un tas de fonctionnalités et de les remettre aux développeurs.

Ceci est certainement pas la voie à suivre. Il est beaucoup mieux d'avoir les devs de BA et les utilisateurs (si possible) travaillent ensemble pour écrire vos scénarios et les construire comme vous allez. Ensuite, vous tous apprendre ensemble ce qui fonctionne et ce qui ne fonctionne pas.

Nous avons essayé d'avoir un BA écrire ensemble des fonctionnalités et de les remettre. Nous (les devs) a fini par avoir à faire réécritures importantes parce que la mise en œuvre a fini différent de celui prévu à l'origine par la BA. Nous avons également changer la syntaxe des étapes et ne rechercher et remplacer par le fichier entier.

Faites un scénario à la fois, le faire fonctionner puis passer à l'étape suivante. Une approche itérative réduit un gaspillage d'efforts et vous assure tout à comprendre comment vous voulez que l'application se comporter.

En ce qui concerne la façon d'écrire les étapes, il est préférable de commencer par ceux qui viennent avec concombre et les copier et de les adapter pendant que vous travaillez sur votre projet pour votre application particulière. Il n'y a pas de bonne ou mauvaise, il est ce qui fonctionne pour vous. La documentation sur les sites de concombre est généralement bonne et sera une ressource précieuse que vous en apprendre davantage.

Nous enseignons Gherkin (pour SpecFlow) d'une manière similaire, comment MRD a décrit.

Je pense qu'il est très important cependant, que le public connaît l'intention principale de « Spécification par exemple », analyse des besoins agile et BDD, donc nous commençons habituellement à discuter du fond d'abord. Nous montrons également un échantillon scénario Gherkin et expliquer les bases (comme données / Quand / then / Mais et tables).

Que nous prenons une histoire simple exemple (qui est tout à fait familier à tout le monde), comme « ajouter des articles au panier » (avec une certaine orientation, bien sûr) et laissez-les formuler les critères d'acceptation en petits groupes.

Après que chaque équipe montre / explique leurs solutions et nous discutons les bonnes et mauvaises pratiques qui étaient présents. Après la deuxième équipe, vous pouvez voir presque toutes les pratiques les plus importantes (bonnes ou mauvaises) qui apparaissent.

type I également dans la solution conclu, et montre ici d'autres façons de décrire les scénarios (arrière-plan, contour des scénarios, etc.). S'il y a assez de temps, je montre aussi comment automatiser et mettre en œuvre la fonctionnalité imaginée sur cette base. Cette aide également à comprendre quelques règles importantes à suivre, qui rend possible l'automatisation beaucoup plus facile.

Bien que, je ne sais jamais ce qui se passera dès le départ, habituellement cet exercice est la meilleure partie de notre formation BDD.

Le livre RSpec a quelques chapitres il qui sont pertinents pour les analystes d'entreprise:
http://pragprog.com/book/achbd/the-rspec-book

Je pense que la meilleure façon d'apprendre est de commencer à écrire.Le cornichon et le concombre sont faciles à apprendre mais difficiles à maîtriser, il est donc important d'accéder à des exemples pratiques le plus tôt possible.

S’il est important de commencer par rédiger vos premiers scénarios, vous avez également besoin de quelques ressources pour établir de bonnes habitudes et comprendre les pratiques clés.J'ai écrit un livre qui pourrait aider. « Rédiger de bonnes spécifications » est, je l'espère, une bonne façon d'apprendre le cornichon et le concombre.Il couvre les modèles et les anti-modèles ainsi que les techniques clés pour écrire de bons scénarios.:) Si vous avez des questions, vous pouvez toujours me contacter Twitter.

Si vous souhaitez acheter « Writing Great Spécifications », vous pouvez économiser 39 % avec le code promotionnel 39nicieja2 :)

Autres ressources intéressantes :

  • « Spécification par exemple » par Gojko Adzic si vous êtes intéressé par les processus de développement logiciel et les pratiques d'ingénierie de haut niveau.
  • "BDD in Action" par John Smart si cela ne vous dérange pas de lire le code de test en Java.Il s’agit d’une vue complète de bout en bout sur la définition et le test des exigences logicielles.
  • « Développement piloté par le comportement » par Liz Keogh si les tests automatisés ne vous disent rien, mais que vous souhaitez comprendre comment les spécifications avec des exemples affectent vos processus d'analyse commerciale.
  • « Le livre du concombre :Développement axé sur le comportement pour les testeurs et les développeurs » par Matt Wynne et Aslak Hellesøy
  • « Le livre RSpec :Développement axé sur le comportement avec RSpec, Cucumber et Friends » par David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, ​​Dan North
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top