アジャイル開発における「TDD」と「BDD」

アジャイル開発における「TDD」と「BDD」

アジャイル開発ではテストを早期かつ継続的に行う必要があります。そのため、開発が完了した後にテストを開始するのではなく、仕様が追加されるたびにテストを行うことが一般的です。このため、テストケースはコーディングの前に記述され、欠陥の防止、検出、および除去をできるだけ早く実行することに重点が置かれています。アジャイルテストには次のようなさまざまな方法がありますが、本記事ではソフトウェア開発における「テスト駆動開発」(Test-Driven Development: TDD)および「ビヘイビア駆動開発」(Behavior Driven Development: BDD)のアプローチについて詳しく説明します。

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

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

執筆者:ROBIN

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): 問題を解決するアーキテクチャと低レベルの設計を提案します。

拡大画像はこちら

4. 結論

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