BlogBlog

  • Home
  • Blog
  • アジャイル開発におけるTDD(テスト駆動開発)とBDD(ビヘイビア駆動開発)

アジャイル開発におけるTDD(テスト駆動開発)とBDD(ビヘイビア駆動開発) アジャイル開発

更新日:2022/10/20 ROBIN

アジャイル開発におけるTDD(テスト駆動開発)とBDD(ビヘイビア駆動開発)

アジャイル開発では、テストを特に早期かつ継続的に行う必要があります。
そのため、開発が完了した後にテストを開始するのではなく、仕様が追加されるたびにテストを行うことが一般的です。
このため、テストケースはコーディングの前に記述され、欠陥の防止、検出、および除去をできるだけ早く実行することに重点が置かれています。

アジャイルテストには次のようなさまざまな方法がありますが、本記事ではソフトウェア開発における「テスト駆動開発」(Test-Driven Development: TDD)および「ビヘイビア駆動開発」(Behavior Driven Development: BDD)のアプローチについて詳しく説明します。

・ テスト駆動開発(Test-Driven Development: TDD)
・ ビヘイビア駆動開発 (Behavior Driven Development: BDD)

・ 受け入れテスト駆動開発 (Acceptance Test-Driven Development: ATDD)
・ 探索的テスト
・ セッションベースのテスト

なおアジャイル開発については、こちらの記事で詳しくご紹介しています。宜しければ合わせてご参照ください。
あらためて、アジャイル開発とは|その概要から進め方、メリット・デメリット、開発手法について

1. テスト駆動開発(TDD)

テスト駆動開発(TDD)は、テストから始まるプログラミング方法として、多くのアジャイル開発手法に取り入れられています。
TDDでは開発者はコードを作成する前に、自動化された単体テストスーツを作成する必要があります。自動テストを作成することで、開発者は考えられる全ての入力、エラーおよび出力を考慮することが求められます。
TDDを開発に取り入れることで、アジャイルチームがコードを更新するたびに作成された自動テストが実行されるため、非常に迅速かつ効率的にテストを実行することが可能となります。

TDDは、次の5つのステップで理解できます。

① テストの作成
コードを書く前に、ソフトウェアの各ユースケースとユーザーストーリーを考案します。その後、ユースケースとユーザーストーリーを元にテストを作成します。このテストは、できるだけ簡潔にする必要があります。

② テストの実行
テストが実行できるようにコンパイルされます。この時点ではコードはまだ開発されていないため、最初のテストは失敗するはずです。

③ テストケースに基づいてコード開発/更新
期待値通りコードが正しく動けばOKです。ハードコードについては、ステップ⑤でリファクタリングされます。

④ テストの再実行
テストが失敗した場合、コードを修正します。全てのテストに合格するまで、テストは再実行されます。

⑤ コードのリファクタリング
テストが正常に実行されたら、全体的なパフォーマンスを向上させるために、コードの保守性と可読性を最適化します。リファクタリングがプログラムの外部動作に影響を与えないことを確認します。

※繰り返す
新しい機能が追加された時にテストケースを追加するために、上記のステップ1〜5の上のサイクルを繰り返します。

拡大画像はこちら

TDDを通じて、フィードバック、バグ修正、および新機能の追加に基づいて、システムが意図した通りに機能することを保証することができます。

2. ビヘイビア駆動開発 (BDD)

一方、TDDを使用する時にプログラマーは次の課題に直面します。

・ どこから始めるか?
・ 何をテストするか?
・ 何をテストしないか?

こういった課題に応えてくれる開発手法がビヘイビア駆動開発(BDD)です。
BDDはTDDを拡張した手法であり、システムの予想される動作を確認するためのテストに重点を置いています。

BDDを使用することにより開発者はどんなシステムを構築するかを正確に理解し、ビジネス要件を満たすソフトウェアを開発、提供することができるようになります。
BDDでは、開発者やドメインの専門家以外の人でも理解ができる「Gherkin」などの自然言語でテストケースを作成することが一般的です。

参考として、下記で具体的な記述例をご紹介します。

記述すべき項目:

ストーリー
■タイトル: 明示的なタイトル

■物語: 次の構造の短い紹介セクション

• AS A [user]
ユーザー/役割として

• I WANT [function]
機能/性能ができる

• SO THAT [value]
それにより価値がもたらされる

シナリオ
■合否基準: 次の構造の物語の各特定のシナリオの説明

• GIVEN
前提・初期コンテキスト

• WHEN
シナリオをトリガーする条件

• THEN
期待される結果

具体例:

■ストーリー
タイトル: クレジットカードで注文を支払う

物語:

AS A 顧客

I WANT  クレジットカードで注文を支払う
SO THAT 現金を使う必要はない

■シナリオ 1

GIVEN カードは有効です

WHEN 顧客が支払いを要求する

THEN アカウントから引き落とされていることを確認する

AND 注文が支払われていたことを確認する

■シナリオ2

GIVEN カードは無効です

WHEN 顧客が支払いを要求する

THEN 拒否メッセージが表示されていることを確認する

AND 注文が支払われていないことを確認する

AND 他のお支払い方法が表示されていることを確認する

この場合、イベントは両方のシナリオで同じですが、コンテキストが異なります。
結果として、期待値は異なります。

3. 3つのアミーゴ

このほか、BDDでは開発に関わるすべての人々が同じページに立ち、ビジネス要件について協力的に話し合うことが求められます。そのために、「3つのアミーゴ」と呼ばれるビジネスアナリスト(BA)、品質保証チーム(QA)、および開発チーム(SE)がビジネス要件について話し合う会議がセットされます。
この会議における主な目標は不足している仕様を特定することに置かれるほか、チームが要件を充実させ、適切な製品を構築しているかどうかについても確認を行います。

3つのアミーゴにおけるそれぞれの役割については以下のとおりです。

ビジネスアナリスト(BA): 各ビジネス要件について詳しく説明するほか、問題を定義します。

品質保証チーム(QA: What-Ifシナリオを通じてさまざまな可能性を提示し、問題解決に向けた道筋をより正確に導き出すのに役立ちます。

開発チーム(SE): 問題を解決するアーキテクチャと低レベルの設計を提案します。

拡大画像はこちら

導入事例

SHIFT ASIAのソフトウェア開発・テストなどの導入事例はこちらから

導入事例

4. 結論

アジャイルテストの方法論は、一連の工程を反復する開発手法と整合しています。
アジャイルテストプロセスは順次ではなく連続的なプロセスであるため、テストはプロジェクトの開始時に開始され(テストファーストアプローチ)、テストと開発の間で継続的な統合が行われます。これにより、アジャイルテストの共通の目的である高い製品品質を達成することが可能になります。

参考資料:
BDD – Test Driven Development (Tutorials Point)

SHIFT ASIAは品質保証とソフトウェア開発のプロフェッショナルとして、ベトナムを拠点にソフトウェアテスト事業・オフショア開発事業を展開しています。
弊社の具体的なサービスや導入事例については以下をご覧の上、何かございましたらお気軽にご連絡をいただけると幸いです。

お問い合わせ

ご不明点やご相談、ご依頼などがありましたら、お気軽にお問い合わせください

お問い合わせ

会社紹介資料

SHIFT ASIAの概要やソリューション、プロジェクト体制例などについてまとめた会社紹介資料を無料でDLいただけます

会社紹介資料

お問い合わせContact

ご不明点やご相談などがありましたら、お気軽にお問い合わせください。

今すぐご相談をご希望の方

お問い合わせ

まずは情報収集をご希望の方

資料ダウンロード