これは何か
テスト戦略書は、プロジェクト全体として「何のために、どんな種類のテストを、どの段階で、誰の責任で行うか」という方針を決める成果物です。
個々のテストの対象や日程は書きません。それはテスト計画・対象一覧（TST-002）の役割です。戦略書は、その計画を作るときの「決まりごと」と「分担の考え方」を先に定めます。
なぜ作るか
- テストの目的（10-01）を、全員が同じ言葉で理解できるようにする
- 段階ごとの役割（10-02）を決め、同じ確認の重複と、どの段階でも確かめない穴を防ぐ
- 複数の会社が関わるとき、どの会社がどの段階・どの種類のテストに責任を持つかの考え方をそろえる
- テストの環境・データ・不具合の扱いの共通の決まりを、計画を作る前に決める
誰が使うか・いつ作るか
- 作る人：一般的には、テスト・品質管理の責任者。開発・連携・運用・業務の各担当が意見を出す
- 承認する人：プロジェクトの責任者（誰が承認するかはプロジェクトによって異なる）
- 使う人：各段階のテスト計画を作る人、テストの環境を準備する人
- 一般的には、要件と全体の設計の方向が見えてきた段階で作り、各社との分担が決まる前に骨格を固めます。大きな変更があれば見直します
CASE FACTFROZEN正本に記載されたアステリア案件の事実
テストの方針に関係する記載
- 約1,500件の要件、約36本のシステム連携、10年分のデータ移行
- マルチベンダー（Vendor A〜D の4社）
- SYS-09 開発・CI/CD基盤。Vendor B / クラウドブリッジの担当範囲に CI/CD が含まれる
- P-010 宮田 直人 — テスト・品質管理リーダー
- AIへ最終委任しないことに「要件確定」「Go / No-Go」「重大障害判断」などがある
アステリア案件のテスト戦略書の中身（テストの種類・段階の分け方・各社の分担）と、作成者・承認した人は、正本に記載がありません。上の人物がこの戦略書を作った・承認したという記載もありません。未確定
主な項目
一般的には、次の項目で構成します。
- 目的と範囲：このテストで何を確かめ、何を確かめないか（対象外のシステムや業務）
- テストの種類：機能、システムのつなぎ目、性能・安全などの非機能、移したデータ、業務での使いやすさ、直したあとの再確認（回帰テスト）など
- 段階と役割：単体・結合・総合・受入などの段階ごとに、どの種類を受け持つか
- 責任の分担の考え方：自社と各社、開発と業務の側が、どの段階に責任を持つか
- 始める条件・次へ進む条件の考え方：条件を決める単位と、決める人（具体の条件は計画で定める）
- 環境とデータの方針：段階ごとの環境、本番に近いデータを使う段階、個人の情報の扱い
- 不具合の扱いの共通の決まり：重大度の分け方（10-05）、記録する場所（TST-003）
- 自動化とAIの使い方の方針：自動で繰り返すテストの範囲、AIに任せてよい作業と任せない判断
- 報告と判断：品質の状況を誰にどう示すか（TST-004）、段階の終わりを誰が判断するか
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 段階と役割の表
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
内容はすべて教材上の架空の例で、アステリア案件の記録ではありません。戦略書では、日程や対象の数ではなく、段階ごとの役割と決まりを書きます。
| 段階 | この段階の役割 | 受け持つ主な種類 | 責任を持つ側（例） | 次へ進む条件の決め方（例） |
|---|---|---|---|---|
| 単体 | 部品が設計どおりに動くことを確かめる | 機能 | 部品を作る会社 | 各社が条件案を作り、テストの責任者が承認 |
| 結合 | システムどうしの受け渡しを確かめる | つなぎ目、相手が止まったときの動き | 連携の両側の会社が共同 | 連携ごとに両側が合意した条件 |
| 総合 | 全体が業務の流れで動き、非機能の目標を満たすことを確かめる | 業務の流れ、非機能、移したデータ | 発注側のテストの担当 | テストの責任者が条件を定める |
| 受入 | 業務として使えるかを、使う側が確かめる | 業務での使いやすさ、例外の場面 | 業務の責任者 | 業務の責任者と定めた終了基準 |
| 全段階共通 | 直したことで、ほかが壊れていないことを確かめる | 回帰テスト | 直した側 | 自動で繰り返す範囲を戦略で決める |
読み方
- テストの種類のそれぞれが、どこかの段階に割り当てられているか（どの段階も受け持たない種類がないか）
- 同じ種類を複数の段階で受け持つ場合、段階ごとに何が違うのかが書かれているか
- つなぎ目のテストの責任が、片方の会社だけに寄っていないか
- 業務の側が参加する段階と、その役割がはっきりしているか
書き方
- テストの目的と、確かめない範囲を決める
- 必要なテストの種類を洗い出す（要件の一覧・連携の一覧・非機能の要件から）
- 段階を決め、種類を段階に割り当てる
- 段階ごとに、責任を持つ側と、条件を決める人を決める
- 環境・データ・不具合・自動化・AIの共通の決まりを書く
- 各社・業務の側に読んでもらい、合意したうえで承認を得る
何を書いてはいけないか
- 個々のテストの対象・日程・担当者の名前（計画書に書く）
- 「必要に応じてテストする」のような、誰も判断できない書き方
- 各社の契約で決まっていない分担を、決まったこととして書くこと
テスト計画・対象一覧との違い
- 戦略書（この成果物）：プロジェクト全体の方針。種類・段階の役割・分担の考え方・共通の決まり。めったに変わらない
- 計画・対象一覧（TST-002）：戦略に沿った具体の予定。どの要件を、いつ、誰が、どの環境で確かめるか。要件の変更に合わせて頻繁に変わる
計画書を読んで「なぜこの段階でこれを確かめるのか」と思ったら、答えは戦略書にあるべきです。
どこを見るか
- テストの目的と、確かめない範囲
- 種類と段階の対応に穴や重なりがないか
- 会社どうし・開発と業務の側の分担
- 次へ進む条件を、誰が決めるか
- 環境・データ・不具合の共通の決まり
赤信号
- 段階の名前だけが並び、各段階の役割が書かれていない
- 結合テストの責任を持つ側が書かれていない
- 受入テストに業務の側がどう関わるかが書かれていない
- 戦略書と計画書の段階の名前や分け方が食い違っている
よくある失敗
- 戦略書を作らず、段階ごとの計画書だけを各社が別々に作る（分担の穴が見えない）
- 他のプロジェクトの戦略書を写し、このプロジェクトの連携や移行の特徴が反映されていない
関係するUnit・成果物・危機演習
- Unit：10-01 テストは何のためにするのか、10-02 小さい単位から全体へテストする、10-03 利用部門が確認するテスト、10-05 障害の重大度をどう決めるのか
- 成果物：TST-002 テスト計画・対象一覧、TST-003 障害管理表、TST-004 品質状況ダッシュボード、TST-006 利用者受入テスト・終了判定報告書
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、戦略書の穴や食い違いを探す下書きに役立ちます。
「次のテスト戦略書の『種類』と『段階』の表を読み、①どの段階にも割り当てられていない種類、②責任を持つ側が空欄の段階、③戦略書と、添付の段階ごとの計画書で、段階の名前や範囲が食い違っている箇所、を挙げてください。分担や条件を提案・決定しないでください。」
REVIEW
- AIが挙げた穴を、人が元の文書で確かめたか
- AIが一般的な分担を、このプロジェクトの決定のように書き足していないか
人間が判断すること
- テストの種類と段階の分け方
- 各社・業務の側の責任の分担
- 次へ進む条件を誰が決めるか
- 戦略書の承認と見直し
いつ使うか
この教材では STAGE 10｜本当に動くことを証明する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この戦略書を読んだ人は、「このプロジェクトでは、どんな種類のテストを、どの段階が受け持ち、誰が何を確かめたら次へ進むのか」を、計画書を見る前に説明できますか？