はじめに（翻訳記事の前提となる知識など）
本記事は自動テスト・テスト自動化Advent Calendar 2021の7日目の記事です。
最近、BDDなどでのテスト自動化を行うにあたり、Discovery（発見）*1→Formulation（定式化）→Automation（自動化）という流れが考えられるようになりました*2。
この中の「定式化」では、後に自動化するテストシナリオの整理を考えます。*3
テストシナリオを作成する際に、ただ単にGherkin記法（Given/When/Thenなどを用いた記法）を利用するだけでは、保守性の低いテストシナリオが作られてしまいます。
そこで今回は、保守性の高い状態でテストシナリオを記述する際に役立つ原則「BRIEFの原則」について書かれた記事「BRIEFの原則を保った状態でシナリオを書いてください（原題：Keep your scenarios BRIEF）」を翻訳して紹介します。*4
具体的なテストシナリオを使った解説は、書籍『Formulation』を読んでください*5。
BRIEFの原則を保った状態でシナリオを書いてください
Gherkinを使用してから何年にもわたって、シナリオを作成するためのアプローチは進化してきました。 Gherkinは自然言語に非常に近いため、学ぶのは非常に簡単ですが、レポートやストーリーを書くのと同じように、うまくやるには練習が必要です。 シナリオを作成する際に気を付ける主な目標は3つあります。
- シナリオは、テストではなくドキュメントとして考えるべきです。
- シナリオは、ビジネスとデリバリーの間のコラボレーションを可能にすべきであり、妨げるものではありません。
- シナリオは、プロダクトを妨害するのではなく、プロダクトの進化をサポートすべきです。
次の6つの原則は、これらの目標をサポートするために連携して機能します。 覚えやすくするために、各原則の頭文字を取ってのBRIEFとなるようにしました。そして「Brief」という単語自体が原則の6番目です。
- Business language
- Real data
- Intention revealing
- Essential
- Focused
- Brief
ビジネス言語（Business language）
シナリオで使用する用語は、ビジネスドメインから引用すべきです。そうしないと、ビジネスの同僚を苦痛なく引き込むことができません。 使用する言語は、ビジネスチームのメンバーが明確に理解できる用語を使用すべきです。
アンチパターン：さまざまなコンテキストでさまざまな意味を持つ用語を使用する。（たとえば、アドレス、ユーザー、日付、アカウントなど）
実際のデータ（Real data）
私たちが執筆した書籍『Discovery』では、例は具体的な実際のデータを使用すべきであると説明しました。 これは、開発プロセスの早い段階で境界条件と基礎となる仮定を明らかにするのに役立ちます。 意図を明らかにするのに役立つ場合は常に、シナリオを作成するときに実際のデータも使用すべきです。
アンチパターン：シナリオが、特定のプロダクションデータの存在に依存している（たとえば、顧客データベースに実在する別のIDを持った顧客に実際のID「1234」を付与して使用する）。
意図を明らかにする（Intention revealing）
シナリオのアクターが達成しようとしている意図を明らかにすべきです。達成する方法のメカニズムを説明するのではありません。 シナリオに意図を明らかにする名前を付けることから始め、次にシナリオのすべての行がメカニズムではなく意図を記述してか確認すべきです。
アンチパターン：シナリオ内にUIの用語を使用する（たとえば、ボタンをクリックする、リンクをたどるなど）。
必須（Essential）
シナリオの目的は、ルールがどのように振る舞うかを説明することです。 この目的に直接関与しない部分は偶発的なものであり、削除すべきです。 それらがシステムにとって重要である場合、他のルールを説明する他のシナリオでカバーされるでしょう。 さらに、期待した振る舞いについての読者の理解を増やさないシナリオは、ドキュメントに記載しません。
アンチパターン：付随的な詳細が多すぎる（たとえば、日付に依存するルールは、ルールの振る舞いが時間によって影響を受けるかもしれない場合を除いて、日付と時刻を使用して説明すべきではありません。）
焦点を絞る（Focused）
ほとんどのシナリオは、1つのルールの説明に焦点を絞るべきです。 実例マッピングのセッションで捉えた具体的な例からシナリオを導き出すと、簡単に実現できます。
アンチパターン：説明しているルールを変更していない場合でもシナリオが失敗し始めるかもしれません（たとえば、ローンの金利を変更すると、利息が支払われる日付を説明したシナリオが失敗します）。
最後に、シナリオはBRIEFの原則に従っていると同時に、簡潔(Brief)である必要があります。
簡潔である（Brief）
ほとんどのシナリオを5行以下に制限することをお勧めします。 これにより、読みやすくなり、意図を捉えるのもはるかに簡単になります。
アンチパターン：プロダクトオーナーが理解できず、価値が見当たらないため、プロダクトオーナーが決して読まない長いシナリオ。
BRIEFの原則の適用については、書籍『Formulation』で詳しく説明しています。
*1:以前に紹介した「実例マッピング」は発見フェーズの具体的なプラクティスの1つになります。 nihonbuson.hatenadiary.jp
*2:個人的には、この考え方はISTQB(JSTQB)の「テスト分析→テスト設計→テスト実装」というテストプロセスの考え方に近いかなと思っています。細かく考えると違いはあるのですが…。どちらにせよ、自動テストを考える前に自動テストの対象となるテストシナリオを整理することが重要だという考え方を主張しているのは良いことだと思います。しかも、「Cucumber」という、「BDDで自動化をどんどんしようぜ！」と言いそうなコミュニティがこういう主張をしていることは非常に価値があります。
*3:なお、仮に「自動化」を行わなかったとしても、「発見」「定式化」をすることは非常に価値があると、オリジナルの記事を書いたSebは自身の著書の中で述べています。私も同じ意見です。
*4:翻訳にあたり、著者本人の許可をもらいました。Thank you, Seb!
*5:現在は英語版しかありませんが、日本語翻訳版も検討しています
