テストドキュメントスコープ定義ルール

1. 目的

本ルールは、テストに関する各ドキュメント（戦略・観点・対象別テスト等）について、

• どのドキュメントに
• どこまで記述するか
• 何を書いてはいけないか

を明確にし、重複・抜け漏れ・責務の混乱を防ぐことを目的とする。

2. 基本原則

2.1. 責務分離の原則

• 上位は 方針・基準・網羅性
• 下位は 具体化・実行可能性

とする。

2.2. 非重複（SSOT）の原則

• 同一内容を複数成果物に重複記載しない
• 重複が必要に見える場合は、原則として 参照（IDリンク）で表現する
• 観点・条件・トレースの一次情報（SSOT）は TPC とする

2.3. 「書かない」ことも仕様である

• 対象外・除外理由・委譲先を明示する
• 「ここには書かない」を明示することで、下流工程の迷いを減らす

2.4. ドキュメント最小化の原則

• テストレベル別ドキュメントは 「全体構成（index）」＋「対象別（term）」の2種を基本 とする
• テスト仕様（Specification）とテスト設計（Design）を 別文書系列として分離せず、仕様に必要事項を含める
• テスト設計の詳細（具体値・ケース網羅・実行方法）は 原則としてテストコードおよびCI成果物で表現する
• テスト設計を文書系列として分離しない理由は、設計の詳細がコードと乖離しやすく、二重管理・形骸化を招くためである

3. 文書責務

ドキュメントは、テスト全体のテスト戦略・方針（tsp-overview）、テスト観点・条件（tpc-<term>）、およびテストレベル別の 全体構成（<level>s-index） と 対象別（<level>s-<term>） に分割する。

• <level>s-index は、当該テストレベルの 唯一のナビゲーション起点 とする
• <level>s-<term> は、当該テストレベルの 対象別テスト仕様 とする

※注記:

• <level>はテストレベル略号（ut/it/et/st/at）を表す。
• <term> は対象単位を表す識別子（例：inventory, product-register）とする。

3.1. テスト戦略・方針 (TSP: Test Strategy / Policy; tsp-overview)

• テスト全体の目的／基本方針／役割分担（レベル別の責務境界）を定義する
• 品質ゲート（入口条件・出口条件）を定義する
• 環境・データ・自動化・不具合運用など、テスト運用の前提を定義する ※ 個別の観点・条件・ケース・具体値は記載しない

3.2. テスト観点・条件 (TPC: Test Perspectives & Conditions; tpc-<term>)

• 観点（What）と条件（When/State）を網羅し、上位仕様へトレースする（SSOT）
• 各観点／条件に、以下を付与する
  • 優先度（P0/P1/P2…）
  • 適用テストレベル（UT/IT/ET/ST/AT など）

※ ケース・具体値・手順は定義しない（設計や実装へ委譲）

3.3. テスト仕様 全体構成（<level>s-index）

• 当該テストレベルの責務を定義する
  • 対象単位（何を対象とするか）
  • 境界（何を含み、何を切るか）
  • 自動化方針
  • 共通合格基準
• TPC を当該レベルに適用するための 適用ルール（分配・解釈方針） を定義する
• 対象別テスト仕様（<level>s-<term>）への ナビゲーション（一覧・リンク） を提供する

禁止事項

• TPCの観点・条件表の再掲
• テストケースの羅列
• 個別対象の詳細保証内容（対象別でのみ書く）

3.4. テスト仕様 対象別（<level>s-<term>）

対象単位ごとに、以下を最小限で定義する

• 対象と境界（含む／除外、依存の扱い）
• 参照TPC（観点ID・条件IDの範囲のみ）
• 代表ケース（必要に応じて）
  • ケースID
  • 参照TPC
  • 期待結果の要点
  • 証跡（テストコード／CI結果等）へのリンク
• 対象固有の合格基準（必要な場合のみ）

禁止事項

• TPCの観点・条件表の再掲（参照IDの範囲のみ）
• 自動テストのケース・具体値・手順の逐語列挙（テストコード／CI成果物へ委譲）
• 根拠のない網羅主張（TPC参照・証跡リンクで示す）

補足

• 自動テストの場合、具体値・詳細手順・網羅展開は テストコード に委譲する
• 手動テストの場合のみ、必要最小限の実施手順を記載してよい

3.5. テストレベル別 責務一覧

テストレベル	対象（何を確認）	境界（どこまで含める）	重点（落とし穴）	成果物（ID）
単体（UT）	ドメインロジック／計算／分岐／バリデーション	DB・外部I/F・時刻等はモック／スタブで切る	境界値／異常値／状態分岐／業務ルール整合	uts-index, uts-<term>
内部結合（IT）	コンポーネント間／サービス間の連携	内部は実接続を増やす。外部I/Fは原則隔離（スタブ等）	I/F整合、データ受け渡し、連携例外、状態整合	its-index, its-<term>
外部結合（ET）	外部API／外部ファイル／外部メッセージ	サンドボックス／スタブ／契約テストで環境差を吸収	契約（スキーマ・コード値）、認証、タイムアウト／リトライ、再送／冪等性	ets-index, ets-<term>
総合（ST）	システム全体／主要業務フロー／横断要件の成立	結合済み環境前提（内部・外部I/F含む構成を基本）	E2E成立、主要例外、データ整合、運用成立（必要範囲）	sts-index, sts-<term>
受入（AT）	受入条件（SAC/BAC）の合否（利用者が判断可能な粒度）	実装詳細は見ない（期待結果は利用者観点に限定）	合否判定の明確さ、証跡、運用シナリオ成立	ats-index, ats-<term>

※ 本プロジェクトでは Internal Integration を IT と表記

3.6. 補足

• テストケースは 観点（TP）× 条件（TC） の組み合わせで構成される
• ただし、組み合わせ（ケース構成）を文書で過剰に列挙しない
  • 自動テストは コード（parameterized / property-based / table-driven など） で表現する
  • 文書には「代表ケース」と「証跡リンク」を残す
• 監査・規制・外部委託等により文書での詳細な実施手順が求められる場合のみ、 本ルールの例外として追加文書を作成してよい

4. 判断に迷ったときのルール

1. 「網羅性・分類・トレースの話か？」

   • Yes → TPC（tpc-<term>）
   • No → 次へ

2. 「レベル共通の境界・合格基準・自動化方針か？」

   • Yes → <level>s-index
   • No → 次へ

3. 「対象別に何を担保するか（参照TPC、代表ケース、証跡）か？」

   • Yes → <level>s-<term>
   • No → 次へ

4. 「具体値や詳細手順か？」

   • 自動テスト → テストコード（必要ならコード側のREADME/コメントで補足）
   • 手動テスト → <level>s-<term> に最小手順（別文書を増やさない）

5. よくあるアンチパターン

アンチパターン	問題点
TPCに具体値・手順・ケースが書かれている	SSOTの肥大化／責務逸脱
<level>s-index にTPCの表（観点・条件）がコピペされている	重複／更新漏れの温床
<level>s-<term> にTPCの表が再掲されている	重複／差分発生
自動テストの詳細手順や値パターンを文書で逐語列挙している	コードと二重化／保守不能
同じ「観点×条件×期待」表が複数の文書に存在している	破綻の温床
合格基準がTPCに混在している（品質ゲートやレベル共通基準が曖昧）	方針と条件の混同／判断の不一致
「仕様」と「設計」を別系列で維持し続け、どちらが正か分からなくなる	二重SSOT／形骸化