BDD（振る舞い駆動開発）とは何ですか？

テクノロジーの世界では、略称BDDまたはニックネーム「Specification by Example」で広く知られている振る舞い駆動開発は、一般的に定義されているのは、「開発者、QA、BA間の継続的な例に基づくコミュニケーションを通じてソフトウェアを開発するための方法論」です。Dan Northという人によって作られたBDDは、開発者がどこから始めるべきか、何をテストしないべきか、どれだけテストするべきか、テストの名称、なぜテストが失敗するのかを明確に説明できないというフラストレーションに対する彼の答えです。テスト駆動開発（TDD）と受け入れテスト駆動開発（ATDD）に由来するこの方法論は、チーム間の機敏性、具体的なコミュニケーション、目標の共有理解をもたらすために使用されます。

本質的には、システムから期待される一連の振る舞いを非常に直接的な例に基づいて説明する共同プロセスであり、最終的には全ての利害関係者がソフトウェアが何をすべきかについて強力な会話を持つことができるようになります。その上、正しく実装されれば、すべてのチームのメンバーが混乱なく提供物の機能を理解し、開発プロセスが始まる前に重要な結果を特定できるようになります。以下の記事では、BDDの詳細と、それを組織のソフトウェア開発管理方法論にどのように実装するかの例を探ります。

BDDの協力的なソフトウェア開発アプローチは、アジャイル手法の短いスプリント、継続的なフィードバック、および改善への反復的アプローチとよく合います。一方を他方に置き換えるのではなく、相互に強化するために調整されます。BDDは、アジャイルプロセスに要件を定義し、シナリオやユーザーインタラクションを記述するための構造化された人間が読み取れる方法を提供し、開発者がソフトウェアが何をすべきかを顧客中心でビジネス志向の実世界の理解を持つことを可能にします。

BDDを考える一つの方法は、アジャイルプロセスを改善するためのプラグインの集まりとしてです。BDDとアジャイルが統合されると、組織はニーズが変化する際に迅速に対応し、本当に必要なときに信頼性の高い動作するソフトウェアを提供し、メンテナンスをサポートし、チームが集中し規律を保つことができます。

BDDは、管理しやすい小さな変更を行うために流れるように連続して行う三つのステップを含むプロセスです。目的は、これらのステップを迅速に進め、勝利を文書化して再現可能にし、各反復でプロセスを強化することです。

アジャイルにおけるBDD

BDDプロセス

• 発見：プロセスは、ユーザーが何をすべきか、必要な機能、優先順位、理解のギャップを説明する「ユーザーストーリー」の開発から始まります。目標は、ニーズの相互理解を得ることです。BDDでは、これらのストーリーには構造があります。
• 形成：次のステップは、ユーザーストーリーからのテイクアウェイを文書化することです。これは、開発者が理解していることをユーザーや他の主要な利害関係者にフィードバックすることを意味します。形成は、フィードバックと改訂のために共有できる実行可能な仕様です。その結果、何を構築するかの共通のビジョンが得られます。
• 自動化：この段階では、ソフトウェア仕様が人間が読み取れる言語でシステムがどのように動作するべきかを説明する実行可能なテストシナリオとしてコードに実装されます。これらのシナリオまたは自動化された例は、ソフトウェアが何をするかを理解しやすくします。

このプロセスは、小さな変更を行い、迅速に反復し、システムに継続的に価値を追加し、フィードバックに対応できるようにすることを強調します。

BDDを通じたTDDとATDDの加速

BDDを理解するためには、まずTDDとATDDの意味を理解する必要があります。その後、BDDがこれら二つの方法論を基本原則を組み合わせて強力なソフトウェア開発プロセスに加速させることを理解する必要があります。

TDDは「コーディング、テスト（単体テストの形式で）、設計（リファクタリングの形式で）の三つの活動が密に結びついているスタイルのプログラミングを指します。」この方法論が使用されると、開発者は特定のユニットのテストセットを定義し、意図的に失敗させ、そのユニットをデプロイし、そのユニットが成功したかどうかを定義する必要があります。BDDの成功の重要な部分として、プログラマーはBDDを学ぶ前にTDDの構造を知り、理解しているべきです。

ATDDは「異なる視点を持つチームメンバー（顧客、開発、テスト）が協力して、対応する機能を実装する前に受け入れテストを書くことを含みます。受け入れテストを生成するために行われる協力的な議論は、顧客（私たちはどの問題を解決しようとしているのか？）、開発（この問題をどのように解決するか）、テスト（何について…）の三つの視点を表す三人の友人と呼ばれることがよくあります。」この方法論内の各テストは「与えられた、いつ、ならば」のスタイルで書かれるべきです。

与えられた[初期コンテキスト]

ならば[いくつかの結果を保証する]

全体的な開発時間を短縮することと、すべての要件レベルでテストによって見つかるバグの数を減らすことに焦点を当てる第一の焦点と、ドメイン固有言語形式によるコミュニケーションの簡素化に焦点を当てる第二の焦点が合わさると、BDDが得られます。ここで、私たちが上記から知っていることを考えてみると、BDDはアプリケーションの振る舞いについて話すために使用される例駆動のコミュニケーション方法論です。BDDの基本原則は、非開発者でも理解できる会話の構造をATDDと組み合わせ、行動の特定に焦点を当てたTDDテストに狙いを定めたものです。

二つの基本原則

要件を達成するために何が起こるべきかの意図、誰、何を説明する平易な言語で書かれたシナリオ。BDD内では、ユーザーストーリーは非常に具体的であり、常に完全な文で名前/機能を含める必要があります。この方法を紹介する際、Dan Northは「開発者は、少なくとも彼らの文書の一部を自動化できることを発見したため、実際の文でテストメソッドを書くことを始めました。さらに、彼らはビジネスドメインの言語でメソッド名を書くと、生成された文書がビジネスユーザー、アナリスト、テスターにとって意味を持つことを発見しました。」と述べました。理想的には「すべき」という言葉を使用し、if-then形式で書くことが求められていますが、BDDは特定のシナリオ形式を要求するものではありません。ただし、多くの専門家、特にDanは、組織が標準化された形式で作業することを提案しています。そうすることで、チームは今後問題なく変更、探求、拡張することができます。

Dan Northのユーザーストーリーフォーマット 

タイトル（要件に関する一行の説明）

受け入れ基準：（シナリオとして提示）

そして[さらに詳細]...

そして[別の結果]...

どのように見えるかをより良く理解できるように、形式のわずかな変化を伴うAPIテストの例を以下に示します。Guru:

特徴：サンプルREST APIテストフレームワークにおけるCRUDメソッドのテスト

与えられたサンプルREST API URLを設定する

シナリオ：POST投稿の例

与えられたPOST投稿APIエンドポイントを設定する

いつHTTPリクエストのヘッダーの内容タイプを「application/JSON」として設定する

そしてリクエストボディを設定する

そしてPOST HTTPリクエストを送信する

ならば有効なHTTPレスポンスコード201を受け取る

そしてレスポンスボディ「POST」は空でない。

シナリオ：GET投稿の例

与えられたGET投稿APIエンドポイント「1」を設定する

いつHTTPリクエストのヘッダーの内容タイプを「application/JSON」として設定する

そしてGET HTTPリクエストを送信する

ならば有効なHTTPレスポンスコード200を受け取る「GET」のために。

そしてレスポンスボディ「GET」は空でない

シナリオ：UPDATE投稿の例

与えられたPUT投稿APIエンドポイント「1」のために設定する

いつ更新リクエストボディを設定する

そしてPUT HTTPリクエストを送信する

ならば有効なHTTPレスポンスコード200を受け取る「PUT」のために。

そしてレスポンスボディ「PUT」は空でない

シナリオ：DELETE投稿の例

与えられたDELETE投稿APIエンドポイント「1」を設定する

いつDELETE HTTPリクエストを送信する

ならば有効なHTTPレスポンスコード200を受け取る「DELETE」のために。

この記事全体を通じて何度も述べてきたように、BDDはチームのすべてのメンバーが理解できる言語の使用に大きく依存しています。ドメイン固有言語（DSL）は、ビジネスパートナーがシナリオを読みやすくするために役立ちます。これは、振る舞いがどのように実装されるかを説明する必要を排除し、プロセス全体の混乱を減少させます。

時間と成果を最大化するために、BDDはテストを自動化するツールによってサポートされています。組織によって定義されたDSLに密接に関連するこれらのツールには、Gherkinを理解し、30の話される言語の仕様を書くことをサポートするCucumberが含まれます。使用中は、これらのツールは一般的な言語仕様を自動的に実行します。

組織での振る舞い駆動開発の開始

あなたの組織がソフトウェア開発管理の旅のどの段階にあるかにかかわらず、アジャイル手法、ウォーターフォール、または他の何かを使用しているかを問わず、この方法論を実装すると、リスク価値よりも高い利益を得ることができます。この方法の使用があなたのニーズに合わない場合は、単にこれまでの方法でテスト要件を書くことに戻ることができます。何も元に戻せません。

まず、開発者がTDD内で作業し、理解していることを確認してください。そうでない場合は、このスタイルのプログラミング内でスキルを開発するためのトレーニング期間を開始する必要があります。開発者が参加したら、BDDの基本を組織全体に実装できます。再度、トレーニング期間が必要です。この間に、開発者、QA、BAチームは、選択したDSLと文書化方法を読み、理解する方法を教えられる必要があります。まずは一つのプロジェクトから始めて、どのように機能するかを確認してください。この方法論は、開発の前に仕様とユーザー、顧客、ドメイン専門家からの継続的なフィードバックが必要であることに注意してください。しかし、成功裏に実装されれば、回帰を減らし、目標コミュニケーションを改善します。

BDDソフトウェアの利点

ソフトウェア開発におけるBDDの広範な採用は、ビジネスニーズを実行可能なソフトウェアコードに翻訳する効果に駆動されています。BDDは以下を提供します：

• コミュニケーションの向上：このアプローチは、すべての利害関係者が通常の言葉でニーズと期待を表現できるようにし、テクノロジーの専門用語やプログラミングコードでは不可能な明快さを提供します。
• 共有理解：すべての利害関係者、非技術ユーザーや意思決定者を含めて、発見、形成、自動化のすべての段階を理解できるため、プロジェクトは明確で共通の理解のもとで開始され、進展します。
• 問題の早期発見：例に基づくコミュニケーションを通じて「左にシフト」して、問題を早期にテスト、発見、修正すると、時間、フラストレーション、コストを削減します。
• テストカバレッジの改善：テストを書くことが非常に容易であるため、より徹底的で関連性のあるテストを行うことができます。
• 再作業の削減：要件に関する明確さと理解が向上することで、ミスが少なくなります。
• 迅速なフィードバックループ：シナリオを書いて自動化することは、各反復でより簡単かつ迅速に行えます。
• ビジネス目標との整合性：非技術的な利害関係者が最初から統合されているため、開発プロセスはビジネス目標と整合します。
• メンテナンスの容易さ：シナリオは開発を指導するだけでなく、自己文書化されたテストケースとなるため、ソフトウェア機能のメンテナンスと更新が容易になります。

BDDアプローチの一般的な落とし穴

ソフトウェア開発におけるアプローチには完璧なものはなく、それはBDDにも当てはまります。採用し使用する際にいくつかの障害や複雑さに直面するかもしれません。これには以下が含まれます：

• 急激な学習曲線：あなたとあなたのチームは、TDDに必要なより多くの概念について知識を持つ必要があります。初心者は、BDDを始める前にTDDの経験があると役立ちます。
• ツール依存：原則、BDDのユーザーストーリーに十分な注意を払わずにツールに焦点をあてる傾向があるかもしれません。コラボレーション、コミュニケーション、相互理解、より良いテストカバレッジに焦点を当て続けてください。
• 概念的な不整合：チームがBDDの根本的な目的を理解せず、技術に関するものだと考えてしまうことがあります。結果として、ツールとテストフレームワークに過剰に依存し、技術的および非技術的な利害関係者間のコミュニケーションを改善する方法を見失うことがあります。

これらの投稿は私自身のものであり、必ずしもBMCの立場、戦略、または意見を表すものではありません。