受け入れテスト駆動開発

受け入れテスト駆動開発（ATDD）は、ビジネス顧客、開発者、およびテスト担当者間のコミュニケーションに基づいた開発方法論です。 ^{[ 1 ]} ATDDには、例示による仕様記述（SBE）、^{[ 2 ]}^{[ 3 ]}行動駆動開発（BDD）、^{[ 4 ]}例示駆動開発（EDD）、^{[ 5 ]}ストーリーテスト駆動開発（SDD）とも呼ばれるサポート駆動開発と同じプラクティスの多くが含まれます。^{[ 6 ]}これらのプロセスはすべて、開発者とテスト担当者が実装前に顧客のニーズを理解するのに役立ち、顧客が独自のドメイン言語で会話できるようにします。

ATDDはテスト駆動開発（TDD）と密接に関連しています。^{[ 7 ]}開発者、テスター、ビジネス顧客の連携を重視する点が異なります。ATDDは受け入れテストを網羅していますが、開発者がコーディングを始める前に受け入れテストを作成することに重点を置いています。

概要

受け入れテストは、ユーザーの視点、つまりシステムの外部からの視点から行われます。^{[ 1 ]}受け入れテストは、特定の入力に対するシステムの正しい出力を特定するなど、外部から見える効果を検証します。受け入れテストでは、注文が「支払済み」から「発送済み」に変わるなど、状態がどのように変化するかを検証できます。また、共有データベースやWebサービスなど、他のシステムのインターフェースとの相互作用を確認することもできます。一般的に、受け入れテストは実装に依存しませんが、自動化は必ずしもそうとは限りません。^{[ 8 ]}^{[ 9 ]}

創造

受け入れテストは、要件が分析され、コーディングの前に作成されます。^{[ 1 ]}受け入れテストは、要件要求者（製品オーナー、ビジネスアナリスト、顧客担当者など）、開発者、テスト担当者が共同で開発できます。開発者は受け入れテストを使用してシステムを実装します。テストに失敗すると、要件が満たされていないことがすぐにフィードバックされます。テストはビジネスドメイン用語で指定されます。これらの用語は、顧客、開発者、テスト担当者の間で共有される普遍的な言語を形成します。^{[ 10 ]}テストと要件は相互に関連しています。^{[ 11 ]}テストのない要件は適切に実装されない可能性があります。要件を参照しないテストは不要なテストです。実装開始後に開発される受け入れテストは、新しい要件を表します。^{[ 12 ]}

テスト戦略

受け入れテストは、全体的なテスト戦略の一部です。システムのビジネス上の意図を示す、顧客／ユーザー指向のテストです。テスト戦略によっては、他のテストタイプと組み合わせて使用する場合もあります。例えば、低レベルのユニットテスト、^{[ 13 ]}ユーザビリティテストを含むクロスファンクショナルテスト、^{[ 14 ]}探索的テスト、^{[ 15 ]}プロパティテスト（スケーリングとセキュリティ）^{[ 16 ]などです。}

受け入れ基準とテスト

受け入れ基準とは、テストで確認する内容を記述したものです。例えば、「利用者として、図書館から本を借りたい」という要件の場合、受け入れ基準は「本が貸出中であることを確認する」といったものになります。この要件に対する受け入れテストでは、テストを毎回同じ結果で実行できるように、詳細な情報を提供します。

テスト形式

受け入れテストは通常、次のような形式をとります。^{[ 1 ]}

与えられた（セットアップ）

システムの特定の状態

いつ（トリガー）

アクションまたはイベントが発生する

それから（検証）

システムの状態が変化したか、出力が生成された

また、以下のいずれかのセクション (Given、When、Then) に ANDで始まるステートメントを追加することもできます。

要件の例の場合、手順は次のようになります。

貸し出されていない本とシステムに登録されているユーザーがいる場合、ユーザーが本を貸し出すと、本は貸し出されているとマークされます。

完全なテスト

前の手順には特定のサンプルデータが含まれていないため、テストを完了するために追加します。

与えられた条件:

貸出されていない本

本
タイトル	チェックアウト
素晴らしい本	いいえ

システムに登録されているユーザー

ユーザー
名前
サム

いつ：

ユーザーが本を借りる

チェックアウトアクション
ユーザー	サム	チェックアウト	素晴らしい本

それから：

本は貸出済みとしてマークされています

本
タイトル	チェックアウト	ユーザー
素晴らしい本	はい	サム

試験試験

特定のデータを用いたテストの検証は、通常、多くの疑問を生み出します。サンプルの場合、次のような疑問が考えられます。

本がすでに貸し出されている場合はどうなりますか?
本が存在しない場合はどうなるのでしょうか?
ユーザーがシステムに登録されていない場合はどうなりますか?
本をチェックインする期限はありますか?
ユーザーはいくつの本を借りることができますか?

これらの質問は、不足している要件や曖昧な要件を明らかにするのに役立ちます。期日などの詳細情報を期待される結果に追加することもできます。また、他の受け入れテストでは、既に貸出されている書籍を貸出しようとするなどの条件で、期待されるエラーが発生するかどうかを確認できます。

別のテスト例

ビジネス顧客が、ユーザーが一度に1冊しか貸し出せないというビジネスルールを希望しているとします。次のテストは、そのことを実証します。

シナリオ: チェックアウトのビジネスルールが適用されていることを確認する

与えられた条件:

貸出中の本

本
タイトル	チェックアウト	ユーザー
素晴らしい本	はい	サム
もう一つの素晴らしい本	いいえ

ユーザー
名前
サム

いつ：

ユーザーが別の本を借りる

チェックアウトアクション
ユーザー	サム	チェックアウト	もう一つの素晴らしい本

それから：

エラー発生

エラーが発生しました
説明
チェックアウトビジネスルール違反

プロジェクト受け入れテスト

要件に対する受け入れテストに加えて、プロジェクト全体に対しても受け入れテストを実施できます。^{[ 1 ]}例えば、この要件が図書館の図書貸出プロジェクトの一部である場合、プロジェクト全体に対して受け入れテストを実施できます。これらはしばしばSMART目標と呼ばれます。例えば、「新しい図書館システムが稼働すると、利用者は現在よりも3倍速く図書を貸し出し・返却できるようになります」といったテストがあります。

参照

参考文献

^ ^a ^b ^c ^d ^e Pugh, Ken (2011).リーン・アジャイル・アクセプタンス・テスト駆動開発：コラボレーションによるソフトウェア改善. Addison-Wesley. ISBN 978-0321714084。
^ Adzic, Gojko. (2009)コミュニケーションギャップを埋める: 例示による仕様とアジャイル受け入れテスト、Neuri Limited、
^ Adzic, Gojko (2011).例による仕様定義：成功するチームはどのようにして適切なソフトウェアを提供するのか. Manning. ISBN 978-0-321-27865-4。
^ Chelimsky, David, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North. The RSpec Book: Behavior Driven Development with RSpec, Cucumber, and Friends. The Pragmatic Bookshelf.
^ 「例に基づく設計」。 2013年4月15日閲覧。
^ 「ストーリーテスト駆動開発」(PDF) . 2013年4月15日閲覧。
^ベック、ケント『テスト駆動開発：事例による解説』Addison-Wesley Professional、2002年。
^メルニク、グリゴリ、フランク・マウラー。メルニク、グリゴリ、マウラー、フランク (2007)。「実行可能な受け入れテスト駆動開発に関する多様な視点」。ソフトウェア工学とエクストリームプログラミングにおけるアジャイルプロセス。コンピュータサイエンス講義ノート。第4536巻。pp. 245– 249。doi : 10.1007 /978-3-540-73101-6_46。ISBN 978-3-540-73100-9。
^ Koskela, Lasse. (2007) テスト駆動：Java開発者のためのTDDと受け入れTDD. Manning Publications
^エヴァンス、エリック。(2003)ドメイン駆動設計：ソフトウェアの核心における複雑性への取り組み。Addison-Wesley Professional。
^ワインバーグ、ジェラルド、ガウス、ドナルド (1989). 『要求の探求：設計より品質を重視する』ドーセットハウス. ISBN 0-932633-13-7。
^ Martin, Robert C., Grigori Melnik.「テストと要件、要件とテスト：メビウスの帯」（PDF） . 2013年4月15日閲覧。
^ [テスト駆動開発]
^ Meszaros, Gerard, Janice Aston. (2006) 「アジャイルプロジェクトへのユーザビリティテストの追加」Agile Conference
^ 「探索的テストの説明」(PDF) 2019年3月23日。
^ Meszaros, Gerard.(2007) xUnitテストパターン：テストコードのリファクタリング. Addison-Wesley.

外部リンク

自動化フレームワークの例

[Pugh11-1] Pugh, Ken (2011).リーン・アジャイル・アクセプタンス・テスト駆動開発：コラボレーションによるソフトウェア改善. Addison-Wesley. ISBN 978-0321714084。

[2] Adzic, Gojko. (2009)コミュニケーションギャップを埋める: 例示による仕様とアジャイル受け入れテスト、Neuri Limited、

[3] Adzic, Gojko (2011).例による仕様定義：成功するチームはどのようにして適切なソフトウェアを提供するのか. Manning. ISBN 978-0-321-27865-4。

[4] Chelimsky, David, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North. The RSpec Book: Behavior Driven Development with RSpec, Cucumber, and Friends. The Pragmatic Bookshelf.

[5] 「例に基づく設計」。 2013年4月15日閲覧。

[6] 「ストーリーテスト駆動開発」(PDF) . 2013年4月15日閲覧。

[7] ベック、ケント『テスト駆動開発：事例による解説』Addison-Wesley Professional、2002年。

[8] メルニク、グリゴリ、フランク・マウラー。メルニク、グリゴリ、マウラー、フランク (2007)。「実行可能な受け入れテスト駆動開発に関する多様な視点」。ソフトウェア工学とエクストリームプログラミングにおけるアジャイルプロセス。コンピュータサイエンス講義ノート。第4536巻。pp. 245– 249。doi : 10.1007 /978-3-540-73101-6_46。ISBN 978-3-540-73100-9。

[9] Koskela, Lasse. (2007) テスト駆動：Java開発者のためのTDDと受け入れTDD. Manning Publications

[10] エヴァンス、エリック。(2003)ドメイン駆動設計：ソフトウェアの核心における複雑性への取り組み。Addison-Wesley Professional。

[11] ワインバーグ、ジェラルド、ガウス、ドナルド (1989). 『要求の探求：設計より品質を重視する』ドーセットハウス. ISBN 0-932633-13-7。

[12] Martin, Robert C., Grigori Melnik.「テストと要件、要件とテスト：メビウスの帯」（PDF） . 2013年4月15日閲覧。

[13] [テスト駆動開発]

[14] Meszaros, Gerard, Janice Aston. (2006) 「アジャイルプロジェクトへのユーザビリティテストの追加」Agile Conference

[15] 「探索的テストの説明」(PDF) 2019年3月23日。

[16] Meszaros, Gerard.(2007) xUnitテストパターン：テストコードのリファクタリング. Addison-Wesley.

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]

[ 15 ]

[ 16 ]などです。