IEEE829-2008 Standard for Software and System Test Documentation に記載されている内容をベースに、テスト全体計画 (Master Test Plan) でどのようなことを記述すると良いかをまとめてみました。 以下の「目次」は IEEE に従って記載していますが、内容についてはWebアプリケーション開発を前提にかなり内容を仕立て直しています。 オリジナルは IEEE 829-2008 をご参照ください。
概要
文書識別番号
ドキュメントバージョンを一意に特定できる番号を記載します。 日付、連番、ステータス（ドラフト版、レビュー版、修正版、最終版）などを記載するのが一般的でしょうか。 もし連続したバージョン番号を振るのであれば セマンティックバージョニング が参考になるか思います。
対象範囲
ソフトウェアテストの目的、目標および実施範囲について記載します。 実施範囲としては、テスト範囲に含む仕様、含まない仕様、前提、制約についても記載します。
参考資料
必要な参考資料をすべて列挙します。 参考資料とするのは内部資料、外部資料に関わらずすべて列挙します。 以下に外部資料および内部資料の例をあげます。
外部資料の例として以下のようなものがあります。
- 外部資料
- 法律
- 規制
- 標準
- 内部資料
- プロジェクト計画
- 品質管理計画
- 構成管理計画
システム概要
スクラッチ開発（新規のパッケージ開発含む）であれば、テスト対象システムの業務目的、主要な機能について記述します。 パッケージ開発やエンハンス開発であれば、テスト対象（手を加えている箇所）の要件概要も記載しておくのが良いと思います。 別資料がある場合は別資料への参照を記載しておくことで代用もできます。
テスト概要
テスト実施に必要な以下のような内容を記載します。
- 推進体制
- テスト日程
- 完全性レベル
- リソース
- 責任
- ツール、テスト技法、手順、メトリクス
推進体制
テストプロセスにおける開発、プロジェクト管理、品質保証、構成管理など他チームの関わりを記述します。 起票された不具合の解決方法、テスト仕様およびテストプロセスの承認など、テストチームのコミュニケーション方法もここに含みます。
- 体制図
- コミュニケーション方法
- 作業フロー
- テスト仕様書作成から承認までのフロー
- テスト実施からレポート作成、承認までのフロー
- 不具合起票から解決までのフロー
テスト日程
プロジェクトライフサイクル中のマイルストーンについて記載します。 プロジェクトの全体スケジュールを踏まえて、各テストの開始終了、別チーム（品質保証、構成管理など）へのフィードバック期日があればその日程などをマイルストーンとして定義しておくと良いと思われます。
完全性レベル
「完全性レベル」とは、障害発生したときシステムを利用するユーザーに対してどれくらいの影響度があるか（致命的（人命にかかわるレベル）なのか、重大な損害をこうむるレベルなのか…）の定義のようです。 ここで定義するシステムの完全性レベルによって作成するドキュメントの種類を変えます（＝ユーザーへの影響度が大きければ多くのドキュメントを準備して万全の体制を整えますが、あまり影響度が大きくないようであれば割愛することを検討します）。
リソース
リソースと言われると「人」をイメージしてしまいがちですが…実施メンバー以外に、環境（放射線や電磁波を使うようであれば特殊な環境が必要）、機材、ツール、特別な手続き（セキュリティ、アクセス権、ドキュメントなど）についても記載します。
責任
テストタスク毎に主担当と副担当（サポート役）を決めます。 イメージ的にはPMBOKで言うところの RACIチャート を作る感じでしょうか。 この節は概要なのであまり細かく書かずに主だったタスクのみにフォーカスして記載するのが良いと思われます。
ツール、テスト技法、手順、メトリクス
テスト実施をするために必要なドキュメント、ハードウェア、ソフトウェア、テストツール、テスト技法、手順、メトリクスについて記載します。 また、各ツールやテスト技法、手順に関する習得、サポート、必要な資格についても記載します。
全体テスト計画詳細
テストプロセスの定義
WBS (いわゆるガントチャート) の作成と各タスクの定義を行っていきます。 主だったタスクリストのサンプルと各タスクの定義で記載する観点について以下に載せます。
タスクリスト
- 要件定義
- 受入テスト計画
- 総合テスト計画
- 設計
- 受入テスト設計
- 総合テスト設計
- 結合テスト計画/設計
- 単体テスト計画/設計
- 実装
- 受入テストケース/実施手順
- 総合テストケース/実施手順
- 結合テストケース/実施手順
- 単体テストケース/実施手順/実施/結果報告
- テスト準備状況の確認
- テスト
- 結合テスト実施/結果報告
- 総合テスト実施/結果報告
- 受入テスト実施/結果報告
- リリース
- リリース実施手順/実施/結果報告
タスク定義のひな形
| 項目 | 説明 |
|---|---|
| タスク名 | タスク内容が分かるような名称を定義します。 |
| 内容 | 各タスクの詳しい実施方法、進め方について記載します。 テスト実施結果であれば評価方法についても記載します。 |
| インプット | 必要となるインプット（どのタスクのアウトプットを利用するか）について記載します。 |
| アウトプット | タスクのアウトプットを定義します。 タスクのアウトプットは他のタスクのインプットとなります。 |
| スケジュール | 各タスクのスケジュールを記載します。開始または完了、必要なインプットの受領、アウトプットの提供といったマイルストーンを組み立てます。 WBSを作成するのであれば、スケジュールはその中に含まれるので個別に記載する必要はなくなります。 |
| リソース | タスク実施に必要なリソース（ツール、設備、機材、事前トレーニングなど）を定義します。 |
| 前提と制約 | テストタスクを実施する前提条件および制約を記載します。 |
テスト文書要件
作成するドキュメントの一覧およびそれらテストドキュメントに関する、目的、フォーマット、目次などを記載します。 作成されるドキュメントとしては以下のようなものが考えられます。
- 全体テスト計画
- 個別テスト計画（受入テスト計画、総合テスト計画…など）
- テスト設計
- テストケース
- テスト実施手順
- テストログ
- 不具合報告
- テスト結果報告
- 総合テスト結果報告
テスト管理要件
一口に「管理」といってもいろいろありますが…定義したメトリクス（進捗、品質）の推移、不具合の管理でしょうか。 ここでは、管理対象とするメトリクスとその拾い方、不具合報告および解決のプロセス、例外を許すのであればそのポリシーなどを定義しておきます。
- 不具合の検出から解決までのフロー
- テスト進捗状況の把握（メトリクス）
- テスト実施進捗（ケース消化率、実施効率など）
- 不具合発見状況（不具合検出率、不具合収束状況、不具合目標達成率など）
- 不具合対応状況（不具合対応日数、不具合除去率など）
テスト報告要件
すべてのテスト報告書に関してその目的、目次、フォーマット、受領者、タイミングを明らかにします。 テスト報告には テストログ、不具合報告、中間報告、各レベルテスト報告、 テスト総合報告が含まれます。
一般
用語集
テスト全体計画 (Master Test Plan) で用いられる用語および略語について定義します。
変更履歴
テスト全体計画に対する修正、承認について記載します。 変更履歴には、テスト全体計画 （Master Test Plan） が作成されて以降に発生するすべての変更ログを含めます。 変更履歴はよくある内容なので改めて書くまでもないですが…記載内容としては、ドキュメントID、バージョン番号、変更内容、変更理由、変更日付、変更者、承認日、承認者などを含めます。
最後に… このブログに興味を持っていただけた方は、 ぜひ 「Facebookページ に いいね！」または 「Twitter の フォロー」 お願いします！！