テスト戦略・方針 (TSP) 作成の指示テンプレート

• 以下のルールに従って、テスト戦略・方針（TSP） を 1 ファイル作成してください。出力は Markdown とします。
• TSP は「個別のテストケース集」ではありません。各テストレベルの 目的・範囲・体制 と 品質ゲート（入口/出口条件） を合意できる形で定義してください。
• 曖昧表現（例: 「十分」「適切」「問題ない」）は禁止し、合否判定できる条件として記述してください。
• 禁止: 物理テーブル名・物理カラム名・SQL全文、実装クラス/関数名、特定ライブラリの設定値の列挙、クリック手順など UI 操作の逐語列挙、個別テストケースの大量列挙

事前に与えられる情報（入力）

次の情報が与えられている前提で、それに整合するTSPを生成してください（不明な場合は、TSP内で「前提（未確定）」として明記してよい）。

• 対象システム/プロジェクト名
• 主要業務（例: 販売/在庫/発注/入荷/棚卸/レポート 等）
• 外部I/F（例: 決済、会計、外部API、ファイル連携 等）
• 参照すべき仕様ID（任意）
  • 例: bac-...（受入条件）、nfr-...（非機能要件）、sac-...（システム受入条件）、adr-...（設計判断）

出力フォーマット（必須）

• 先頭に YAML Frontmatter を付与し、以下の形式で記述してください（id / type / title / status は必須、type は test 固定）：

  ---
  id: tsp-<英小文字とハイフンで構成したID>
  type: test
  title: テスト戦略・方針: <対象名>
  status: draft # draft / ready / deprecated
  part_of: []
  based_on: []
  supersedes: []
  ---

• 本文は次の見出し（日本語）をこの順序で必ず含めてください：

  1. 概要
  2. テスト戦略・方針
  3. メモ / 将来課題

記述ルール（重要）

1. 概要

• 1〜3文で「何の品質を、どの範囲に対して、どのように担保するか」を書いてください。
• based_on に列挙した仕様（BAC/NFR/SAC等）と矛盾しない内容にしてください。

2. テスト戦略・方針（必須要素）

「テスト戦略・方針」には必ず以下を含めてください。

対象システム（前提）

• 対象業務と、主要な外部I/Fを簡潔に列挙してください。
• 外部I/Fについては「境界の責任範囲（対象/対象外）」が分かる一文を添えてよいです。

テストレベル一覧（表形式・必須）

• 次の列を持つ 一覧表で定義してください：
  • テストレベル / 目的 / 範囲 / 実施体制・備考
• 目安: 4〜6 行（単体/結合/総合/受入を基本に、必要なら外部I/Fや性能などで分ける）。
• 各レベルで「何を確認し、何を下位/上位に委ねるか」の境界を明確にしてください。

スコープ（対象/対象外・必須）

• 対象（含む） と 対象外（除外） を必ず書いてください。
• 除外は「なぜ除外できるか（外部契約、運用で切り分け、リスク受容 等）」が分かる形にしてよいです。

テスト環境・テストデータ（方針・必須）

• 環境区分（例: 開発/結合/総合/受入）と用途、外部I/Fの扱い（モック/スタブ/サンドボックス等）を定義してください。
• テストデータは、個人情報の扱い（禁止/匿名化）と、代表データ量やマスタの再現性方針を最小限で書いてください。

入口／出口条件（品質ゲート・表形式推奨・必須）

• フェーズ/テストレベルごとに、開始条件と完了条件を 合否判定できる形で定義してください。
• 出口条件には、未解決不具合の扱い（重大度別の許容）と、必要なら NFR/SAC への合格条件を含めてください。

2. テスト戦略・方針（任意だが推奨）

必要に応じて以下を追加してください（プロジェクトで合意が必要な場合のみ）。

• 自動化・回帰方針（どこを自動化し、どこを手動で補うか）
• 不具合管理方針（重大度、収束基準、既知不具合の扱い）
• 品質メトリクス（合意が必要な最小限のみ）

3. メモ / 将来課題

• 未確定の前提、将来追加したい試験、外部依存の合意事項を箇条書きで記載してください。

最終チェック（自己検査）

• 見出しが 1〜3 の順で揃っている
• 「テストレベル一覧」「スコープ」「環境/データ」「入口/出口条件」が入っている
• 曖昧表現がなく、合否判定できる書き方になっている
• 実装依存（SQL/クラス名/設定値/逐語手順）を書いていない