今回は IEEE29119 part3 の テスト計画 (Test Plan) をベースにテスト計画に何を書くと良いかについてまとめてみました。 IEEE829-2008 と似ている部分もありますが…微妙に異なるようです。
概要
識別番号
ドキュメントを一意に特定するバージョンを付与します。 バージョンの付け方は セマンティックバージョニング が参考になると思います。
発行団体
テスト計画ドキュメントを発行、責任を持つチームについて記載します。いわゆるドキュメント作成者の名前を書くのが一般的な気がします。
承認権限
いわゆるレビュアー、承認者を記載します。
変更履歴
ドキュメントが発行されてからのすべての履歴を記載します。
イントロダクション
ドキュメントに関する以下のような情報を記載します。
- 範囲
- 参照
- 用語
範囲
ドキュメントが対象とする範囲（含むもの、含まないもの、前提、制限など）を明記します。
参照
システム、ソフトウェア、テストに関するドキュメントの参照先を記載します。 記載する際は社内資料と社外資料を分けて記載します。
用語
ドキュメント中で利用する単語、略語などを列挙します。
テスト条件
サブプロセス
テスト計画に関連するサブプロセスを定義します。
テスト項目
テスト対象とするコンポーネント、モジュールを列挙します。
テスト範囲
上記のテスト項目で対象として取り上げたコンポーネントやモジュールでテストを行う機能を列挙します。 また、テストを行わない機能についても列挙しておきます。
前提と制約
テスト実施を行うにあたっての前提や制約があれば記載します。 時間、コスト、スキル、アクセス権限、ツール、環境など。
ステークホルダー
ステークホルダーの一覧とテストへのかかわり方を記載します。 また、各ステークホルダーとのコミュニケーション方法についても検討します。
コミュニケーション
テスト実施期間中のコミュニケーション方法について記載します。 定例や関係各所への報告のタイミングなど。
リスク登録簿
テスト実施にあたってのリスク洗い出しを行います。 よくあるリスク洗い出しと同様に「インパクト」と「発生確率」でリスク判定を行います。 リスクは「製品」と「プロジェクト」の2観点で洗い出します。
製品リスク
「製品」に関するリスクを洗い出します。 テスト対象製品のデグレ、性能など。
プロジェクトリスク
「プロジェクト」に関するリスクを洗い出します。 リソースやスケジュールなど。
テスト戦略
サブプロセス
テスト実施するための必要なサブプロセスを定義します。 イメージ的には何をやらなければいけないかタスク分割していったツリーを作る感じでしょうか。 タスクについては後の節で記載するのでここでは大枠だけ記載します。
成果物
テスト実施した結果作られる成果物を定義します。 大まかには以下のようなものがあるかと思います。
- テスト計画
- テスト設計
- テストケース
- テスト実施手順
- テストデータ要件
- テスト環境要件
- 不具合報告
- テスト実施結果報告
- テスト完了報告
設計技法
どのようなテスト技法（境界値、デシジョンテーブル、状態遷移など）を適用するか定義します。
完了基準
何をもってテスト完了とするかを定義します。 テストカバレッジが一定以上となっており検出された不具合が一定数以下まで解消している、など。
収集するメトリクス
テスト実施時に収集するメトリクスを定義します。
テストデータ要件
テスト実施するために必要なテストデータ要件を記載します。 ここではサブプロセスで使われるものすべてに対して記載しておきます。
テスト環境要件
テスト実施するために必要なハードウェア、ソフトウェア、ツール、データベース、人材、環境などを記載します。
再テストおよび回帰テスト
どの回帰テストを行うか定義します。
テスト中断および再開条件
テスト毎または全体を通して中断および再開する条件があれば記載します。 人命危害やデータ損失など大きな問題が出そうな場合を想定した条件になると思います。
例外
各テスト計画はプロジェクトのテスト計画や品質保証に従って作成されます。 それらに則らない例外的なものがあればその内容と承認者について記載しておきます。
テストタスクおよび見積もり
テスト実施に必要なすべてのタスクを洗い出します。 また、各タスクの工数も見積もっておきます。
実施メンバー
役割、タスク、責任
テスト実施に関わる各チームのリーダー、サブリーダー（サポート役）について記載します。 また、各テスト項目に対する責任についても割り当てを行います。 各メンバーの必要期間についても記載します。
雇用の必要性
追加のテスト実施要員が必要かどうかを記載します。 いつ必要で、一時的でよいのかパートなのかフルタイムなのか、必要とするスキルは何かなどを明らかにします。
トレーニングの必要性
テスト実施メンバーとして必要なスキルを明らかにし、必要なトレーニングが何であるかを明確にします。
スケジュール
テスト計画上のマイルストーンを定義します。 テスト実施結果を開発チームや関連部署へ報告する期日をまとめておきます。 マイルストーンは利用可能なリソースや制約を踏まえて見積もります。
最後に… このブログに興味を持っていただけた方は、 ぜひ 「Facebookページ に いいね！」または 「Twitter の フォロー」 お願いします！！