TM-1.2.1 (K4)システムのテストニーズを分析して、テスト目的を達成するテスト活動およびテスト成果物を計画する。

テスト計画作業の活動期間

そのレベルのテストプロセスの開始時から終了作業が完了するまでプロジェクト全体を通じて継続する。

作業内容

* テスト戦略で特定された使命や目的を達成するために必要な、活動とリソースを特定する
* テスト戦略に応じたテスト計画を立てる
* 採用するテストレベル、テストレベルの目標と目的、使用するテスト技法などのアプローチを規定する
* プロジェクトで使用するメトリクスを収集し追跡する方法を特定する
* テストベース(たとえば要求仕様やリスクなど)、テスト条件、およびそれらを満たすテストの関係を理解する
* トレーサビリティマトリクスで関係を追跡したりする
* スコープを明確に識別する
* 範囲外のフィーチャ、スコープに含むソフトウェアの特定のフィーチャを明確にする
* プロジェクトアーキテクトへ必要事項の確認をする
* 外部とのすべての依存関係、および関連するサービスレベルアグリーメント(SLAs)を識別し、必要に応じて、初期に連絡をとる

テスト戦略に応じたテスト計画の例

* リスクベースドテスト戦略の場合は、リスク分析を使用して、識別したプロダクトリスクの軽減とコンティンジェンシープラン(緊急時対応計画)の支援を行うために必要な活動を軽減できるように、テスト計画作業プロセスをガイドする。
* セキュリティ関連の潜在的欠陥を多数識別した場合は、 セキュリティテストを開発して実行するために、膨大な工数を費やす計画を立てる
設計仕様で深刻な欠陥が日常的に見つかることが判明した場合は、設計仕様の静的テスト(レビュー)を追加する計画を立てる
* システム性能に関するリスクが高い場合は、コードが統合され使用可能になるとすぐに、性能テストを実行する計画を立てる
* 対処的戦略を採用する場合は、探索的テストなどの動的テスト技法のテストチャータとツールを作成する計画を立てる

開発チームの成果物とテストチームの成果物の関係の例

* 開発チームが作成した詳細な設計書が承認された後に低位レベルのテストケース(具体的テストケース)を作成する
* アジャイルライフサイクルの場合は、非公式な情報伝達セッション後にテストを開始する

テストマネージャからプロジェクトアーキテクトへ確認することの例

* 初期のテスト環境仕様の定義
* 必要なリソースの可用性の検証
* 環境を設定する要員にその作業を割り当てていることの確認
* テスト環境をすべて揃えて提供するために必要な作業や、コスト、納品スケジュールの把握を行うための要求事項

外部との依存関係の例

外部グループへのリソース要求があり、他プロジェクト(1 つのプログラム内で活動している場合)は以下の依存関係が例としてあげられる。
* 外部のベンダー
* 開発パートナー
* 開発チーム
* データベース管理者

問題