テスト全体計画といっても何を書いてよいかわからないので、IEEE829-2008 や IEEE29119-part3 を参考に「テスト全体計画」へ書き起こすと良さそうな内容をまとめました。 このレベルのドキュメントをどれくらい書く機会があるのか…という疑問もありますが、必要となったとき考えるのでは遅いので、今回のまとめを作成しました。
ここで取り上げている「テスト全体計画」は「プロジェクト全体を通してどのようなテストを行うかを定義するもの」で、１プロジェクトで１計画作成されるイメージのドキュメントになります。
表紙
一般的な表紙を付けておきます。
文書識別番号
文書が一意に特定できる番号を付与します。 基本的な命名規則はより上位の文書（プロジェクトの全体方針的なドキュメント）で定義されているハズなので、それに従って番号を振っていくことになると思います。 会社ルールまたは部署ルールが決まっていたりもするので確認してみると良いと思います。
変更履歴
表紙には一般的な変更履歴を残します。 以下のサンプルには承認者、承認日が含まれていませんが、必要に応じて追加してください。 このあたりの記載項目は他のドキュメントでも同じです。
変更履歴 の サンプル
| No. | 変更箇所 | 変更内容 | Ver. | 変更日 | 変更者 | 備考 |
|---|---|---|---|---|---|---|
| 1 | システム概要 テスト観点 | 性能観点を追加 | 1.0.1 | 8/20 | 田中 | |
| … | … | … | … | … | … | … |
システム概要
テスト概要へ入る前にテスト対象となるシステムについてまとめておきます。
システム全体像
テスト対象システムの全体像を記載します。
重要機能
先述の「システム全体像」で描いたシステムのうち、重要な機能がどこであるかを記載します。 ここで記載した重要機能はこの後の「テスト項目選定優先度」に反映されます。
何をもって「重要」と定義するかは難しい気もしますが… リスク管理と似たような考え方で「影響度」と「利用頻度」の2軸に分解して考えると良い気がします。 「影響度」がまだ抽象的なのでもう少し分解するとすれば、業務的な観点で「品質」「コスト（金銭的な利益or損失）」「納期」などにどれだけインパクトがあるかを基準にするとよいと思います。
テスト概要
テスト全体に関わる方針をこの章でまとめます。 内容は多岐にわたりますが、基本方針となるので重要な情報が多くあります。
サブプロセス定義
テスト全体計画におけるサブプロセス定義ではどのようなテスト工程を実施するか定義します。 定義されるテスト工程のサンプルをいかに載せます。 「テスト」と言われると「動的テスト（＝実際にアプリを動かして確認するテスト）」をイメージしやすいですが、「静的テスト（＝レビュー）」もテストに含めて考えます。
テスト工程のサンプル
- 要件定義レビュー
- 基本設計レビュー
- 詳細設計レビュー
- ソースコード静的検査、レビュー
- 単体テスト
- 結合テスト
- 総合テスト
- 受入テスト
テスト観点
テスト対象となるシステムまたは機能に対するテスト観点を整理します。 品質特性なども参考にテスト観点を洗い出します。 以下にテスト観点のサンプルを載せます。
テスト観点のサンプル
- 機能
- 正常系
- 異常系
- 組合せ
- 非機能
- 性能
- セキュリティ
- ユーザビリティ
- 回帰
テスト項目選定優先度
テスト項目を作り始めると観点や組合せが多いため際限なく膨らみます。 そのようなときに何を基準として選定していくかの優先度をここで定義しておきます。 基本的には前述の「重要機能」で取り上げた箇所を中心に、機能の重要度と利用頻度を観点にテスト対象を選定することになると思います。 優先度の付け方のサンプル図を以下に記載します。
あくまで個人的な意見ですが… 「利用頻度が高く重要度（命に係わる、金銭的な損失に関わる…など）が高い機能」が最も優先度が高いのは明らかですが、 Webアプリケーション開発だと「利用頻度が高く重要度が低い機能」と「利用頻度は低いが重要度が高い機能」でどちらを優先するかというと「利用頻度が高く重要度が低い機能」を優先します。 人の目につきやすい機能が正しく動いていた方が「当たり前品質」を保つことにつながる、つまりユーザー離れを防ぎやすいと思います。
テストスケジュールサマリ
開発全体およびテスト実施に関するマイルストーンを整理します。 開発工程上の開始/完了日付や、設計情報のインプットが必要な日付、テスト実施完了報告を行う日付などがマイルストーンになると思います。 前述のマイルストーンは一覧でも良いですが、時系列に並べた以下のような図を描いた方が分かりやすいと思います。
テストスケジュールのサンプル
リソースサマリ
人、環境（サーバー、クライアント）、データなど必要なリソースを記載します。
人はテスト工程ごとにおおよその工数を見積もります。
環境はテストを並列実行するかどうかを踏まえて必要な環境数を見積もります。 例えば結合テストにおいて機能テスト、性能テスト、脆弱性テストを同時にはできないので3環境ないし実施時期をずらすことを考えます（1環境で時期をずらす場合は環境のバックアップ、リカバリ、構築の時間も忘れずに！）。
データ観点では受入テストで本番相当のデータを持ってくるのであれば個人情報のマスキング、抜き出すことに関する手続きなどを考えておく必要があります。
体制、ステークホルダー
開発、テスト、関係各社をまとめた体制図を描きます。 以下にいくつかパターンを記載します。
体制図 (会社レベルの概要図) サンプル
体制図 (会社をまたぐ内部も含めた概要図) サンプル
体制図 (自社内のみの概要図) サンプル
コミュニケーション
前述の体制図で引かれた線の数だけコミュニケーションが存在します。 それぞれに対して「定例（進捗報告）」、「不具合報告」、「障害対応」、「課題対応」などをどのような方法で対応するか決めておきます。 ちなみにコミュニケーション手段は以下のようなものがあります。 どのメンバーに対してどのような頻度でどのコミュニケーションを取るかを定義します。
コミュニケーション手段の例
- 相互型コミュニケーション
- 対面打合せ
- 電話会議
- テレビ会議
- チャット
- BTS (Bug Tracking System)
- プッシュ型コミュニケーション
- メーリングリスト
- プル型コミュニケーション
- 掲示板
責任
テストタスクに関する責任の所在を明らかにします。 RACIチャートを作るとわかりやすいと思います。 以下にサンプルを載せます。
テストタスク RACIマトリクス サンプル
| オーナー | マネージャー | リーダー | メンバー | |
|---|---|---|---|---|
| 進捗 | A | R | ||
| 品質 | A | R | ||
| 課題 | A | R | ||
| テスト計画 | A | R | ||
| テスト設計 | I | A | R | |
| テストケース作成 | I |
A | R | |
| テスト実施手順書作成 | I | A | R | |
| テスト環境準備 | I | A | R | |
| テストデータ準備 | I | A | R | |
| テスト実施 | I | A | R | |
| 不具合対応 | I | A | R | |
| テスト結果報告 | A/I | A | R |
メトリクス
テスト実施中に収集するメトリクスを定義しておきます。 主には進捗（テスト実施、不具合対応）と品質（アプリ自体の品質、テストケースの品質）になるかと思います。
メトリクス の サンプル
- 進捗（テスト実施）
- テストケース消化率
- 累積不具合件数（信頼度成長曲線）
- 進捗（不具合対応）
- 不具合除去率
- 不具合対応日数
- 品質（アプリケーション）
- 機能別不具合検出累積数
- 重要度別不具合検出累積数
- 原因別不具合検出累積数
- 品質（テストケース）
- 不具合発見率
不具合管理
不具合の発見から解決までのプロセスを定義します。 不具合報告方法はBTSへ起票かエクセルへ起票と言ったところでしょうか。 不具合解決のプロセスサンプルは以下に載せます。 大きなプロジェクトであれば、各プロセスについて具体的な手順（例えば不具合報告を起票するとき書いてほしい内容など）まで書いておいた方が無難かもしれません。
不具合対応フロー の サンプル
リスク管理
テスト実施に関するリスク管理を行います。 リスクの洗い出し、評価（発生確率と影響度の設定）、優先度の確定、対策の検討を行います。
リスク管理 の サンプル
| No. | リスク内容 | 発生率 | 影響度 | 優先度 | 対応内容 |
|---|---|---|---|---|---|
| 1 | 結合テスト開始時までにモジュールAが完成しない | 90% | 60% | A | モジュールAに関する結合テスト実施スケジュールを後ろ倒しにしておく。 |
| 2 | … | … | … | … | … |
自動化、ツール
テスト自動化ツールやログ収集ツール（画面キャプチャをとるツール）など、利用するツールがあれば記載します。 以下にいくつか例を載せます。
テスト自動化ツール の 例
- JUnit
- Selenium
- Jmeter
- Jenkins
サブプロセス定義（個別定義）
前述「サブプロセス定義」で定義したプロセス単位に作成します。 内容的に前述の内容と被る部分が多くあります。 開発アプリケーションや要件によって内容が変わってくるので、必要に応じて記載または省略を行ってください。
開始基準、完了基準
テスト開始基準とテスト完了基準を決めておきます。 特に開始基準については前提や制約も考えられるので、それらも踏まえて明記しておきます。 テスト環境構築とデータ投入はテスト実施に含まれそうな気もしますが…以下のサンプルではテスト前提として記載しています。
結合テスト 開始基準/完了基準 の サンプル
- 開始基準
- テスト対象モジュールすべての単体テストが完了しておりすべての障害が解消していること
- 機能テスト環境の構築が完了していること
- テスト実施に必要なデータ投入が終わっていること
- 完了基準
- 実施予定の結合テストがすべて完了していること
- 発生した不具合がすべて解消していること
テスト観点
基本は前述の「テスト観点」でも記載しているので、ここでは各テスト工程別に気にする観点があれば記載します。 ここでは前述と内容が被るので詳細は割愛します。
テスト環境
テスト実施環境について記載します。 単体テストは不要かもしれませんが…結合テスト以降については環境定義が必要になってきます。 以下にサンプル図を載せます（本当はIPアドレスも記載しておくと良いかもしれません）。
結合テスト環境 の サンプル
ドキュメント
作成するドキュメントについて定義します。 各テスト工程も似ていると思います。 以下にサンプルを記載します。
ドキュメント の サンプル
- テスト計画
- テスト設計
- テストケース
- テスト実施手順
- テストログ
- 不具合報告
- テストケース実施結果報告
- テスト完了報告
収集メトリクス
前述「メトリクス」とほぼ同等になるかと思います。 ここでは前述と内容が被るので詳細は割愛します。
回帰テスト
新規開発でなく改修案件であれば回帰テストについて考えます。 どの機能のどの範囲をテストするか定義します。 ここでは機能観点一覧を作成すると良いと思います。
一般
以降は補足情報を載せます。
用語集
テスト計画で利用する用語、略語についてまとめます。 以下に用語集のサンプルを載せます。
用語集 の サンプル
| 用語 | 説明 |
|---|---|
| LTP | Level Test Plan の略。個別テスト計画書のこと。 |
| 不具合 | 障害（アプリケーションの障害、テストケースの障害）と誤報告の切り分けができていない課題。 |
| … | … |
参考資料
内部ドキュメント、外部の参考資料など、テスト全体計画を作成するために必要になった関連資料をまとめておきます。
参考資料 の サンプル
- 内部
- プロジェクト企画書
- 品質保証計画
- 外部
- IEEE 829-2008
- IEEE 29119 part3
今回はかなり重厚長大なポストとなってしまいました… 分割するわけにもいかなかったので仕方ないのですが、目次を利用して効果的に参照していただければと思います。
最後に… このブログに興味を持っていただけた方は、 ぜひ 「Facebookページ に いいね！」または 「Twitter の フォロー」 お願いします！！