ビジネスアナリストが、Gherkinを使用して、キュウリに優しい機能、シナリオ、および手順のすべての仕様を記述できるようにしたいと思います。
キュウリのgithubサイトで基本的な情報をいくつか読んだり、Googleで簡単に検索したりしましたが、技術者以外の人がGherkinを使用して包括的なBDDを作成できるようにするための推奨リソースがあるかどうかを知りたいと思いました(で作成されるキュウリテストの優先言語)。
ありがとう。
ビジネスアナリストが、Gherkinを使用して、キュウリに優しい機能、シナリオ、および手順のすべての仕様を記述できるようにしたいと思います。
キュウリのgithubサイトで基本的な情報をいくつか読んだり、Googleで簡単に検索したりしましたが、技術者以外の人がGherkinを使用して包括的なBDDを作成できるようにするための推奨リソースがあるかどうかを知りたいと思いました(で作成されるキュウリテストの優先言語)。
ありがとう。
私が会社のビジネスアナリストと一緒にしたことは、キーワードを与えて構造を教えることでした。
それから私は彼らに簡単な例を挙げ、彼らが書くべきだと思ったので彼ら自身の特徴を書き留めるように彼らに言いました。驚くべきことに、構造は自明であり、彼らが書いた機能は素晴らしいスタートとなりました。
唯一の大きな問題は、各シナリオのステップで多くのロジックが含まれていたことでした。「なぜ?」と繰り返し尋ねることでそれを解決しました。ほとんどの場合、それは彼らが求めていたコア機能を明らかにし、それに応じてシナリオを書き直しました。
彼らにガイドラインを与え、彼らに彼ら自身に特徴を書かせることによって、彼らは彼らの手を汚し、彼らが書いたものについて考えることを余儀なくされました。今日、彼らははるかによく理解し、「なぜ?」反復はもはやそれほど一般的ではありません。
もちろん、ビジネスアナリストと開発者が緊密に連携する必要があり、アナリストが作成する機能は出発点としてのみ機能する必要があります。Cucumberの機能は、アナリストと開発者の間の共通言語にすぎないことを忘れないでください。彼らはまだお互いに話すことができるように頻繁に一緒に座る必要があります:)
http://cukes.infoは、人々にそれらの書き方を教えるための優れたリソースです。Ben Mabeyは、Mountain West RubyConference2009でキュウリについても素晴らしいプレゼンテーションを行いました。
きゅうりを使ったアジャイルプロジェクトに初めて取り組んだばかりですが、きゅうりとガーキンを学ぶ最良の方法は手を汚すことだと思います。
私は間違っているかもしれませんが、あなたがガーキンを書くためにあなたのBAを訓練したいと思っているあなたの質問から印象を受けます。次に、一連の機能を作成して開発者に渡します。
これは間違いなく行く方法ではありません。BAの開発者とユーザー(可能であれば)が協力してシナリオを作成し、進行中にそれらを構築することをお勧めします。次に、何が機能し、何が機能しないかを一緒に学びます。
BAに機能全体を書き込んでもらい、それらを引き渡してみました。私たち(開発者)は、実装がBAによって当初想定されていたものとは異なる結果になったため、大幅な書き換えを行う必要がありました。また、ステップの構文を変更し、ファイル全体を検索して置き換える必要がありました。
一度に1つのシナリオを実行し、それを機能させてから、次のシナリオに進みます。反復的なアプローチにより、無駄な労力が軽減され、アプリの動作をすべての人が確実に理解できるようになります。
ステップの書き方に関しては、Cucumberに付属しているものから始めて、特定のアプリケーションに合うようにプロジェクトで作業するときに、それらをコピーして適応させるのが最善です。正しいことも悪いこともありません、それはあなたのために働くものです。キュウリのサイトのドキュメントは一般的に優れており、詳細を学ぶにつれて貴重なリソースになります。
私たちは、mrDがそれをどのように説明したかと同様の方法で、Gherkin(SpecFlow用)を教えています。
ただし、聴衆が「例による仕様」の主な意図、アジャイル要件分析、およびBDDに精通していることは非常に重要だと思います。そのため、通常、最初に背景について説明します。また、サンプルのGherkinシナリオを示し、非常に基本的なもの(Given / When / Then / Butやテーブルなど)について説明します。
「ショッピングカートにアイテムを追加する」(もちろん、ある程度の方向性を持って)のような簡単な例の話(誰もがよく知っている)を取り上げて、小グループで受け入れ基準を策定させます。
その後、すべてのチームがソリューションを示し/説明し、存在した良いプラクティスと悪いプラクティスについて話し合います。2番目のチームの後、最も重要な(良いまたは悪い)プラクティスのほとんどすべてが表示されます。
また、結論として得られたソリューションを入力し、シナリオを説明する別の方法(背景、シナリオの概要など)をここに示します。十分な時間があれば、それに基づいて想像された機能を自動化して実装する方法も示します。これは、従うべきいくつかの重要なルールを理解するのにも役立ち、自動化がはるかに簡単になります。
何が起こるかを前もって知ることはできませんが、通常、この演習はBDDトレーニングの最良の部分です。
RSpecブックには、ビジネスアナリストに関連するいくつかの章があります。http:
//pragprog.com/book/achbd/the-rspec-book
Gherkinを学ぶ最良の方法は、最初にBehatドキュメントを読むことです:http://behat.readthedocs.org
次に、キュウリのサイトから公式文書を読みます:https ://cucumber.io/docs/reference
また、Guru99の記事を読んで、最初のキュウリのスクリプトを書くこともできます:http: //www.guru99.com/your-first-cucumber-script.html