テスト計画といっても何を書いてよいかわからないので、IEEE829-2008 や IEEE29119-part3 を参考に「テスト計画」へ書き起こすと良さそうな内容をまとめました。
ここで取り上げている「テスト計画」は「個別のテスト計画」に相当するので、「単体テスト計画」「結合テスト計画」「システムテスト計画」といった工程ごとにドキュメントが作成されるものになります。 工程によって必要なもの必要でないものがあると思いますので、必要なものが最低限記載されるよう修正して使っていただければと思います。
表紙
表紙には一般的なものとして「文書識別番号」「変更履歴」を記載しておきます。
文書識別番号
文書を一意に特定できる番号を付与します。 ドキュメント名、日付、バージョンなどを用いて一意に特定できるようにします。
文書識別番号 の サンプル
- 結合テスト計画_20170827_01 （文書名 + 年月日 + 通番)
- 総合テスト計画_1.0.0 （文書名 + バージョン番号）
変更履歴
初版を作成して以降のすべての変更履歴を残します。 変更履歴には主に以下のような項目を残します。
- No.
- 変更箇所
- 変更内容
- 変更日付
- 変更者
- 承認日付
- 承認者
- 備考
テスト内容
作成しているテスト工程のテスト概要についてこの章でまとめます。
テスト対象機能
テスト対象機能を一覧化します。 テスト対象とする機能、テスト対象外とする機能をここで明らかにしておきます。 この次に記載する「テスト観点」とあわせて「機能観点一覧」を作成してもよいと思います。
テスト観点
該当テスト工程においいて前述の機能に対してどのようなテストを行うか明らかにします。 テスト観点なので品質特性を踏まえた記載になっていると良いかと思います。
テスト観点のサンプル
- 機能
- 正常系
- 境界値
- 表示項目
- 遷移（状態、画面）
- 設定（保存、変更、反映）
- 異常系
- 異常値
- エラー処理（ネットワーク、ディスクI/O）
- 異常操作
- 組合せ
- 同時操作
- 割込み動作
- 排他制御
- 正常系
- 非機能
- 性能
- 処理速度
- 連続動作
- 通信帯域
- 大容量
- セキュリティ
- 性能
- ユーザビリティ
- 回帰
テストトレーサビリティマトリクス（テスト追跡表）
上位文書との関連付けを行います。 要件、基本設計とテストケースを関連付けます。
トレーサビリティマトリクス の サンプル
| 要件ID | ユースケースID | テストケース | … | |||
| CS0101 | CS0102 | CS0103 | CS0104 | … | ||
| REQ0100 | UC0101 | ○ | ○ | ○ | … | |
| UC0102 | ○ | … | ||||
| UC0103 | ○ | … | ||||
| REQ0200 | UC0201 | ○ | … | |||
| … | … | … | … | … | … | |
前提と制約
テスト実施を行うにあたっての前提条件や制約条件があれば記載します。 例えば、結合テストであれば前工程の単体テストが終わってないと開始できないでしょうし、テスト実施において環境制約（性能試験なので他からのアクセスはNGなど）があれば記載します。
中断基準と再開基準
テストとは言え、障害が多すぎて進まないとか、これ以上無理にテストを行うとテストデータの破損により次回実施に影響が出るなど テスト実施と障害対応のバランスをどのようにとるかも
例外
テスト対象、テスト観点は上位文書に従って作成しますが、個別テスト設計を作成する中で上位文書の方針とは異なる方針をとる場合、その内容と理由について記載しておきます。 時間的な制約、環境的な制約、機能的な制約など…。
成果物一覧
該当テスト工程で作成する成果物を一覧化しておきます。 ここで一覧化したドキュメントの作成および承認完了が該当テスト工程が完了しているかどうかの判定基準の一つになると思います。 以下に作成するドキュメントの一例を載せます。
成果物一覧のサンプル
- 個別テスト計画（本ドキュメント）
- テスト設計
- テストケース
- テスト実施手順
- テストログ
- 不具合報告
- テスト結果報告
- テスト完了報告
テスト環境
テスト実施を行うにあたっての環境面に関する定義を行います。 主な観点として「必要なデータ」と「必要な設備」という2観点で記載します。
テストデータ要件
テストで利用するデータに関する要件を記載します。 テストデータに複数因子があればテスト観点を踏まえてどの因子を対象にパターン作成するか検討します。 因子水準表はテスト設計で作成すればよいので、ここでは因子の特定までにとどめておきます。
会員データ因子のサンプル
- ユーザーID
- ユーザー名
- 性別
- 年齢
- 郵便番号
- 住所１（都道府県）
- 住所２（市区町村）
- 住所３（番地以降）
- 電話番号（固定）
- 電話番号（携帯）
- メールアドレス
テスト環境/設備/備品要件
テスト実施に必要な環境、設備、備品などについて記載します。 テスト工程にもよりますが、結合テストや総合テストであれば同時並行で複数のテスト観点を実施するのでサーバーも複数必要になったりします（機能の組合せテストを同時にやるためには複数環境必要、機能テストと性能テストは同時に実施したければ複数環境必要…など）。 また、Webアプリケーション開発であれば備品として携帯電話やタブレットなどの実機も必要になるかもしれません。
スケジュール
テスト実施に関わるマイルストーンを定義しておきます。 テスト実施は開発プロジェクトの一部となるので、開発プロジェクトにおける納期についてもあわせて記載しておくと良いと思います。
マイルストーン
「開発プロジェクトにおけるマイルストーン」と「テスト実施におけるマイルストーン」の2観点で整理すると良いと思います。 また、マイルストーンは一覧化されても読み取りづらいので、図示すると伝わりやすいと思います。
- 開発に関するマイルストーン
- 基本設計完了
- 詳細設計完了
- コーディング完了
- 単体テスト完了
- 結合テスト完了
- 総合テスト完了
- 受入テスト完了
- テストに関するマイルストーン
- テスト計画完了
- テスト設計完了
- テストケース作成完了
- テスト実施完了
- テスト結果報告完了
テストタスク
テストを完遂するまでに必要なタスクおよび工数、役割について明確化します。 ここで記載する内容は簡易的なWBSを作るイメージになると思います。
テストタスク一覧、工数見積もり
タスク一覧およびそれぞれのタスクについて工数見積もりを行います。 細かく行なわないまでも概算で見積もりを出しておくことで人員がどれくらい必要かの目安を作ります。
- テスト計画
- テスト設計
- テストケース作成
- テスト手順書作成
- テスト実施
- テスト結果報告書作成
役割、責任
前述のタスク以外に必要な作業カテゴリ（例えば、テスト環境の構築（ネットワーク、サーバー、データベースなど）、データ投入など大きな役割ごと）に担当チームを割り当てておきます。
- テスト設計
- テストケース作成
- テスト環境構築（ネットワーク、サーバー、データベース）
- テストデータ投入
- テスト実施
品質
テスト品質についてまとめます。
メトリクス
テスト実施中に収取するメトリクスについて記載します。
カバレッジ基準
テストケースについてどこまでのカバレッジを満たすべきかをここで定義します。 単体テストであれば C0 / C1 / C2 などと呼ばれるものでしょうか。 結合テストや総合テストであれば条件網羅率を定義することになると思います。
- C0 ： 命令網羅
- C1 ： 分岐網羅
- C2 ： 条件網羅
合否判定基準
各テストケースの合否判定基準を記載します。 基本的には「テストケースを満たす前提および結果が得られること」になると思います。 そもそもですが…「テストケースを満たしていることが誰が見ても明らかになるようなテストケース作成をしておくこと」が前提となります。。
テストケース合否判定基準 の サンプル
- テストケース内容を満たしたテスト前提と実施結果のログが得られていること
テスト完了基準
該当のテスト工程を合格と判断する基準を定義しておきます。 基本的な完了条件は以下になると思います。
テスト完了基準 の サンプル
- すべてのテストケースを実施完了していること
- 重大度が低以外の不具合がすべて解消していること
メンバー
「人」に関する情報を整理します。
必要な人員、期間
前述の「テストタスク一覧、工数見積もり」で算出した必要人員および「マイルストーン」で定義された完了期限をベースにどれだけの要員が必要かを算出します。
必要なスキルセット
テスト実施にあたって必要なスキルがあればここでまとめます。 通常の画面操作だけであれば不要かもしれませんが、データベースへデータ投入したり、Seleniumを使ったり、スマートフォンを利用したりなど特筆すべき必要スキルがあれば人員要件として記載します。
- PL/SQL の作成、実行ができる
- Seleniumを利用した自動テストができる
体制図
テスト実施に関する体制図を作成します。 ここではテスト実施に関わる社内（内部）メンバーに限定した体制図を描きます。 社外（外部）メンバー含めた体制はこの後の「ステークホルダー」にて記載します。
調達の必要性
仮に必要人員が満たせない場合、外部からの調達、外部ベンダーへの委託などを検討します。 やるべきことに対して不足分をここでは整理します。
トレーニングの必要性
人員の中に案件初参画者や若手がいる場合、トレーニングの必要性があります。 調達予定の人員のうちだれに対してどのようなトレーニングをどれくらいの期間で行うかを計画しておきます。
ステークホルダー
組織図
単体テストは内部だけで良いかもしれませんが、結合テストや総合テストであれば外部ベンダーも関わることがあるのでそのような場合は外部ベンダー含めて体制図を作成します。 また、同じ社内でも部署が違うようなケース（企画と開発のような関係）もここで記載します。
コミュニケーション
社内外各所とのコミュニケーション頻度や方法についてまとめます。 ここでは内部向けと外部向けで分けて記載しています。
内部の定例、報告
「メンバー」の「体制図」で定義した体制内での定例や進捗報告の内容についてここで定義します。 実働部隊に近い体制での定例は日次～週次での実施になると思います。 定例以外にも不具合報告のフロー、外部ベンダーへの連絡方法についても整理しておきます。
- 進捗定例
- 不具合報告フロー
- 外部ベンダー問合せフロー
外部の定例、報告
「ステークホルダー」の「組織図」で定義した体制間での定例や進捗報告の内容についてここで定義します。 対外的な報告になるので報告フォーマットがが決まっていれば参照を付けておくと良いと思います。 頻度は週次～マイルストーンまで内部の定例よりもやや長い間隔になるかと思います。
- 進捗定例
- テスト実施完了報告
リスク
テスト実施に関するリスクの特定および対策を検討します。
リスク一覧
プロジェクトに関するリスクは別途管理されているハズなので、ここではテスト実施（計画～完了報告）におけるリスクを洗い出し、その評価まで行います。
リスク対応計画
「リスク一覧」で洗い出されたリスクのうち優先度が高いものについて対応計画を検討します。
一般
本章以降は補足情報をまとめます。
用語集
本ドキュメント内で使用した用語、略語についてまとめます。
参考資料
本ドキュメントに関連する資料があれば社内外に関わらず列挙しておきます。
最後に… このブログに興味を持っていただけた方は、 ぜひ 「Facebookページ に いいね！」または 「Twitter の フォロー」 お願いします！！