Wie man Gurke für Gurke lernt/lehrt

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

Frage

Ich möchte es den Geschäftsanalysten ermöglichen, mit Gherkin alle ihre Spezifikationen für Funktionen, Szenarien und Schritte gurkenfreundlich zu schreiben.

Ich habe einige der grundlegenden Informationen auf der Github-Website für Cucumber und durch eine schnelle Google-Suche gelesen, wollte aber wissen, ob es empfohlene Ressourcen gibt, um technisch nicht versierte Leute dazu zu bringen, umfassende BDD mit Gherkin zu schreiben (ich gehe davon aus). die bevorzugte Sprache für die Erstellung von Cucumber-Tests).

Danke.

War es hilfreich?

Lösung

Was ich mit den Business-Analysten haben in unserem Unternehmen war sie die Struktur zu lehren, indem sie die Schlüsselwörter geben: Da , Wenn , Dann , und für Szenarien und um / strong auf <>, Als und ich will für Funktionen.

Dann gab ich ihnen ein einfaches Beispiel und sagte ihnen, ihre eigenen Merkmale aufzuschreiben, wie sie dachten, sie geschrieben werden sollen. Erstaunlicherweise war die Struktur selbsterklärend und die Eigenschaften wurden sie schrieb ein guter Start.
Das einzige große Problem war, dass sie zu viel Logik in jedem Szenario Schritt enthalten hatte. Ich löste die durch iterative zu fragen: „Warum?“ die in den meisten Fällen ergab die Kernfunktionalität waren sie nach und wir wieder schrieb die Szenarien accordantly.

Mit dem sie die Richtlinien geben und ließ sie die Funktionen selbst schreiben bekam sie ihre Hände schmutzig und wurden zu denken gezwungen, was sie geschrieben haben. Heute haben sie ein viel besseres Verständnis und die „Warum?“ Wiederholungen sind nicht so häufig mehr.

Natürlich steht Ihnen die Business-Analysten und die Entwickler haben müssen eng zusammenarbeiten und die Features die Analysten nur als Start handeln schreiben soll. Denken Sie daran, dass die Gurke Features sind nur eine gemeinsame Sprache zwischen den Analysten und den Entwicklern. Sie müssen immer noch oft zusammen zu sitzen in der Lage sein, miteinander zu sprechen:)

Andere Tipps

http://cukes.info ist eine großartige Ressource für die Menschen zu lehren, wie sie zu schreiben. Ben Mabey machte auch eine große Präsentation auf Gurke in Mountain West Ruby Conference 2009

auf einem agiles Projekt gerade gearbeitet Nachdem ich denke, zum ersten Mal mit Gurke, dass der beste Weg, Gurke und Gherkin zu lernen, ist Ihre Hände schmutzig zu machen.

Ich kann mich irren, aber ich habe den Eindruck, aus Ihrer Frage sind Sie wollen Ihre BAs trainieren Gherkin zu schreiben; dann werden sie eine Reihe von Funktionen schreiben und sie an Entwickler übergeben.

Dies ist definitiv nicht der Weg zu gehen. Es ist viel besser, BA Devs und Nutzer zu haben (wenn möglich) arbeiten zusammen, um Ihre Szenarien zu schreiben und sie zu bauen, wie Sie gehen. Dann Sie alle gemeinsam lernen, was funktioniert und was nicht.

Wir haben versucht, mit einem BA gesamten Features schreiben und zu übergeben. Wir (die Devs) landeten mit großen Neufassungen zu tun, weil die Umsetzung endete anders als ursprünglich von der BA in Betracht gezogen. Wir hatten auch die Syntax der Schritte zu ändern, und finde, und ersetzen Sie durch die gesamte Datei.

Sie ein Szenario zu einem Zeitpunkt, um es arbeitet dann zum nächsten bewegen. Ein iterativer Ansatz reduziert vergebliche Mühe und stellt sicher, dass Sie alle verstehen, wie Sie die App verhalten wollen.

In Bezug darauf, wie Schritte zu schreiben, ist es am besten, mit denen zu beginnen, die mit Gurke kommen und kopieren und passen sie, wie Sie an Ihrem Projekt arbeiten, um Ihre spezielle Anwendung zu passen. Es gibt kein richtig oder falsch, es ist das, was für Sie arbeitet. Die Dokumentation zu den Gurken-Websites ist in der Regel gut und wird eine wertvolle Ressource sein, wie Sie mehr erfahren.

Wir lehren Gherkin (für SpecFlow) in ähnlicher Weise, wie MRD es beschrieben hat.

Ich denke, es ist aber sehr wichtig ist, dass das Publikum mit dem Hauptziel der „Specification by Example“, agile Anforderungsanalyse und BDD vertraut ist, so dass wir beginnen in der Regel zunächst den Hintergrund der Diskussion. Wir zeigen Ihnen auch eine Probe Gherkin Szenario und erklären die Grundlagen (wie Gegeben / Wann / Then / Aber und Tabellen).

Als wir ein einfaches Beispiel Geschichte nehmen (das ist ganz die jeder kennt), wie „add Artikel in den Warenkorb“ (mit einer gewissen Orientierung, natürlich) und lassen Sie sie die Annahmekriterien in kleinen Gruppen formulieren.

Nach dass jedes Team zeigt / erklärt ihre Lösungen und wir diskutieren die guten und schlechten Praktiken, die anwesend waren. Nach der zweiten Mannschaft, können Sie fast alle der wichtigsten (gut oder schlecht) Praktiken erscheinen sehen.

Ich tippe auch in der geschlossenen Lösung, und hier zeigen alternative Möglichkeiten, um die Szenarien beschreiben (Hintergrund, Szenario Umriss, etc.). Wenn es genug Zeit ist, zeige ich auch, wie zu automatisieren und implementieren die Funktionalität vorgestellt auf dieser Grundlage. Dies auch dazu beitragen, einige wichtige Regeln zu verstehen zu folgen, dass die Automatisierung sehr viel einfacher macht.

Obwohl, ich weiß nie im Voraus, was passieren wird, in der Regel diese Übung ist der beste Teil unseres BDD Trainings.

Das RSpec Buch hat ein paar Kapitel darin, die Business-Analysten relevant sind:
http://pragprog.com/book/achbd/the-rspec-book

Ich denke, der beste Weg zu lernen ist, mit dem Schreiben anzufangen.Gurke und Gurke sind leicht zu erlernen, aber schwer zu meistern, daher ist es wichtig, so schnell wie möglich praktische Beispiele zu finden.

Während es wichtig ist, mit dem Schreiben Ihrer ersten Szenarien zu beginnen, benötigen Sie auch einige Ressourcen, um gute Gewohnheiten zu etablieren und wichtige Praktiken zu verstehen.Ich habe ein Buch geschrieben, das helfen könnte. „Großartige Spezifikationen schreiben“ ist, so hoffe ich, eine gute Möglichkeit, Gurke und Gurke zu lernen.Es behandelt Muster und Antimuster sowie Schlüsseltechniken zum Schreiben großartiger Szenarien.:) Wenn Sie Fragen haben, können Sie mich jederzeit kontaktieren Twitter.

Wenn Sie sich für den Kauf von „Writing Great Specifications“ interessieren, können Sie mit dem Aktionscode 39 % sparen 39nicieja2 :)

Weitere tolle Ressourcen:

  • „Spezifikation anhand von Beispielen“ von Gojko Adzic, wenn Sie sich für Softwareentwicklungsprozesse und hochrangige Ingenieurspraktiken interessieren.
  • „BDD in Action“ von John Smart, wenn es Ihnen nichts ausmacht, Testcode in Java zu lesen.Es handelt sich um eine umfassende End-to-End-Ansicht zum Definieren und Testen von Softwareanforderungen.
  • „Behaviour-Driven Development“ von Liz Keogh, wenn Ihnen automatisierte Tests nicht bekannt vorkommen, Sie aber verstehen möchten, wie sich Spezifikationen anhand von Beispielen auf Ihre Geschäftsanalyseprozesse auswirken.
  • „Das Gurkenbuch:Verhaltensgesteuerte Entwicklung für Tester und Entwickler“ von Matt Wynne und Aslak Hellesøy
  • „Das RSpec-Buch:Verhaltensgesteuerte Entwicklung mit RSpec, Cucumber und Freunden“ von David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, ​​Dan North
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top