#1．概要
テストを実施する上でドキュメントを作成する人は多いと思います。今回その中でもテストの基本となる「テスト計画書」について、以下を中心に説明したいと思います。
- テスト計画書をなぜ作成するのか？
- どうやってテスト計画書を作成すればいいのか？
また、本内容を説明する上でIEEE829をもとに説明したいと思います。
※IEEE829はテストのドキュメントについてまとめた国際規格です。テスト系のドキュメントを作成する場合、よく参考にします。
#2．IEEE829のテスト計画書とは？
IEEE829のテスト計画書には、以下2つのドキュメントがあります。
・マスターテスト計画（全体テスト計画書とも呼ばれ、プロジェクトの最初に作成するもの）
・レベルテスト計画（単体テスト計画書、結合テスト計画書等の段階ごとの計画書のこと）
企業によっては、マスターテスト計画書しか作らなかったり、そもそも計画書を作らないこともあるようです。
今回はマスターテスト計画書を基準として説明いたします（マスターテスト計画書もレベルテスト計画書も、案件全体を対象としているのか一部を対象としているかの違いがあるだけで、本質は2つとも同じです。）
#３．なぜテスト計画を作るのか？
ここが私個人の考えになるのですが、テスト計画書はテスト中にもめごとが起きないように事前に合意しておくことをまとめたドキュメントと考えています。
つまり、過去のもめごとに対する対策がすべてテスト計画書に入っていれば、それがその案件の正しいテスト計画書となります。
例えば、以下のような問題があったとします。
①報告漏れ
Aさん「A機能で不具合が多く出ていることをなぜ報告しないのか！？」
Bさん「え、そういった報告が必要と聞いたことがないのですが…」
②急なテスト範囲の増加
Cさん「ごめん！C機能に重大な欠陥が見つかったから、追加でテストを行って！」
Dさん「え！？もう工数残っていませんよ！！！」
③テスト結果の判断ミス
Eさん「ここ、期待値と違う結果になっているけど、テストではOKとなっている…」
Fさん「あ、特に仕様上問題ないと思いましたので、OKとしました！」
上記のような問題を起こさないために、事前にもめそうな項目をテスト計画書に記載し、合意しておきます。
- ①報告漏れ ⇒報告内容を事前に合意する！
- ②急なテスト範囲の増加 ⇒緊急時の対応を事前に合意する！
- ③テスト結果の判断ミス ⇒テストの判断方法を事前に合意する！
#４．IEEE829-テスト計画書の各項目について
3章をもとにIEEE-829の各項目の意味を簡単にまとめると、以下のようになります。現場の問題と比較しながら各項目が必要不要か判断すれば、自社向けのテスト計画書を作成することができます。
（以下の項目にないものでも、現場の問題から新規に項目を追加してもいいです。）
| 起きている問題 | 対策 | IEEE829での項目名 |
|---|---|---|
| みんなが勝手に資料を更新するので、最新版がわからなくなった！ | 識別番号を決め、更新のルールを決める | 識別番号 |
| どの資料を基に計画書が立てられたのかわからない！ | 計画書のもとになった資料はすべて記載する | 参考文献 |
| 何のためにテストを行うのかわからない！ | テストの目的をきちんと共有する | はじめに |
| テスト対象がコードしかない！ | テスト対象がわかる資料をまとめる | テストアイテム |
| すべてテストすると時間がかかりすぎる！ | テストが必要な部分を決める | テスト対象 |
| 連携する他社のシステムはテストできない！ | テストができないな部分を決める | テスト非対象 |
| 性能試験を忘れていたので、リリース後に障害となった！ | どうテストするのか事前に決めておく | テストアプローチ |
| 期待値と違っているのにテストケースでOKとなっている！ | OKとする条件を決めておく | テスト合否判定基準 |
| 機能の開発が遅れ、全くテストできない！ | テストを中止する条件を決めておく | テスト中止再開基準 |
| 納品されると思ったものが納品されない！ | 納品する成果物を事前に決めておく | テスト成果物 |
| 予定していた作業をテストチームが実施してくれない！ | 実施するタスクを決めておく | テスト作業タスクと担当 |
| テストに必要な環境がテスト開始時に準備されていない！ | いつまでにどんな環境が必要か決めておく | テスト環境 |
| 別会社の問題を自社に押し付けられた！ | 誰がどこまで責任を負うのか決めておく | 責任範囲 |
| 必要な人材がテスト開始までにそろわない！ | どんな人材が欲しいのか、どう育てるのか決めておく | 人員計画・トレーニング |
| 予定の期日にテスト結果が報告されない！ | いつまでに何を報告するのか決めておく | スケジュール |
| 無茶なスケジュールなのに進めようとしている！ | 起きそうなリスクと、リスクが起きた場合どうするのか決めておく | リスクとその対策 |
| テスト計画書に記載したことが守られていない！ | きちんと合意したことを記録しておく | 承認 |
#５．まとめ
テスト計画書はもめごとが起きないように、事前に取り決めをまとめたドキュメントです。裏を返せば、テスト中にもめごとが起きなければ、テスト計画書を作成する必要はありません。
そのため、リリース後でも案外どうにかなるWeb系の案件ではテスト計画書は薄く、逆に基幹系のシステムのような大規模なものは、テスト計画書が厚くなる傾向があります。
（Web系は問題が起きても、「すぐに直してリリースします！」、で何とかなるので。）