振る舞い駆動開発(BDD)は、Cucumberがサポートするために構築されたソフトウェア開発プロセスです。

BDDは、Cucumberを使用することだけにとどまりません。

BDDとは?

BDDは、以下の方法でビジネス関係者と技術関係者間のギャップを埋めるソフトウェアチームの作業方法です。

  • 役割を超えた協調を促進し、解決すべき問題に対する共通の理解を構築する
  • 迅速で小規模な反復作業を行い、フィードバックと価値の流れを増加させる
  • システムの動作に対して自動的にチェックされるシステムドキュメントを作成する

これは、システムの動作方法を示す具体的な現実世界の例を中心とした協調作業に焦点を当てることで実現します。これらの例を使用して、継続的な協調のプロセスにおいて、概念から実装までを導きます。

BDDとアジャイル

チームは、既に何らかのアジャイル手法を使用しており、ユーザーストーリーのような小さな価値の増分で作業を計画していると仮定します。BDDは既存のアジャイルプロセスに取って代わるものではなく、それを強化するものです。

BDDを、既存のプロセスに対するプラグインのセットと考えてください。これにより、チームはアジャイルの約束、つまり組織の進化するニーズを満たす動作するソフトウェアのタイムリーで信頼性の高いリリースを、ある程度のメンテナンスの努力と規律を必要としながら実現する能力を向上させることができます。

迅速な反復

ユーザーからのフィードバックに迅速に対応し、ニーズを満たすために必要な最小限の作業を行うことを望んでいると仮定します。

BDDは、迅速な反復作業を促進し、ユーザーの問題を開発プロセスをできるだけ迅速に通過できる小さなピースに継続的に分割します。

3つのプラクティス

基本的に、日々のBDD活動は3段階の反復プロセスです。

  1. まず、システムへの小さな今後の変更(ユーザーストーリー)を取り上げ、新しい機能の具体的な例について話し合い、何を行うべきかの詳細を調査、発見、合意します。
  2. 次に、それらの例を自動化できる方法で文書化し、合意を確認します。
  3. 最後に、文書化された各例によって記述された動作を実装します。コードの開発をガイドするための自動化されたテストから開始します。

アイデアは、各変更を小さくして迅速に反復し、より多くの情報が必要になるたびにレベルを上げていくことです。新しい例を自動化して実装するたびに、システムに何か価値のあるものを追加し、フィードバックに対応する準備が整います。

これらのプラクティスを発見定式化自動化と呼びます。

diagram of how the practices fit together
発見、定式化、自動化

時間の経過とともに、文書化された例は、チームがシステムへの変更を自信を持って迅速に継続できるようにする資産になります。コードはドキュメントを反映し、ドキュメントはチームの問題領域に関する共有された理解を反映します。この共有された理解は常に進化しています。

これらの各プラクティスについて学ぶことはたくさんあります。以下でそれぞれを要約します。

発見:何ができるか

ソフトウェアシステムを構築する上で最も難しい部分は、正確に何を構築するかを決定することです。

フレッド・ブルックス、「ミシック・マン・マンマンス」より

BDDチームはドキュメントと自動化されたテストを作成しますが、それらを優れた副産物と考えることができます。真の目標は価値のある動作するソフトウェアであり、そこに到達する最速の方法は、そのソフトウェアの想像と提供に関わっている人々の間の会話を通してです。

BDDは、チームが適切なタイミングで適切な会話をできるようにすることで、会議に費やす時間を最小限に抑え、生成する価値のあるコードの量を最大限に増やすのに役立ちます。

ユーザーの視点からシステムの現実世界の例を中心とした、ディスカバリーワークショップと呼ばれる構造化された会話を利用します。これらの会話は、ユーザーのニーズ、システムが機能する方法を規定するルール、そして行う必要がある作業の範囲に関するチームの共有された理解を高めます。

また、何をするかを知る前に、より多くの情報が必要な、私たちの理解のギャップを明らかにすることもあります。

ディスカバリーセッションの精査により、ユーザーストーリーの範囲から延期できる低優先度の機能が明らかになり、チームがより小さな増分での作業を可能にし、フローを改善します。

BDDが初めての場合は、発見から始めるのが最適です。発見をマスターするまでは、他の2つのプラクティスから大きな喜びは得られません。

定式化:何がすべきか

ディスカバリーセッションから少なくとも1つの価値のある例を特定したら、各例を構造化されたドキュメントとして定式化できます。これにより、構築するものの共有された理解を本当に持っていることを確認する迅速な方法が得られます。

従来のドキュメントとは対照的に、人間とコンピューターの両方で読み取ることができる媒体を使用するため、

  • 構築しているものに対する共有されたビジョンについて、チーム全体からフィードバックを得ることができます。
  • これらの例を自動化して、実装の開発をガイドすることができます。

この実行可能な仕様を共同で記述することにより、システムについて話すための共通の言語を確立します。これにより、問題領域の用語をコード全体で使用することができます。

自動化:何が実際に行われるか

実行可能な仕様ができたので、それを実装の開発をガイドするために使用できます。

一度に1つの例を取り上げ、システムにテストとして接続することによって自動化します。まだ記述されている動作を実装していないため、テストは失敗します。ここで、必要に応じて内部システムコンポーネントの動作に関するより低レベルの例を使用して、実装コードを開発します。

自動化された例はガイドレールのように機能し、開発作業を軌道に乗せるのに役立ちます。

後でシステムを保守する必要がある場合、自動化された例は、システムが現在実行していること、そして意図せずに何かを壊すことなく安全に変更を加えるのに役立ちます。

この迅速で繰り返し可能なフィードバックにより、手動回帰テストの負担が軽減され、探索的テストなど、より興味深い作業を行うための時間を確保できます。

詳細はこちら

以下のトピックを読んで、BDDについてさらに詳しく学びましょう。

このドキュメントの改善にご協力いただけます。このページを編集する