受入テスト設計 作成ルール
Acceptance Test Design (ATD) Documentation Rules
本ドキュメントは、 受入テスト設計（ATD）で定義された分割方針・観点を、 1つの業務受入条件／業務シナリオ単位で、実施可能な設計に落とし込む ための標準ルールです。
ATD-D は、
- 業務側が「この確認で受け入れ判断できる」と納得でき
- 実施者が「何を確認すればよいか」を迷わない
受入テストの最終設計レイヤです。
0. 位置づけ（必読）
plaintext
TSP（テスト戦略・方針）
└ ATS（受入テスト仕様）
└ ATS-D（受入テスト仕様・個別）
└ ATD（受入テスト設計）
└ ATD-D（受入テスト設計・個別） ← 本書
└ 受入テスト実施・結果| 観点 | ATD | ATD-D |
|---|---|---|
| 粒度 | 全体設計 | 個別設計 |
| 主語 | 受入テスト全体 | 1業務条件／1シナリオ |
| 役割 | 分割方針 | 具体的な確認設計 |
| ケース | 書かない | ここでも書かない |
※ ATD-D は「テストケース一覧」ではありません。
1. 全体方針
- ATD-D は 1つの業務受入条件（BAC）または業務シナリオにつき 1 ファイル作成します。
- ATD-D は 業務視点の設計であり、技術詳細は含めません。
- ATD-D では次を明確にします：
- 対象となる受入条件／業務シナリオ
- 確認すべき観点の適用範囲
- ケース分割の考え方（観測軸）
- 合否判断に必要な観測点
2. 作成単位
ATD-D の作成単位は以下のいずれかです。
- 業務受入条件（BAC）単位（推奨）
- 業務シナリオ単位
- 業務イベント単位（例：出荷完了、請求確定）
※ 原則として ATS-D と 1:1 で対応させます。
3. ファイル命名・ID規則
ファイル名（推奨）
sh
010-受入テスト設計-受注完了.md
020-受入テスト設計-在庫不足対応.mdID ルール
| 項目 | ルール |
|---|---|
| prefix | atd- |
| id | atd-order-complete, atd-stock-shortage |
※ ID は 用語集の term を基準にした安定名を使用します。
4. 推奨 Frontmatter 項目
| 項目 | 説明 | 必須 |
|---|---|---|
| id | ATD-D ID（atd-*） | ○ |
| type | test 固定 | ○ |
| title | 受入テスト設計: <業務条件名> | ○ |
| status | draft / ready / deprecated | ○ |
| part_of | atd-main | 必須 |
| based_on | ats-*, ats-d-*, bac-* | 必須 |
| supersedes | 置換関係 | 任意 |
5. 本文構成（標準テンプレ）
ATD-D は以下の見出しを 必ずこの順序で記述します。
- 概要
- 対象となる業務受入条件
- 対象業務シナリオ
- 適用する受入観点
- ケース分割の考え方
- 合否判断の観測点
- 実施上の前提・制約
- 対象外
- メモ / 将来課題
6. 記述ガイド詳細
6.1 概要
- 本 ATD-D が どの業務条件の受入判断を設計するか を簡潔に記述します。
例：
本設計は、受注完了が業務として成立しているかを判断するための受入テスト設計である。
6.2 対象となる業務受入条件（必須）
- 対応する BAC を明示します。
例：
- bac-order-complete
6.3 対象業務シナリオ（必須）
- 業務の流れを 業務用語で要約します。
- 操作手順・画面遷移の逐語列挙は禁止。
6.4 適用する受入観点（必須）
ATS / ATS-D の観点を この条件に適用します。
| 観点カテゴリ | 観点 |
|---|---|
| 業務 | 業務が完了状態になる |
| 操作 | 業務担当者が判断に迷わない |
| 情報 | 必要な情報が確認できる |
| 運用 | 問い合わせ・再確認が可能 |
6.5 ケース分割の考え方（必須）
ATD-D の中核です。
- ケースは 業務状態 × 業務判断 の組み合わせで分割します。
- 具体ケース一覧は 記載しません。
例：
| 分割軸 | 考え方 |
|---|---|
| 業務状態 | 通常処理 / 再処理 |
| 判断結果 | 完了 / 差戻し |
| 情報参照 | 画面のみ / 帳票含む |
6.6 合否判断の観測点（必須）
- 合否判断に必要な 観測ポイントを列挙します。
例：
- 業務結果が確認できる
- 業務判断に必要な情報が揃っている
- 業務を止める不具合が発生しない
※ 数値基準は SAC / NFR に委譲
6.7 実施上の前提・制約（必須）
- 受入テスト実施の前提条件を明示します。
例：
- 業務マスタが準備済み
- 操作マニュアルが最新である
6.8 対象外
- 本設計では扱わない業務条件
6.9 メモ / 将来課題
- 将来の受入条件追加
- 未確定事項
7. 禁止事項
| 禁止事項 | 理由 |
|---|---|
| 操作手順の逐語列挙 | UI変更に弱い |
| 入力値・期待値の明示 | 実施レベル |
| 技術用語・実装詳細 | 業務判断に不要 |
| テストケース一覧 | 実行設計に委譲 |
8. サンプル（最小）
yaml
---
id: atd-order-complete
type: test
title: 受入テスト設計: 受注完了
status: draft
part_of: [atd-main]
based_on:
- ats-order-complete
- bac-order-complete
---9. 生成AI向け指示テンプレート
- 以下のルールに従って 受入テスト設計 − 個別設計（ATD-D） を 1 ファイル作成してください。
- 対象は 1つの業務受入条件（BAC） としてください。
- ケース分割の考え方と合否判断の観測点を中心に記述してください。
- 操作手順・入力値・技術詳細は記載しないでください。