Loading article…
ビヘイビア駆動開発（BDD）は、複雑な問題の解決策を見つけることに利害関係のあるビジネスおよびIT専門家間のコラボレーションを中心としたアジャイルソフトウェア開発手法です。その主な目的は、問題に対する共通理解を達成することです。[ 1 ]
BDDでは、動作と期待される結果を表現できる自然言語の構成要素（例えば、英語のような文）を使用したドメイン固有言語（DSL）を使用します。 [ 2 ]
BDDは、ソフトウェアプロジェクトにおいて、開発者、品質保証担当者、顧客担当者間のコラボレーションを促進します。[ 3 ] [ 4 ]また、チームが会話や具体的な例を用いて、アプリケーションの動作に関する共通理解を形式化することを促します。[ 5 ] BDDは、特に問題領域が複雑な場合に効果的な手法と考えられています。[ 6 ]
BDD に関するよくある誤解は、テスト駆動開発(TDD)の改良版であるというものです。BDD は元々 TDD の手法から派生したものですが、[ 7 ] BDD の唯一の目的は、問題領域に対する共通理解を得て、それを実際のデータを使用してビジネス言語で記述する方法を見つけることであり、同時に意図を明らかにし、本質的で、焦点を絞った (BRIEF) ことです。[ 8 ] BDD は、TDD の手法とドメイン駆動設計およびオブジェクト指向分析と設計の考え方を組み合わせて、ソフトウェア開発チームと管理チームにソフトウェア開発で協力するための共有ツールと共有プロセスを提供します。[ 3 ] [ 9 ]
大まかに言うと、BDDは、ビジネス上の利益と技術的な洞察の両方によってソフトウェア開発をどのように管理すべきかという考え方です。その実践には、専用ツールの使用が含まれます。[ 10 ] BDD専用のツールの中には、TDDにも使用できるものがあります。これらのツールは、ユビキタス言語を自動化します。
BDDは、DSLで構造化された自然言語のステートメントを実行可能なテストに変換するプロセスです。その結果、実行可能な仕様が作成され、最終的に「生きたドキュメント」、つまりソフトウェア開発を推進する最初の受け入れテスト（受け入れテスト駆動開発）となる要件が形成されます。
BDDは以下に焦点を当てています。
この時点から、多くの人々が長年にわたってBDDフレームワークを開発し、最終的にはソフトウェアプロジェクトにおける開発者、QA、非技術系またはビジネス系の参加者間のコミュニケーションとコラボレーションのフレームワークとして位置づけました。[ 12 ]
BDDでは、ソフトウェアテストは望ましい動作に基づいて命名されるべきであると提唱されています。[ 10 ] [ 9 ]アジャイルソフトウェア開発から借用すると、この場合の「望ましい動作」は、ビジネスによって設定された要件、つまり、構築中のソフトウェアユニットを委託したエンティティにとってビジネス価値のある望ましい動作で構成されます。 [ 10 ] BDDの実践では、これはBDDが「外部から内部へ」の活動であると呼ばれています。
TDDは、ソフトウェアの高レベル要件、低レベル技術詳細、あるいはその中間といった観点からテストを区別しません。したがって、BDDはTDDの進化形であり、より具体的な選択を行うものだと考えることができます。
BDDのもう一つの提案は、望ましい動作をどのように指定するかに関するものです。BDDでは、オブジェクト指向分析設計分野のユーザーストーリー仕様から借用した、動作仕様のための半形式的なフォーマットの使用を推奨しています。このフォーマットのシナリオ的な側面は、ドメイン固有言語を用いたソフトウェアの動作仕様へのホーア論理の応用と見なすことができます。
BDDでは、ビジネスアナリストとソフトウェア開発者がこの分野で協力し、それぞれ明示的に文書化されたユーザーストーリーの観点から動作を規定すべきであると提唱しています。各ユーザーストーリーは、ある程度、次の構造に従う必要があります。[ 10 ]
BDD ではこの情報のフォーマット方法は規定されていませんが、上記の要素を含む比較的シンプルで標準化されたフォーマットをチームが決定すべきであると示唆しています。[ 10 ]また、シナリオは命令型ではなく宣言型で記述すべきであるとも示唆しています。つまり、ビジネス言語で、インタラクションが行われる UI の要素には言及せずに記述すべきです。[ 13 ]このフォーマットはCucumberではGherkin 言語と呼ばれています。
BDD は、ドメイン駆動設計からユビキタス言語の概念を借用しています。[ 10 ] [ 9 ]ユビキタス言語とは、ソフトウェア開発チームのすべてのメンバー(ソフトウェア開発者と非技術担当者の両方) が共有する (半) 形式言語です。[ 14 ]この言語は、対象となるソフトウェアのドメインについて議論するための共通手段として、すべてのチームメンバーによって使用され、開発されます。[ 14 ]このように、BDD はソフトウェアプロジェクトにおけるさまざまな役割間のコミュニケーションの手段となります。[ 10 ]
ソフトウェア開発における一般的なリスクの一つに、開発者とビジネス関係者間のコミュニケーションの断絶があります。[ 15 ] BDD は、望ましい動作の仕様をプロジェクト チーム メンバーの共通言語として使用します。これが、BDD が動作仕様に半形式言語を要求する理由です。ある程度の形式性は、共通言語であるための要件です。[ 10 ]さらに、このような共通言語を持つことで、仕様のドメイン モデルが作成され、仕様について形式的に推論できるようになります。[ 16 ]このモデルは、利用可能なさまざまな BDD サポート ソフトウェア ツールの基盤でもあります。
上記の例では、開発中のソフトウェアシステムのユーザーストーリーを説明しています。このユーザーストーリーでは、ステークホルダー、ビジネス効果、ビジネス価値を特定しています。また、前提条件、トリガー、期待される結果を含む複数のシナリオも記述しています。これらの各要素は、言語のより形式的な部分（例えば、 「Given」という用語はキーワードとみなすことができます）によって正確に識別されるため、ユビキタス言語の形式的な部分を理解するツールによって何らかの方法で処理される可能性があります。
ほとんどのBDDアプリケーションはテキストベースのDSLと仕様アプローチを使用しています。しかし、統合シナリオのグラフィカルモデリングも、例えばテスト目的で実際にうまく適用されています。[ 17 ]
TDDと同様に、BDDでも専用ツールを使用する場合があります。
BDDはTDDと同様にテストコードだけでなく、より人間が読みやすい言語で動作を記述したドキュメントも必要とします。そのため、テストの実行、記述の読み取りと解析、テストコードの読み取り、そして対応するテスト実装の特定という2段階のプロセスが必要となります。このプロセスは開発者にとってBDDをより手間のかかるものにしています。しかし、BDDの支持者は、人間が読みやすい性質を持つため、これらのドキュメントは比較的非技術的な読者にも価値があり、要件（「機能」）を記述するためのコミュニケーション手段として役立つと主張しています。
原則として、BDDサポートツールは、TDDをサポートするツールと同様に、ソフトウェアのテストフレームワークです。ただし、TDDツールはテストの仕様記述において比較的自由な形式を採用しているのに対し、BDDツールはユビキタス言語の定義に密接に結びついています。
ユビキタス言語により、ビジネスアナリストは、開発者にも理解できる方法で動作要件を文書化できます。BDD サポートツールの原則は、これらの要件ドキュメントをテストの集合として直接実行できるようにすることです。仕様の実行を可能にする技術ツールに関連する理由でこれが実現できない場合は、動作要件の記述スタイルを変更するか、ツールを変更する必要があります。[ 18 ]動作要件の具体的な実装はツールによって異なりますが、アジャイルプラクティスでは、次の一般的なプロセスが考案されています。
ビヘイビア駆動開発の別のサブカテゴリとして、ユーザーストーリーではなく仕様を入力言語として使用するツールがあります。仕様ツールは、テストシナリオの入力形式としてユーザーストーリーを使用するのではなく、テスト対象のユニットの機能仕様を使用します。これらの仕様は、ユーザーストーリーよりも技術的な性質が強く、ビジネス担当者とのコミュニケーションにはユーザーストーリーよりも不便な場合が多いです。[ 10 ] [ 19 ]スタックの仕様の例は次のようになります。
仕様:スタック 新しいスタックが作成される と、それは空になります 要素がスタックに追加される と、その要素はスタックの最上位になります。 スタックにN個の要素があり 、要素Eがスタックの最上位にある 場合、ポップ操作はEを返し 、スタックの新しいサイズはN-1になります。
このような仕様は、テスト対象コンポーネントの動作を正確に規定するかもしれませんが、ビジネスユーザーにとってはあまり意味がありません。そのため、仕様ベースのテストは、BDD の実践においてストーリーベースのテストの補完として捉えられ、より低いレベルで動作します。仕様テストは、自由形式のユニットテストの代替としてよく見られます。[ 19 ]
「3人の仲間」、または「仕様ワークショップ」と呼ばれる会議は、プロダクトオーナーが、QAや開発チームなどのさまざまなステークホルダーと、仕様の形で要件を例を挙げて話し合う会議です。この議論の主な目的は、会話を促し、不足している仕様を特定することです。この議論はまた、QA、開発チーム、プロダクトオーナーが集まり、互いの視点を聞き、要件を充実させ、正しい製品を構築しているかどうかを確認するためのプラットフォームを提供します。[ 20 ]
3人の仲間とは：