テスト計画書（Test Plan）

テスト計画書は、特定のリリース、プロジェクト、機能に対してテストをどのように行うかを記述したものです。何が範囲内で何が範囲外か、どの種類のテストを適用するか、誰が何を担当するか、どこで実行するか、いつ行うか、そしてチームがどうやって完了を判断するかを定めます。テストに関する QA、開発、プロダクトの間の合意事項であり、実行開始前に文書化されます。IEEE 829 規格（現在は ISO/IEC/IEEE 29119-3 に置き換えられています）が古典的なテンプレートです。

役立つテスト計画書に含まれるもの

• 範囲（スコープ）: 範囲内の機能、そして同じくらい重要な、明示的に範囲外とするもの。
• アプローチ: テストレベルとテストの種類（ユニット、API、UI、性能、セキュリティ、アクセシビリティ）、何を自動化し何を手動で行うか。
• 環境とデータ: どの環境を使うか、テストデータをどう作成・マスキングするか、サードパーティのサンドボックス。
• 開始基準: テストを始める前に満たすべきこと。たとえば「ビルドがステージングにデプロイされ、スモークテストがグリーン」。
• 終了基準: 「完了」の意味。たとえば「未解決の Critical・Major の欠陥がなく、P1 シナリオがすべて合格し、回帰テストスイートがグリーン」。
• リスクと緩和策: たとえば「決済サンドボックスが不安定なため、機能テストではスタブを使い、本物のサンドボックスに対する E2E チェックを 1 日 1 回実行する」。
• 役割、スケジュール、成果物: 誰が何をテストするか、主要な日程、どのレポートを作成するか。

テスト計画とテスト戦略の違い

テスト戦略は、製品や組織に対する高レベルで長期的なアプローチです。テストの原則、レベル、ツール、標準を定めます。テスト計画は、その戦略を 1 つのリリースやプロジェクトに適用し、具体的な範囲、日程、担当者を定めたものです。多くのアジャイルチームは、軽量な戦略ページを 1 つ用意し、リリースやエピックごとに短い計画を作っています。

よくある間違い

• 誰も読まない 40 ページの文書を書く。 アジャイルチームでは、2 スプリント目には古くなっている網羅的な計画より、最新に保たれた 1 ページの計画のほうが優れています。
• 曖昧な終了基準。 「テスト完了」は測定できません。条件を明記しましょう。
• 範囲外のセクションがない。 明記されていない除外事項は、リリース後の言い争いの種になります。