アジャイル
受入テスト駆動開発（ATDD）
Acceptance Test Driven Development
読み：うけいれてすとくどうかいはつ
機能を実装する前に、関係者が受入テストの具体例を共同で定めて開発を導く方法です。
01初心者向け
まず意味をつかむ
作り終えてから「期待と違う」と気付くのを減らすため、利用者から見た合格例を先に話し合います。依頼側、開発側、検証側の異なる視点を持ち寄ります。
02実務者向け
仕事でどう使うか
ユーザーストーリーに対し、正常、境界、例外の受入例を合意します。必要なら自動化し、その例を満たす機能を実装します。仕様が変われば例とテストも更新します。
03専門家向け
判断を一段深める
受入テストを先に作る順序だけでなく、対話による共通理解が中心です。すべてを画面経由で自動化すると保守負担が増えるため、確認の目的に合うテスト層を選びます。
別名・略語：ATDD
IN PRACTICE
具体例で考える
架空の受講申込で、空席がある時と定員到達時の応答を三者で決め、その合意例を確認できる機能とテストを作ります。
理解を助けるための架空の例です。三つの視点で対話
受入例を合意
例を満たす実装
合意した例を開発へ使う関係で、自動化は目的に応じて選びます。
ここは誤解しやすい
テスト担当者だけが実装前にテストケースを書けば十分、という意味ではありません。
この知識を、組織の力へ。