受け入れテスト駆動開発

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

受け入れテスト駆動開発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倍の速さで本をチェックインおよびチェックアウトできるようになる」です。

も参照してください

参考文献

  1. ^ a b c d e Pugh、Ken(2011)。リーンアジャイル受け入れテスト駆動開発:コラボレーションによるより優れたソフトウェアアディソン-ウェスリー。ISBN 978-0321714084
  2. ^ Adzic、Gojko。(2009)コミュニケーションギャップの橋渡し:例による仕様とアジャイル受け入れテスト、Neuri Limited、
  3. ^ Adzic、Gojko(2011)。例による仕様:成功したチームが適切なソフトウェアを提供する方法マニング。ISBN 978-0-321-27865-4
  4. ^ Chelimsky、David、Dave Astels、Zach Dennis、AslakHellesøy、Bryan Helmkamp、およびDanNorth。RSpecブック:RSpec、Cucumber、およびFriendsを使用したビヘイビア駆動開発。実用的な本棚。
  5. ^ 「駆動設計の例」2013年4月15日取得
  6. ^ 「ストーリーテスト駆動開発」(PDF)2013年4月15日取得
  7. ^ ベック、ケント。テスト駆動開発:例による。Addison-Wesley Professional、2002年。
  8. ^ Melnik、Grigori、およびFrankMaurer。Melnik、Grigori; マウラー、フランク(2007)。「実行可能受け入れテスト駆動開発に関する複数の視点」。ソフトウェアエンジニアリングとエクストリームプログラミングにおけるアジャイルプロセスコンピュータサイエンスの講義ノート。4536. pp。245–249。土井10.1007 / 978-3-540-73101-6_46ISBN 978-3-540-73100-9
  9. ^ Koskela、Lasse。(2007)テスト駆動:Java開発者向けのTDDおよびアクセプタンスTDD。マニング出版物
  10. ^ エヴァンス、エリック。(2003)ドメイン駆動設計:ソフトウェアの中心にある複雑さへの取り組みアディソン-ウェスリープロフェッショナル。
  11. ^ ワインバーグ、ジェラルド; ガウス、ドナルド(1989)。要件の調査:設計前の品質ドーセットハウス。ISBN 0-932633-13-7
  12. ^ マーティン、ロバートC.、およびグリゴリーメルニク。「テストと要件、要件とテスト:メビウスの帯」(PDF)2013年4月15日取得
  13. ^ [テスト駆動開発]
  14. ^ Meszaros、Gerard、およびJaniceAston。(2006)「アジャイルプロジェクトへのユーザビリティテストの追加」。アジャイル会議
  15. ^ 「探索的テストの説明」(PDF)
  16. ^ Meszaros、Gerard。(2007) xUnitテストパターン:テストコードのリファクタリングアディソン-ウェスリー。

外部リンク