誰が何をする？

誰がGherkinドキュメントを作成し、誰がステップ定義を作成すべきでしょうか？

プロダクトオーナー、ビジネスアナリスト、プログラマー、テスターは、誰がどの責任を負うべきかについて混乱することがよくあります。

答えは、チーム構造、スキル、文化、プロセスなど、いくつかの要因によって異なります。

3人のアミーゴ

3人のアミーゴとは、ユーザーストーリーを明確で徹底したGherkinシナリオに変える会議です。少なくとも3つの声が含まれます。

  • プロダクトオーナー - この人はアプリケーションのスコープに最も関心があります。これには、ユーザーストーリーをフィーチャーのシリーズに変換することが含まれます。テスターがエッジケースを思いつくと、プロダクトオーナーはスコープ内にあるものを決定する責任があります。
  • テスター - この人は多くのシナリオと多くのエッジケースを生成します。アプリケーションはどのように壊れるのでしょうか？これらのフィーチャーの中で、どのようなユーザーストーリーを考慮していないでしょうか？
  • 開発者 - この人はシナリオに多くのステップを追加し、各要件に含まれる詳細を考えます。このアプリケーションはどのように実行されるのでしょうか？舞台裏にはどのような障害や要件があるのでしょうか？

これらの会話は、それぞれのアミーゴが異なる視点から製品を見るため、優れたテストを生み出すことができます。このため、これらの役割すべてが一緒に例を発見するための会話をすることが不可欠です。例のマッピングとイベントストーミングは、例を発見するための優れた共同分析手法です。

最後に、これらの会議を3人に限定したり、プロジェクトの開始時に1回だけ開催したりする理由はありません。フィーチャーを継続的に改善し、アプリケーションについて話し、開発し、テストする方法を最もよく理解するために、全員と協力してください。

Gherkinの記述

まず、シナリオで使用される言語とスタイルがまだ確立されていない場合は、チーム全体でGherkinの記述を共同で行うことをお勧めします。後で、開発者（または自動化を担当する人）とテスター（または品質を担当する人）のペアで効率的に行うことができます。ただし、彼らの成果物はプロダクトオーナー（またはビジネス担当者）によって積極的にレビューされる必要があります。

フィーチャーの記述

Cucumberテストは「フィーチャー」の観点から記述されます。各フィーチャーは1つ以上の「シナリオ」で構成されます。

フィーチャーファイルの例から始めましょう

Feature: Explaining Cucumber
  In order to gain an understanding of the Cucumber testing system
  As a non-programmer
  I want to have an overview of Cucumber that is understandable by non-geeks

  Scenario: A worker seeks an overview of Cucumber
    Given I have a coworker who knows a lot about Cucumber
    When I ask my coworker to give an overview of how Cucumber works
    And I listen to their explanation
    Then I should have a basic understanding of Cucumber

シナリオは、ソフトウェア（またはこの場合は同僚）が何をするかの詳細には踏み込まないことに注意してください。フィーチャーが提供することを意図している人（この場合は「非プログラマー」）の視点に焦点を当てたままです。

すべてのフィーチャーファイルには、一番上に単一のフィーチャーの説明がありますが、任意の数のシナリオを含めることができます。

Feature行はフィーチャーに名前を付けます。これは短いラベルである必要があります。

In order toは、フィーチャーを持つ理由/正当性を示します。一般的に、これはプロジェクトの中核となる目的または「ビジネス価値」の1つと一致する必要があります。

  • 収益を保護する
  • 収益を増やす
  • コストを管理する
  • ブランド価値を高める
  • 製品を注目に値するものにする
  • 顧客により多くの価値を提供する

As aは、フィーチャーによって提供される人/ユーザーの役割を記述します。

I wantは、フィーチャーが何をすることが期待されるかを1文で説明したものです。

したがって、これらの3行は「なぜ」、「誰が」、「何を」をカバーします。次に、ドキュメントはシナリオを使用して「どのように」に入ります。

シナリオ

フィーチャーには任意の数のシナリオを含めることができます。

1つのフィーチャーに非常に多くのシナリオがある場合は、実際には複数のフィーチャーを記述している可能性があります。その場合は、ドキュメントを個別のフィーチャー定義に分割することをお勧めします（ここでの「非常に多く」の定義は主観的であり、フィーチャーを分割する時期を決定するのはあなた次第です）。

最初の行は、シナリオがカバーすることを意図した内容の簡単な説明を提供します。シナリオを1文（および長文ではない文）で説明できない場合は、おそらくカバーしすぎようとしているため、複数のシナリオに分割する必要があります。

その後に、「ステップ」の組み合わせ（キーワードGiven、When、およびThenで始まる行（通常はこの順序）が続きます）。

同じキーワードを使用する多くの行を含めることができます（例：Given there is somethingの後にGiven I have another thing）。可読性を高めるために、キーワードAndまたはButを代用できます（例：Given there is somethingの後にAnd I have another thing）。

一般に、Givenステップの行は1つのことのみを記述する必要があります。ステップの途中に「and」のような単語がある場合は、おそらく複数のステップを記述しているため、複数のステップに分割する必要があります。

例

	When I fill in the "Name" field and the "Address" field

こうなります

	When I fill in the "Name" field
	And I fill in the "Address" field

Cucumberフィーチャーは一貫性によって最も効果的に提供されます。同じことを別の方法で言わないでください。毎回同じように言ってください。

例

	Given I am logged in

そして

	Given I have logged in to the site

は同じ意味を持つため、ログインする必要があるすべてのシナリオで1つを選択して同じ行を使用することをお勧めします。

このドキュメントを改善するためにご協力ください。このページを編集。