TDDとBDD/ATDD(6) BDDのプロセスその2「定式化(Formulation)」とBRIEFの原則

はじめに
3. 定式化
- Gherkin記法
シナリオを改善する
おわりに　〜BDD以外でもBRIEFの原則を活用する〜

はじめに

前回は、自動販売機を題材にして、BDDを用いたプロセスの「発見(Discovery)」の部分（2.要件ワークショップ）までを説明しました。

今回は、「3. 定式化(Formulation)」の部分を、BRIEFの原則を交えつつ説明します。

3. 定式化

定式化では、システムの振る舞いの例（実例マッピングでいう具体例の部分）をシナリオの形で文書化します。

例えば、以下のような実例マッピングができた時に、書かれてある具体例「550円を入れて120円のコーラを選ぶとコーラと430円のお釣りが出る」をシナリオの形で文書化します。

例えば、Gherkin記法を用いて以下のように書けます。

Feature: 自動販売機

Scenario: 飲み物を買うとお釣りが出る
    Given 自動販売機がある
    When 500 円硬貨を入れる
    And 50 円硬貨を入れる
    And コンボボックスから 120 円の "コーラ" を選択する
    Then "コーラ" が出てくる
    And 100 円硬貨が 4 枚出てくる
    And 10 円硬貨が 3 枚出てくる

Gherkin記法

Gherkin記法とはGiven/When/Thenなどのいくつかのキーワードを用いて、実行可能な形式で記述する構文方法です。

今回は、以下の6つのキーワードが登場します。

Feature…ソフトウェアのフィーチャーの概要を記述するためのキーワードです。
Scenario…ビジネスルールを表す具体例を記述するためのキーワードです。
Given…システムの初期段階やシナリオの前提を記述するためのキーワードです。
When…実際に行うアクションや操作を記述するためのキーワードです。
Then…期待される結果を記述するためのキーワードです。
And…複数のGiven/When/Thenに値する内容が出てきた時には、この「And」のキーワードで繋げます。

例えば今回書いた内容の場合、以下のような内容を説明していることになります。

自動販売機についてのフィーチャーです。
「飲み物を買うとお釣りが出る」という具体例について記述します。
「自動販売機がある」という前提があります。

以下の操作を行います。
「500 円硬貨を入れます」
「50 円硬貨を入れます」
「コンボボックスから120 円のコーラを選びます」

すると、以下の結果が期待されます。
「コーラが出てきます」
「100 円硬貨が 4 枚出てきます」
「10 円硬貨が 3 枚出てきます」

シナリオを改善する

さて、今回Gherkin記法で書いたような以下のシナリオがあれば全て大丈夫なのでしょうか。

Feature: 自動販売機
  Scenario: 飲み物を買うとお釣りが出る
    Given 自動販売機がある
    When 500 円硬貨を入れる
    And 50 円硬貨を入れる
    And コンボボックスから 120 円の "コーラ" を選択する
    Then "コーラ" が出てくる
    And 100 円硬貨が 4 枚出てくる
    And 10 円硬貨が 3 枚出てくる

このままでも実行可能なテストを作成していくことが可能ですが、もう少しシナリオの改善を考えることができます。

自分一人で考えても良いですが、他の人からフィードバックを得ながら進めるとなお良いでしょう。BDDを用いたプロセスの「#4. レビュー」の部分に該当します。

シナリオを改善する時の参考になるのが、BRIEFの原則です。

BRIEFの原則

BRIEFの原則とは、シナリオをより良くするために考えられた経験則です。それぞれの頭文字5つとBriefという言葉自体の計6つからなります。以下の説明は、「【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則（原文はKeep your scenarios BRIEF）」から引用。

Business language（ビジネス言語）…ビジネスチームのメンバーが明確に理解できる用語を使用すべきです。

Real data（実際のデータ）…具体的な実際のデータを使用すべきです。

Intention revealing（意図を明らかにする）…シナリオのアクターが達成しようとしている意図を明らかにすべきです。達成する方法のメカニズムを説明するのではありません。

Essential（必須）…シナリオの目的は、ルールがどのように振る舞うかを説明することです。この目的に直接関与しない部分は偶発的なものであり、削除すべきです。

Focused（焦点を絞る）…ほとんどのシナリオは、1つのルールの説明に焦点を絞るべきです。

Brief（簡潔である）…ほとんどのシナリオを5行以下に制限することをお勧めします。

【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則

今回のシナリオにBRIEFの原則を適用して改善する

それではBRIEFの原則に当てはめて今回のシナリオを改善していきましょう。

ビジネス言語を用いる(Business language)

今回のシナリオの中で「コンボボックス」という単語は、実際の画面を想定して表現しており、ビジネス言語ではありません。また、コンボボックスでなくチェックボックスなどであっても今回行いたい内容を満たすことができます。そのため、以下のようにシナリオを改善します。

Feature: 自動販売機
  Scenario: 飲み物を買うとお釣りが出る
    Given 自動販売機がある
    When 500 円硬貨を入れる
    And 50 円硬貨を入れる
    And コンボボックスから 120 円の "コーラ" を選択する
    And 120 円の "コーラ" を選択する
    Then "コーラ" が出てくる
    And 100 円硬貨が 4 枚出てくる
    And 10 円硬貨が 3 枚出てくる

意図を明らかにして(Intention revealing)、必須(Essential)の目的のみに焦点を絞って(Focused)記述する

今回のシナリオで示したい目的は、「飲み物を買うと飲み物の値段を引いた金額だけお釣りが出る」ということです。重要なのは金額であり、どんな硬貨が出てくるかは今回のシナリオの意図ではありません。そのため、以下のようにシナリオを改善します。

Feature: 自動販売機
  Scenario: 飲み物を買うとお釣りが出る
  Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る
    Given 自動販売機がある
    When 500 円硬貨を入れる
    And 50 円硬貨を入れる
    When 550 円を入れる
    And 120 円の "コーラ" を選択する
    Then "コーラ" が出てくる
    And 100 円硬貨が 4 枚出てくる
    And 10 円硬貨が 3 枚出てくる 
    And 430 円が出てくる

なお、どんな硬貨が出てくるかを示したい場合は、別のシナリオとして記述を検討すべきでしょう。おそらく、「発見(Discovery)」に立ち戻って、実例マッピングでいう具体例（緑色の付箋）やルール（青色の付箋）を追加することになると思います。

結果として簡潔(Brief)なシナリオになっている

改善した結果、以下のようなシナリオになりました。

Feature: 自動販売機

  Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る
    Given 自動販売機がある
    When 550 円を入れる
    And 120 円の "コーラ" を選択する
    Then "コーラ" が出てくる
    And 430 円が出てくる

これを見ると、シナリオ自体は5行に収まっており、簡潔になっています。