D9: テスト観点一覧

遵守すべき重要ルール

1. 確かめる事柄と結果を分けて記載する: テスト観点は体言止めで、確かめる事柄の名前を記載する。期待値は「〇〇であること」「〇〇できること」の1つの結果にする。成否が別々に分かれる結果は、観点を分けて記載する。どちらにも関数名・変数名など内部実装の用語は使わない。
2. 具体値を記載しない: テスト観点と期待値のどちらにも、境界の値・区分値・件数などの具体値は記載しない。どの値で確かめるかはテスト仕様書が決める。状態が移る行の期待値には、遷移先の業務状態の名前を記載する。
3. 1行に1つの観点だけを記載する: 1つの要件から複数の観点が生まれるなら行を分け、同じ意味の観点を重複させない。
4. 計画書で決めた範囲の外に出ない: 観点は計画書の対象スコープについてだけ洗い出し、テスト技法は計画書のテスト設計技法でそのテストスコープに挙げたものだけを使う。対象外のスコープと非機能テストの観点は作らない。
5. 上流の成果物を直さない: 上流の漏れや誤りに気づいたら、直さずにユーザーへ伝える。
6. ID を振り直さない: 採番済みの TVP-* と行の対応は変えず、欠番も再利用しない。表記は最大番号の桁数で先頭を0埋めする。2桁なら TVP-01、3桁なら TVP-001 とする。

インプットする成果物

成果物のパス	内容
docs/D8.test-plan/overall-test-plan.md	全体テスト計画書。テストタイプを、業務シナリオの観点の要否判断に利用
docs/D8.test-plan/system-test-plan.md	システムテスト計画書。テストスコープとテストアイテムと優先度を、観点の対象の選定とテストアイテム・優先度の引き継ぎに利用。適用するテスト技法を、観点の補完に利用
docs/D1.business-requirements/user-story-list.md	ユーザーストーリー一覧。参照元のユースケースの関連 US が、一覧の全 US-* を含むことの確認に利用
docs/D1.business-requirements/use-case-list.md	ユースケース一覧。観点の参照元と関連 US の確認に利用。業務シナリオの行では、トリガと主要価値を単位と期待値に利用
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-perspectives.md	テスト観点一覧

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

テンプレートのパス	内容
.claude/skills/d9-test-perspectives/template.md	テスト観点一覧のテンプレート

処理

1. 分岐する

• もし docs/D8.test-plan/system-test-plan.md が無いなら、システムテスト計画書が先である旨を伝えて終了する。
• もし docs/D9.test-design/test-perspectives.md が無いなら、§2（新規作成）に進む。
• それ以外なら、§3（更新）に進む。

2. 新規作成

2.1 テストスコープと画面の全体像を列挙する

計画書のテストスコープから、対象の STPLAN-SCOPE-* とテストアイテムと優先度を並び順に記載する。優先度は 高／中／低 だけを取り、計画書の 【要確認】 は除く。それぞれに紐づく機能・バッチ名を同じ表から引き、その機能・バッチ名に対応する画面の名称を画面一覧から引く。バッチ一覧が無いときは BATCH-* は無いものとして扱う。画面設計書が無いときは、画面一覧・画面遷移図・シーケンスから観点を記載し、参照元には使った成果物を記載する。

2.2 テストスコープごとに観点を記載する

2.1 で列挙した順に、1つのスコープの行を記載し終えてから次のスコープに進む。画面設計書と C4モデル レベル2シーケンスは、そのスコープに関わるものだけを読む。

• テストアイテム、テストスコープ、機能・バッチ名、画面名、優先度: 2.1 で列挙した値を、そのスコープの全行に記載する。優先度は計画書の 高／中／低 だけを記載し、【要確認】 は転記しない。画面を伴わないスコープの画面名は「—」とする。
• 観点分類の当てはめ方:
  • 対象の探し方: 画面なら入力項目・ボタン・表示領域、バッチなら処理のステップ、外部連携なら受け渡すデータに着目する。
  • エラーの扱い: 異常時の振る舞いは独立した分類を作らず、各分類の中に含める（エラーメッセージの表示は「入力・バリデーション」に含める）。
  • 用語の統一: 分類はプロジェクトに合わせて増減してよいが、全体で同じ分類名を使う。
• 観点分類ごとに要否を決める: 次の分類を上から順に検討し、そのスコープに当てはまるものだけを観点にする。
  • 画面表示: 表示される情報が仕様どおりであること。並び順、絞り込みの結果、0件時の表示、上限を超えたときの表示に加え、操作した直後の見た目の変化も含む。
  • 画面操作: 操作によって画面遷移図のとおりに遷移すること。条件に応じて操作の可否（ボタンが押せる・押せない等）が切り替わること。
  • 入力・バリデーション: 正常な値を受け付け、不正な値はエラーメッセージを出して弾くこと。
  • 状態遷移: 操作や処理によってデータの状態が変わること、または変わらないこと。
  • データ保持: 画面での即時の反映ではなく、後から画面を開き直しても処理の結果が残っていること。画面名は開き直す先の画面とする。
  • 排他制御: 複数人が同時に操作してもデータが壊れないこと。上流に同時操作時の定義がある場合だけ記載する。
  • 外部連携: 外部システムと意図したデータを送受信できること。C4モデル レベル2 の連携方式が非同期なら、処理の遅延・順序の逆転・再送も観点にする。
  • ファイル入出力: 取り込む、または出力するファイルの内容と形式が仕様どおりであること。
  • ログ出力: 処理の正常・異常の結果が、運用で追跡できる形で記録に残ること。
• テスト技法: その観点に該当するものを記載する。無ければ「—」とする。
• テスト観点、期待値、参照元: 要否を決めた観点を、確かめる事柄と観測できる結果に分けて1行に記載する。根拠にした成果物とその中の箇所を参照元に記載する（「画面設計書 注文登録画面 入力項目」等）。その観点のユースケースも記載する。
• 前提条件: その観点を確かめる前の状態を、業務で使っている状態の名前で1文にする。画面名と操作の手順は記載しない。ログイン済みのような自明な前提は記載しない。同じ前提条件が続いても省略しない。
• 同じ性質のものはまとめる: 確かめる事柄が同じなら、対象が複数あっても1行にする。必須項目が10個あっても、テスト観点は「必須項目の未入力」、期待値は「エラーとなり受け付けないこと」の1行にし、個々の項目への展開はテスト仕様書で行う。
• 重なりを解く: 同じ操作について複数の分類で行ができたら、確かめる事柄を見比べ、同趣旨なら1行にまとめる。

2.3 業務シナリオの観点を記載する

計画書のテストタイプ（差分が無ければリンク先の全体テスト計画書）に業務シナリオを通しで確かめるテストがあるなら、ユースケースごとに1行を記載する。全体テスト計画書が無く、システムテスト計画書もテストタイプを「全体テスト計画に準拠」とだけ記載しているときは、業務シナリオの行は記載せず、その旨をユーザーに伝える。対象のテストスコープを1つも通らないユースケースは記載しない。観点分類は「業務シナリオ」、テスト技法は「—」とし、行は末尾にまとめる。

• テストアイテム、テストスコープ、機能・バッチ名、画面名: そのユースケースに対応する機能・バッチを機能一覧とバッチ一覧から引き、そのスコープと名称をすべて記載する。テストアイテムは、またがるスコープの計画書の値を記載する。同じなら1つにする。画面名は、そのユースケースに対応する画面を画面一覧から引き、C4モデル レベル2シーケンスで通る順に記載する。
• 優先度: またがるスコープの中で最も高い優先度にする。比べるのは 高／中／低 だけで、計画書の 【要確認】 は除く。
• テスト観点、期待値、参照元: ユースケースのトリガから主要価値に至る流れを、始まりと終わりがわかる体言止めでテスト観点に記載する。期待値には、その主要価値が得られたことを「〜こと」で記載する。参照元にはユースケースと、そのシーケンスを記載する。
• 前提条件: シナリオを始める前に満たしておく状態を記載する。

2.4 仕上げる

TVP-* を上から通し連番で振り、最大番号の桁数で先頭を0埋めする。そのあと「完成時のセルフチェック」を実施する。

3. 更新

• インプットした成果物で変わった箇所に関わる行を §2 の手順で見直す。新しい観点には最大値の次の ID を、既存と同じ桁数で振る。桁が増えたときは、既存の ID も同じ桁数に揃える。不要になった観点は行を削除する。
• もし観点を追加・削除・変更したなら、docs/D9.test-design/test-specification.md と docs/D9.test-design/test-data-requirements.md の見直しが必要になる旨をユーザーに伝える。

完成時のセルフチェック

• 計画書のテストスコープの対象の STPLAN-SCOPE-* がすべて、いずれかの行のテストスコープに現れている
• 各行のテストスコープに、計画書に無い STPLAN-SCOPE-* が現れていない
• 各行のテストアイテムと機能・バッチ名が、そのテストスコープについて計画書が定めた値と一致しており、画面名を記載した行は、その名称が画面一覧にある
• 各行のテスト技法が計画書のテスト設計技法でそのテストスコープに挙げたものであり、挙げたもののうち観点が1つも無いものがない
• 同じ意味の観点分類に、表記の揺れた語（「入力・バリデーション」と「入力チェック」等）が混在していない
• 業務シナリオを除き、各行の優先度が、そのテストスコープについて計画書が定めた優先度（【要確認】 を除く）と一致している。優先度列に 【要確認】 が付いていない
• 全行の前提条件・期待値・参照元が埋まっており、「同上」等で省略されていない。前提条件は始まる前の状態で、画面名が無い
• 1行に1つの観点だけが記載され、機能・バッチ名と前提条件が同じ行および同じ画面名の行の中に、テスト観点が同趣旨のものが無い
• テスト観点が体言止めで確かめる事柄の名前になっており、期待値が1つの結果で「〜こと」で終わっている。成否が別々に分かれる結果が1つの期待値に入っていない。どちらにも内部実装の用語と、境界の値・区分値・件数などの具体値が使われていない。状態が移る行の期待値には、遷移先の業務状態の名前がある
• 前提条件が1文で、画面名と操作の手順が無い
• 対象のテストスコープを通るユースケースがすべて、いずれかの行の参照元に現れている
• 参照元に現れたユースケースの関連 US に、ユーザーストーリー一覧の全 US-* が現れている
• 性能・負荷・セキュリティのような非機能テストの観点が混ざっていない
• 参照元に挙げた成果物がインプットする成果物のいずれかであり、参照元に記載した SCR-*・FUNC-*・BATCH-*・UC-* が上流に存在する
• TVP-* に重複が無く、最大番号の桁数で先頭が0埋めされている。業務シナリオを除く行が計画書のテストスコープの並び順で、同じスコープの中は観点分類の並び順になっており、業務シナリオの観点が末尾にまとまっている。更新時は既存の ID と観点の対応が変わっていない