D9: テスト仕様書

遵守すべき重要ルール

1. 観測できる結果を1つ記載する: 期待結果は、利用者・運用者が観測できる1つの結果で記載する。関数名・変数名・テーブル名など内部実装の用語は使わない。観点の期待値に成否が別々に分かれる結果が入っているときは、観点の分割が先である旨をユーザーに伝え、仕様書では1つの期待結果にまとめない。
2. 1ケースで1つのテストパターンを確かめる: 複数のテストパターンを1ケースに詰め込まない。ケースは、画面を上から順に操作して確かめられる順に並べる。同じ画面で続けられるものをまとめ、状態を変える操作の直後に、その状態を見るケースを続ける。
3. 観点一覧の範囲の外に出ない: 観点一覧に無い観点からテストケースを作らない。
4. 仕様から決まる値だけを具体的に記載する: 桁数の上限・日付の下限のように、仕様から一意に決まる値は手順と期待結果に記載する。顧客名・商品コードのように案件で用意するデータは「部分一致する件名がある」のように性質だけを記載する。
5. 上流の成果物を直さない: 上流の漏れや誤りに気づいたら、直さずにユーザーへ伝える。
6. ID を振り直さない: 採番済みの TC-* と行の対応は変えず、欠番も再利用しない。表記は最大番号の桁数で先頭を0埋めする。2桁なら TC-01、3桁なら TC-001 とする。

インプットする成果物

成果物のパス	内容
docs/D9.test-design/test-perspectives.md	テスト観点一覧。テスト観点と期待値を、テストケースに利用。テスト技法を、テストパターンの洗い出しに利用。テストアイテム、画面名、機能・バッチ名、優先度を、各列への引き継ぎに利用。前提条件は、実行順で足りない状態を足すのに利用
docs/D8.test-plan/system-test-plan.md	システムテスト計画書。観点のテストアイテムが、テストスコープについて計画書が定めた値と一致することを確認するのに利用
docs/D1.business-requirements/use-case-list.md	ユースケース一覧。ユースケースのトリガと主要価値を、業務シナリオの手順の作成に利用
docs/D2.system-requirements/function-list.md	機能一覧。機能の概要を、手順と期待結果の具体化に利用
docs/D2.system-requirements/screen-list.md	画面一覧。画面の名称を、手順に記載する画面名の確認に利用
docs/D2.system-requirements/screen-flow-diagram.md	画面遷移図。画面間の遷移を、画面操作の手順と期待結果の作成に利用
docs/D3.system-design/c4-level2-container.md	C4モデル レベル2。連携方式を、外部連携・非同期の手順の組み立てに利用
docs/D3.system-design/c4-level2-sequences/*.md	C4モデル レベル2シーケンス。処理の流れと分岐を、テスト手順の組み立てに利用
docs/D3.system-design/batch-list.md	バッチ一覧。バッチの起動条件を、テスト手順の組み立てに利用
docs/D3.system-design/screen-designs/*.md	画面設計書。項目名・ボタン名・メッセージの文言と、入力項目の桁数・値域を、テストパターン・手順・期待結果に利用

アウトプットする成果物

成果物のパス	内容
docs/D9.test-design/test-specification.md	テスト仕様書

アウトプットに使用するテンプレート

テンプレートのパス	内容
.claude/skills/d9-test-specification/template.md	テスト仕様書のテンプレート

処理

1. 分岐する

• もし docs/D9.test-design/test-perspectives.md が無いなら、テスト観点一覧が先である旨を伝えて終了する。
• もし docs/D9.test-design/test-specification.md が無いなら、§2（新規作成）に進む。
• それ以外なら、§3（更新）に進む。

2. 新規作成

2.1 展開する観点を列挙する

観点一覧の TVP-* を並び順に記載し、それぞれのテストアイテム、画面名、テストスコープ、機能・バッチ名、観点分類、テスト技法、前提条件、テスト観点、期待値、優先度、参照元を引く。観点のテストアイテムが、そのテストスコープについて計画書が定めた値と食い違うなら、直さずにユーザーへ伝える。

2.2 観点ごとにテストケースを作成する

2.1 の順に1つの観点を進め、観点ごとにテストケースを記載する。新規作成時は、作成した順に TC-* を通し連番で振る。全件を振り終えたら、最大番号の桁数で先頭を0埋める。行の並び順は §2.3 で変える。振った ID は変えない。

• 観点一覧から列を記載する: テストアイテム、画面名、機能・バッチ名、テスト観点ID、テスト観点、優先度を記載する。
• 技法の有無を見る: 観点にテスト技法が定められているかを確認する。
• テストパターンを決める:
  • 記載ルール:
    • 行の分割: 展開したパターンごとに行を分ける。技法が「—」ならテストパターンも「—」とし、行は分けない。
    • 条件の絞り込み: 展開したパターンのうち、その観点と期待値に合致するものだけを記載する。エラーを確かめる観点に、正常値のパターンは記載しない。
    • 簡潔な記載: パターン列には「件名の上限+1(101文字)」のように具体的な条件だけを記載し、テスト観点の文章は繰り返さない。
  • 技法ごとの抽出基準:
    • 境界値分析: 上限値、上限＋1、下限値、下限−1。
    • 同値分割: 有効値の代表、無効値の代表。区分値なら値ごとに1つ。
    • エラー推測: 失敗の契機・要因（ユーザーの誤操作、異常なデータ、タイムアウト等）ごとに1つ。
    • デシジョンテーブルテスト: 業務ルールの条件の組み合わせごとに1つ。
    • 状態遷移テスト: 定義された遷移、定義されていない遷移（不正な操作）。
    • 一覧に無い技法: その技法が網羅しようとするバリエーションの単位に従う。
• 手順と期待結果を記載する: テスト観点・テストパターンをもとに、その観点の参照元が指す成果物を見て、番号を振ってテスト手順と期待結果を記載する。手順が複数あるときは、番号ごとに改行して記載する。期待結果は1つにする。画面の文言は画面設計書のとおりにする。画面設計書が無いときは、シーケンスとワイヤーフレームの文言を使う。バッチ一覧が無いときは BATCH-* は無いものとして扱う。
• 実行欄を空ける: 作成時は結果を「未実施」とし、実行日・実行担当者・不具合URL・備考は空欄にする。

2.3 実行順序に沿って修正する

2.2 で作成したケースの行を、画面を上から順に操作して確かめられる順に並べ替える。同じ画面で続けられるものをまとめ、状態を変える操作の直後に、その状態を見るケースを続ける。注文を消す初期化は末尾にする。TC-* は振り直さない。

• 実行順序を振る: 並べた順の数値を、優先度の右の列に記載する。1, 2, 3 とし、先頭は0埋めしない。並べ替えのたびに、この番号は上から振り直す。
• 前提条件を記載する: 実行順で、直前のケースの終了状態から追加で要る状態だけを1文で記載する。画面名は記載しない。直前の終了状態で足りるときは「—」とする。画面へ移動する操作は、そのケースの手順に記載する。

2.4 仕上げる

「完成時のセルフチェック」を実施する。

3. 更新

• インプットした成果物で変わった箇所に関わる行を §2 の手順で見直す。新しいケースには最大値の次の TC-* を、既存と同じ桁数で振る。桁が増えたときは、既存の TC-* も同じ桁数に揃える。不要になったケースは行を削除する。実行順序は、並べ替えたあとに 1 から振り直す。
• すでに記入された実行日・結果・実行担当者・不具合URL・備考は消さない。
• 手順か期待結果を変えた行は、記入済みの結果が確かめた内容と合わなくなるため、結果を「未実施」に戻して実行日・実行担当者を空欄にし、その旨をユーザーに伝える。

完成時のセルフチェック

• 観点一覧の全 TVP-* が、いずれかの行のテスト観点IDに現れている
• 各行のテスト観点IDに、観点一覧に無い TVP-* が現れていない
• 各行のテストアイテム、画面名、機能・バッチ名、テスト観点、優先度が、テスト観点IDについて観点一覧が定めた値と一致している
• 各行のテストアイテムが、テスト観点IDのテストスコープについて計画書が定めたテストアイテムと一致している
• テスト技法が付いた観点には、2.2 の技法ごとの抽出基準のうち、その観点の期待値が確かめているものがテストパターンに現れている
• 1ケースに1つのテストパターンだけが対応し、テスト観点IDとテストパターンが同じ行が無い。テストパターンに、テスト観点IDのテスト観点の言い換えが記載されていない
• 全行のテスト手順・期待結果が埋まっており、「同上」等で省略されていない。前提条件は1文か「—」で、画面名が無い。実行順で直前の終了状態で足りる行が「—」になっている
• テスト手順が番号を振って並んでおり、手順が複数ある行は番号ごとに改行されている。行が画面を順に操作して確かめられる順になっている。実行順序が優先度の右にあり、その順の 1 からの数値で、先頭が0埋めされていない。注文を消す初期化が末尾にある
• 期待結果が観測できる1つの結果で記載され、内部実装の用語が使われていない
• 各行の期待結果が、テスト観点IDについて観点一覧が定めた期待値と矛盾していない
• 画面のメッセージとボタン名が、画面設計書の文言と一致している
• 顧客名・商品コードのような業務データの具体値が記載されていない
• 作成時は、全行の結果が「未実施」で、実行日・実行担当者・不具合URL・備考が空欄になっている
• TC-* に重複が無く、最大番号の桁数で先頭が0埋めされている。新規作成時の番号は観点ごとにケースを作成した順で、実行順へ並べ替えたあとも変わっていない。更新時は既存の ID とケースの対応が変わっていない