はじめに
前回は、BDDとATDDとSbEの違いについて説明しました。
今回は、BDDで勘違いされやすい部分について説明していきます。
BDDはツールの1つではない
「BDDとは何か？」と聞くと、「振る舞いを用いてテストを自動化するもの」「Given/When/Thenを使って書かれた自動テストのコード」と答えられることが多いです。しかし、これは誤解です。
Seb Roseは自身の書籍『The BDD Books – Discovery（邦訳：The BDD Books – Discovery Japanese Edition）』の中で、以下のように述べています。
私はビジネスチームが参加しない形の「BDD」を実施しているチームをたくさん見てきました。（中略）個人としては基本的にはそれらは BDD にまったく従っていないと考えています。彼らはせいぜい、（中略）高価なテスト自動化プラットフォームとして使用しているだけです。 結果として得られるのは、たいていは遅くてメンテナンスが難しく、組織にごく限られた価値しかもたらさない自動テストスイートです。BDD は協調に関するものです。 BDDツールを使用したり、Given/When/Thenを使用してテストを自動化しても、開発アプローチは少しも BDD にはなりません。
The BDD Books – Discovery
BDDは会話を重視します。特に、ビジネス関係者（非開発チーム）との会話を重視し、共有言語(Shared Languege)の構築を大切にしています。そのため、同書籍では「business」という単語が非常に多く出てきます。
プロセスに組み込まれたBDD
書籍『The BDD Books – Discovery（邦訳：The BDD Books – Discovery Japanese Edition）』の中では、プロセスとしてのBDDについても説明しています。今回はその一部を軽く紹介します。
BDDのプラクティスの概要
この書籍では、BDDのプラクティスを以下の3つのフェーズに分けています。
BDDでよく勘違いされるのは、この3つのうち「自動化(Automation)」のみに注目してしまうことです。
そうではなく、協調作業が行われる「発見(Discovery)」が最も大切です。同書籍では、この順序でプラクティスを採用することが大事であり、「発見(Discovery)」のプラクティスを採用するだけでも大きな効果を得られると語っています。
逆に、「自動化(Automation)」のみを採用してもBDDで期待しているメリットを得られません。
BDDを用いたプロセス
上ではBDDのプラクティスの概要を示しましたが、実際にBDDを用いたプロセスはどのようになるのでしょうか。その中身について描いた図は以下の通りです。
先ほど紹介したBDDのプラクティスと対応づけると以下のようになります。
・発見(Discovery)…#2 要件ワークショップ
・定式化(Formulation)…#3 定式化
・自動化(Automation)…#5 自動化
知らないことを分かっていない分野(unknown unknowns)への挑戦
2002年にラムズフェルド国防長官（当時）が会見時に発した言葉を元にした「ラムズフェルド行列(Rumsfeld matrix)」というものがあります。
BDD、特に「発見(Discovery)」のフェーズでは、ラムズフェルド行列の右下の部分「Unknown unknowns（知らないことを分かっていない）」状態のものを見つけ出し、右上の部分「Known unknowns（知らないことを分かっている）」状態にシフトさせる活動を目指します。
次回予告
今回はBDDに対して「振る舞いを用いてテストを自動化するもの」「Given/When/Thenを使って書かれた自動テストのコード」という考えが誤解であると言うこと、BDDのプラクティスを3つに分けて考えられていることを紹介しました。
次回以降は、それぞれのプラクティスで行う内容を具体例を用いつつ説明していきます。
連載一覧
TDDとBDD/ATDD(1) TDDはテスト手法ではない
TDDとBDD/ATDD(2) 2種類のBDD
TDDとBDD/ATDD(3) BDDとATDDとSbE
TDDとBDD/ATDD(4) ツールとしてのBDDとプロセスに組み込まれたBDD
TDDとBDD/ATDD(5) BDDのプロセスその1「発見(Discovery)」と実例マッピング
TDDとBDD/ATDD(6) BDDのプロセスその2「定式化(Formulation)」とBRIEFの原則
TDDとBDD/ATDD(7) BDDのプロセスその3「自動化(Automation)」
