テスト計画書の書き方｜範囲と体制と日程の決め方

テスト計画書の書き方を調べている人の多くは、初めてテストの取りまとめを任された、あるいは発注先から計画書を出すよう求められて、何をどこまで書けばよいのか迷っています。結論から言うと、テスト計画書は「何を、どこまで、誰が、いつまでに、どの環境で、どうなったら終わりとしてテストするか」を、関わる人全員がそろえるための文書です。中でも、テストの範囲、体制、日程、終わりの基準の4つが決まっていれば、計画書としての骨格はできあがります。この記事では、テスト計画書の役割と、ほかの文書との違い、書く項目、項目ごとの決め方、目次の見本、よくある失敗を順に説明します。テストの作業を何人かで分担するときに、担当と期限と進み具合を共有できるプロジェクト管理ツールのPinatecaのような道具の使い方にも後半で触れます。

テスト計画書とは何か

テスト計画書とは、ソフトウェアやシステムのテストを始める前に、テストの目的、範囲、方法、体制、日程、終わりの基準などを決めて書き残した文書のことです。テストの進め方の全体像を示す設計図のような役割を持ちます。

テストという言葉からは、画面を操作して不具合を探す作業が思い浮かびますが、その作業を始める前に決めておくべきことはたくさんあります。どの機能を確かめるのか、どの機能は確かめないのか、どのパソコンやスマートフォンで確かめるのか、誰が確かめて誰が結果を判断するのか、いつまでに終えるのか。こうしたことを決めずにテストを始めると、確かめ漏れや、同じ確認の重複、終わりの見えないテストが生まれます。

テスト計画書は、開発する側だけで使う文書ではありません。発注した会社の担当者、プロジェクトの責任者、テストを担当する人など、立場の違う人が同じ前提でテストを進めるための共通の約束ごとでもあります。とくに受託開発では、納品の前にどこまで確かめたかを示す根拠になるため、発注者から提出を求められることがよくあります。

テストの国際的な資格制度を日本で運営するJSTQB（ソフトウェアテスト技術者資格認定）のシラバスでも、テスト計画書はテストプロジェクトの目的、リソース、プロセスを表す文書として位置づけられています。

テスト計画書を作る目的

テスト計画書を作る目的は、テストの質を上げることと、関わる人の認識をそろえることの2つに大きく分けられます。JSTQBのFoundation Levelシラバスは、テスト計画書の役割を次のように説明しています。

テスト計画書は、テスト目的を達成するための手段やスケジュールを文書化する テスト計画書は、実施したテスト活動が、確立した基準を満たすことを保証するのに役立つ テスト計画書は、チームメンバーやステークホルダーとのコミュニケーション手段としての役割を担う 出典: JSTQB「テスト技術者資格制度 Foundation Level シラバス」

ステークホルダーとは、そのプロジェクトに関わる利害関係者のことで、発注者、開発者、利用者などが含まれます。

1つ目の目的であるテストの質を上げることについては、計画を立てる過程そのものに意味があります。何をテストするかを書き出していくうちに、確かめるべき機能の抜けや、準備が必要な環境、足りない人手に気づけます。計画なしで始めたテストでは、これらに気づくのはテストの途中か、最悪の場合は本番の公開のあとになります。

2つ目の認識をそろえることについては、テストの終わり方で意見が分かれる場面を想像すると分かりやすいでしょう。開発する側は「主な機能は確かめたので終わり」と考え、発注する側は「すべての画面を確かめてほしい」と考えていた、というすれ違いは珍しくありません。テスト計画書で範囲と終わりの基準を先に決めて合意しておけば、こうしたすれ違いを防げます。

ほかのテストの文書との違い

テストには、テスト計画書のほかにもいくつかの文書があります。それぞれの役割を知っておくと、テスト計画書に何を書き、何を書かないかがはっきりします。

文書	役割	作る時期
テスト計画書	テスト全体の目的、範囲、方法、体制、日程、終わりの基準を決める	テストの準備の最初
テスト設計書（テスト設計仕様書）	何を確かめるかの観点や条件を整理する	計画のあと
テスト仕様書（テストケース）	確かめる手順、入力する値、期待する結果を1件ずつ書く	設計のあと
テスト報告書	実施した結果、見つかった不具合、残った課題をまとめる	テストの終わり

テスト計画書は、この中で最も上位の文書です。個々の確認の手順までは書かず、テスト全体の方針と枠組みを示します。テスト設計書やテスト仕様書は、テスト計画書で決めた範囲と方法に沿って作られます。

大きなプロジェクトでは、プロジェクト全体のテスト計画書（マスターテスト計画書と呼ばれることもあります）の下に、単体テスト、結合テスト、システムテストなど、テストの段階ごとの計画書を作ることもあります。小さなプロジェクトでは、1つのテスト計画書にすべての段階をまとめるのが一般的です。

テスト報告書は、テスト計画書と対になる文書です。計画書で決めた終わりの基準に対して、実際にどうなったかを報告します。そのため、計画書の段階で終わりの基準をはっきり書いておかないと、報告書でテストが終わったと言えるかどうかを示せなくなります。

テスト計画書に書く項目

テスト計画書に書く項目は、会社やプロジェクトによって違いますが、JSTQBのシラバスでは、典型的な内容として次のものが挙げられています。

• テストの概要：テストの範囲、テストの対象、制約、テストの基になる資料
• テストプロジェクトの前提と制約
• ステークホルダー：役割、責任、必要な教育
• コミュニケーション：連絡の形や頻度、文書のひな形
• リスクの一覧：製品のリスク、プロジェクトのリスク
• テストの進め方：テストの段階、テストの種類、テストの技法、成果物、開始と終了の基準、テストデータと環境の条件
• 予算と日程

テストの基になる資料とは、要件定義書や仕様書など、何が正しい動きかを決めている資料のことです。テストは、この資料に書かれた動きと、実際の動きを比べる作業なので、どの資料を基準にするかを最初に書いておきます。

実際の計画書では、これらの項目を次のような順番の章立てにまとめることが多くあります。

1. はじめに（目的、対象のシステム、参照する資料）
2. テストの範囲（対象と対象外）
3. テストの方針（段階、種類、技法）
4. テストの環境と道具
5. 体制と役割
6. 日程
7. 開始の基準と終了の基準
8. 不具合の扱い
9. リスクと対策
10. 報告と連絡の方法

このあとの節では、それぞれの項目の決め方を順に説明します。

目的と範囲を決める

テスト計画書で最初に決めるのは、テストの目的と範囲です。目的とは、このテストで何を確かめたいのかということ、範囲とは、どの機能や画面をテストし、どれをテストしないかということです。

目的は、「新しく作った予約の機能が、仕様書どおりに動くことを確かめる」「既存の機能に影響が出ていないことを確かめる」のように、短い文で書きます。目的がはっきりしていると、範囲を決めるときの判断の軸になります。

範囲を決めるときは、テストする対象だけでなく、テストしない対象もはっきり書くことが大切です。たとえば、次のように書きます。

• 対象：予約の登録、変更、取り消しの機能。管理画面の予約一覧
• 対象外：決済の機能（外部のサービスを使うため、別の計画で確かめる）、古い版のブラウザ

対象外を書いておくと、あとで「この機能は確かめたのか」と聞かれたときに、計画の段階で合意した内容として答えられます。対象外にした理由も添えておくと、関わる人が納得しやすくなります。

範囲は、使える時間と人手とのつり合いで決めます。すべての機能を同じ深さで確かめるのが理想ですが、現実には時間が足りないことがほとんどです。その場合は、利用者がよく使う機能、お金や個人の情報を扱う機能、不具合が起きたときの影響が大きい機能を優先して深く確かめ、そのほかの機能は主な動きだけを確かめる、といった濃淡を付けます。

テストの段階と種類を決める

範囲が決まったら、どの段階で、どんな種類のテストを行うかを決めます。

テストの段階は、一般に次の4つに分けられます。

段階	確かめること	主な担当
単体テスト	1つ1つの部品（プログラムの単位）が正しく動くか	開発者
結合テスト	部品どうしをつないだときに正しく動くか	開発者、テスト担当
システムテスト	システム全体が要件どおりに動くか	テスト担当
受け入れテスト	利用者や発注者の目で見て使えるか	発注者、利用者

テストの種類は、大きく機能のテストと、機能以外のテストに分けられます。機能のテストは、ボタンを押したら正しく登録される、といった「何ができるか」を確かめるテストです。機能以外のテストは、速さ、たくさんの人が同時に使ったときの動き、セキュリティ、使いやすさなど、「どのくらいうまくできるか」を確かめるテストです。

機能以外の要件は、発注者と開発者の間で決め漏れが起きやすい部分です。情報処理推進機構（IPA）は、機能以外の要件を整理するための非機能要求グレードを公開しており、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に分けて要件を整理できるようにしています。テスト計画書で機能以外のテストを決めるときは、こうした項目に沿って要件を確かめておくと、テストの抜けを防げます。

不具合を直したあとに、直した部分とその周りが正しく動くかを確かめる回帰テストも、計画に入れておきます。回帰テストとは、修正によって、それまで動いていた機能が壊れていないかを確かめるテストのことです。

テストの環境を決める

テストの環境とは、テストを行うときに使う機器、OS、ブラウザ、ネットワーク、データなどのことです。環境があいまいなままテストをすると、実際の利用の場面とずれた結果になります。品質保証の専門会社のAGESTのコラムでも、次のように注意を促しています。

「どの環境でテストするか」を曖昧にしたままテストを行うと、実際の利用シーンとの食い違いが発生しやすくなります。環境を統一したうえでテストを実施するため、テスト計画書には、使用端末・OS・ブラウザの組み合わせを一覧で記入します。 出典: agest.co.jp

環境の一覧は、次のように表にまとめると分かりやすくなります。

区分	機器	OS	ブラウザ
パソコン	Windowsのノートパソコン	Windows 11	Chrome、Edge
パソコン	Mac	macOSの最新版	Safari、Chrome
スマートフォン	iPhone	iOSの最新版	Safari
スマートフォン	Androidの端末	Androidの最新版	Chrome

どの組み合わせを選ぶかは、実際の利用者がどの機器やブラウザを使っているかを基に決めます。すでに公開しているサービスであれば、アクセスの記録から利用の多い組み合わせが分かります。

テストに使うデータも、環境の一部として決めておきます。本番のデータをそのまま使うと、個人の情報が漏れる危険があるため、テスト用のデータを用意するのが基本です。どんなデータを、誰が、いつまでに用意するかを計画書に書いておきます。テストの結果を記録する道具や、不具合を管理する道具も、この節で決めておきます。

体制と役割を決める

体制とは、テストに関わる人と、それぞれの役割のことです。誰が何を担当し、誰が判断するのかを決めておかないと、作業の重複や漏れが起き、判断が必要な場面で止まってしまいます。

テストに関わる主な役割は次のとおりです。

• テストの責任者：テスト全体の計画と進み具合に責任を持ち、終わりの判断をする
• テストの担当者：テスト仕様書を作り、テストを行い、結果を記録する
• 開発の担当者：見つかった不具合を直す
• 発注者や利用者の代表：受け入れテストを行い、仕様の疑問に答える

体制を書くときは、役割ごとに名前を書きます。「テストチーム」のような書き方では、誰に連絡すればよいかが分かりません。

あわせて決めておきたいのが、判断の権限です。不具合が見つかったときに、それを直すのか、次の版に回すのかを誰が決めるのか。仕様書に書かれていない動きを見つけたときに、正しいかどうかを誰に確かめるのか。こうした判断の流れを決めておくと、テストの途中で迷う時間が減ります。

社外の会社にテストの一部を頼む場合は、頼む範囲と、成果物の形、報告の方法を体制の節に書いておきます。発注者がテストに参加する場合は、参加できる日と時間も確かめておきます。

日程を決める

テストの日程は、開発の日程と密接につながっています。開発が遅れるとテストの開始も遅れ、テストの期間が短くなりがちです。テストの期間が削られて品質が下がる、というのは多くのプロジェクトで起きる問題です。

日程を決めるときの手順は次のとおりです。

1. テストの作業を洗い出す：仕様書の作成、環境の準備、テストの実施、不具合の修正の確認、報告書の作成
2. 作業ごとにかかる時間を見積もる
3. 作業の順番と、前後のつながりを決める
4. 公開の日や納品の日から逆算して、作業を日付に割り振る
5. 予備の期間を確保する

見積もりで見落とされやすいのが、不具合の修正と、その確認にかかる時間です。テストで不具合が見つかると、開発者が直し、テストの担当者が再び確かめ、さらに回帰テストを行います。この繰り返しの時間を見込んでおかないと、日程は必ず足りなくなります。

予備の期間は、テスト全体の期間の1割から2割ほどを目安に、最後に取っておきます。予備の期間を作業ごとに分けて持たせると、それぞれの作業がその期間を使い切ってしまいがちです。最後にまとめて取っておくほうが、全体の遅れを吸収しやすくなります。

日程は、開始と終了の日付だけでなく、途中の節目も書いておきます。「仕様書の完成」「システムテストの1回目の完了」など、節目ごとに進み具合を確かめると、遅れに早く気づけます。

開始と終了の基準を決める

テスト計画書の中で特に大切なのが、テストを始める条件と、終える条件です。これを開始基準と終了基準と呼びます。

開始基準とは、テストを始めてよいと判断する条件のことです。たとえば、次のような条件を決めます。

• 前の段階のテストが終わり、重大な不具合が残っていない
• テストの環境とデータの準備ができている
• テスト仕様書の確認が済んでいる

開始基準を満たさないままテストを始めると、テストの途中で環境の不備や、前の段階で直すべきだった不具合に次々とぶつかり、時間を無駄にします。

終了基準とは、テストを終えてよいと判断する条件のことです。たとえば、次のような条件を決めます。

• 計画したテストケースをすべて実施した
• 重大な不具合と、優先度の高い不具合がすべて直っている
• 残っている不具合について、発注者の了承を得ている
• 新しく見つかる不具合の数が減り、落ち着いてきている

終了基準は、できるだけ数字で書きます。「十分にテストした」のような書き方では、終わったかどうかの判断が人によって分かれます。「テストケースの実施率100%」「重大な不具合の残りが0件」のように書いておけば、誰が見ても同じ判断ができます。

不具合の重さの区分も、この節で決めておきます。「重大」「高」「中」「低」などの区分と、それぞれの例を決めておくと、不具合を見つけた人によって重さの判断がぶれません。

リスクと対策を書く

リスクとは、テストやプロジェクトの進み方に悪い影響を与えるかもしれないことです。テスト計画書では、考えられるリスクを挙げ、それぞれに対策を書いておきます。

リスクは、大きく2つに分けられます。

• 製品のリスク：利用者に影響する不具合が起きるかもしれない部分（お金の計算、個人の情報の扱い、新しく作った複雑な機能など）
• プロジェクトのリスク：テストの進み方に影響すること（開発の遅れ、担当者の不足、環境の準備の遅れなど）

製品のリスクは、テストの濃淡を決める材料になります。不具合が起きたときの影響が大きく、不具合が起きやすい部分ほど、テストケースを多くし、深く確かめます。

プロジェクトのリスクには、起きたときの対策を決めておきます。たとえば、次のように書きます。

リスク	起きたときの影響	対策
開発が遅れ、テストの開始が遅れる	テストの期間が短くなる	優先度の高い機能から先にテストできるよう、開発の順番を調整する
テストの担当者が急に休む	テストが止まる	担当者ごとの作業を記録し、ほかの人が引き継げるようにしておく
テストの環境の準備が遅れる	テストを始められない	環境の準備を最初の作業にし、期限を早めに設ける

リスクを書いておくことの利点は、起きたときに慌てずに済むことだけではありません。計画の段階で関わる人とリスクを共有しておけば、発注者も含めて、早めに手を打つことに協力してもらいやすくなります。

報告と連絡の方法を決める

テストの途中では、進み具合や見つかった不具合を、関わる人に伝え続ける必要があります。報告と連絡の方法も、計画書で決めておきます。

決めておくことは次のとおりです。

• 報告の頻度：毎日、週に1回など
• 報告の形：打ち合わせ、メール、共有の資料など
• 報告の中身：実施したテストの数、見つかった不具合の数と重さ、遅れの有無
• 不具合の連絡の流れ：誰が見つけ、どこに記録し、誰に知らせるか
• 緊急の連絡：重大な不具合が見つかったときに、誰にどう知らせるか

報告の中身は、毎回同じ形にしておくと、前回との比べがしやすくなります。たとえば、「テストケースの実施数と全体の数」「見つかった不具合の数」「直った不具合の数」「残っている不具合の数」の4つを毎回報告すれば、テストがどこまで進み、品質がどう変わってきたかが分かります。

不具合の記録の形も決めておきます。どの画面で、どんな操作をしたら、どんな結果になり、本来はどうなるべきだったのかを、決まった項目で記録します。記録の形がそろっていれば、開発者が不具合をすぐに再現でき、修正が早く進みます。

テスト計画書の目次の見本

ここまでの内容を、実際の計画書の目次の形にまとめた見本を紹介します。小さなWebサービスのシステムテストを想定したものです。

1. はじめに
   • 1.1 目的：予約の機能の追加に伴い、システム全体が要件どおりに動くことを確かめる
   • 1.2 対象のシステム：予約サービスの利用者画面と管理画面
   • 1.3 参照する資料：要件定義書 第2版、画面仕様書 第3版
2. テストの範囲
   • 2.1 対象：予約の登録、変更、取り消し、管理画面の予約一覧
   • 2.2 対象外：決済の機能、古い版のブラウザ
3. テストの方針
   • 3.1 段階：システムテスト、受け入れテスト
   • 3.2 種類：機能のテスト、画面の表示の速さのテスト、回帰テスト
4. 環境と道具：機器とブラウザの組み合わせの一覧、テスト用データ、不具合の管理の道具
5. 体制と役割：責任者、担当者、開発の窓口、発注者の窓口の名前
6. 日程：節目ごとの日付と予備の期間
7. 開始と終了の基準
8. 不具合の扱い：重さの区分と、直すかどうかを決める人
9. リスクと対策
10. 報告と連絡の方法

この見本のように、各項目に1行から数行で中身を書いていくと、計画書の全体像ができあがります。表紙には、文書の名前、版の番号、作った日、作った人、承認した人を書いておきます。版の番号と変更の記録があれば、どの時点の計画で合意していたかをあとから確かめられます。最初から細かく書き込もうとせず、まず目次と各項目の要点を書き、関わる人に確かめてもらいながら詳しくしていくと、手戻りが少なくなります。

テスト計画書でよくある失敗

テスト計画書を作っても、うまく使われないことがあります。よくある失敗と、その対策を挙げます。

1つ目は、範囲があいまいなことです。「主な機能をテストする」のような書き方では、どの機能が主な機能なのかが人によって違います。対象と対象外を、機能や画面の名前で具体的に書くことが対策です。

2つ目は、役割があいまいなことです。誰が判断するのかが決まっていないと、不具合を直すかどうかの判断が止まり、テストが進みません。役割ごとに名前を書き、判断の権限を決めておくことが対策です。

3つ目は、終了基準がないことです。終わりの条件が決まっていないと、テストはいつまでも続くか、日程の都合で打ち切られるかのどちらかになります。数字で終了基準を書いておくことが対策です。

4つ目は、作ったきり更新されないことです。プロジェクトの途中で仕様が変わったり、日程が動いたりしても計画書を直さなければ、計画書と実際の作業がずれていきます。変更があったら計画書を直し、版の番号と変更の内容を記録しておくことが対策です。

5つ目は、ほかの資料を写しただけになることです。ひな形やほかのプロジェクトの計画書をそのまま使うと、そのプロジェクトに合わない項目が残ったり、必要な項目が抜けたりします。ひな形は出発点として使い、項目ごとにこのプロジェクトではどうするかを考えて書き直します。

小さな案件での簡易版

数日で終わる小さな修正や、個人で受けたWebサイトの制作などでは、ここまで紹介したすべての項目を書くのは負担が大きすぎます。その場合は、次の5つの項目だけを書いた簡易版で十分です。

1. 確かめる範囲：何を確かめ、何を確かめないか
2. 確かめる環境：どの機器とブラウザで確かめるか
3. 確かめる人：誰が確かめ、誰が最後に確認するか
4. 日程：いつからいつまでに確かめるか
5. 終わりの条件：どうなったら確認を終えるか

この5つを1枚の文書や、チャットでのやり取りの中にまとめておくだけでも、発注者との認識のずれは大きく減ります。特に、確かめない範囲と終わりの条件を事前に伝えておくと、納品のあとに「この画面も確かめてほしかった」と言われることを防げます。

個人でWebサイトの制作を受けている場合は、納品の前の確認の項目を一覧にしたものを、作業の最初に発注者に見せておく方法もおすすめです。確認の項目について発注者から意見をもらっておけば、それがそのまま簡易版のテスト計画書の役割を果たします。確認を終えたら、どの項目をどの環境で確かめたかを一覧に書き込んで納品物に添えると、発注者にとっても受け入れの確認がしやすくなり、次の依頼にもつながりやすくなります。

テストの作業を分担して進めるとき

テスト計画書で決めた作業は、実際のテストの期間中、毎日のように進み具合を確かめる必要があります。誰がどのテストを担当していて、どこまで終わったのか、見つかった不具合はどこまで直ったのかを、関わる人が同じ情報で見られることが大切です。

関わる人が2人か3人で、テストの数も多くなければ、表計算ソフトで作業の一覧を作り、担当と期限と状況の列で管理すれば足ります。

ところが、テストの担当者が増え、開発者や発注者との間で不具合の確認のやり取りが何度も起きるようになると、表計算の一覧とメールだけでは、どのやり取りがどの作業の話なのかが分かりにくくなります。その段階では、テストの作業ごとにカードを作り、担当と期限と話し合いを1か所にまとめられるプロジェクト管理ツールを使うと、進み具合を共有しやすくなります。

候補の1つがPinatecaです。公式サイトによると、カンバン、ガント、カレンダー、リストなど8種類のボードとチャットが無料プランから使え、カードごとにコメントや添付を付けたり、カスタムフィールドで「テストの段階」「重さ」などの項目を追加したりできます。たとえば、カンバンボードに「未着手」「テスト中」「修正待ち」「再確認」「完了」の5つの列を作り、テストの作業をカードにして担当と期限を付ければ、どこで作業が止まっているかを1画面で確かめられます。ガントボードでは、カードの期間が横棒で並ぶので、テストの日程の重なりも見えます。5人までのチームなら期限なしで無料で、ボードは10個まで作れます。6人目、または11個目のボードからはスタンダードプランで、料金は1人あたり月額500円（年払いなら1人あたり月額400円、税抜）です。Pinatecaはテストを自動で行ったり、テストケースを作ったりする道具ではなく、作業の分担と進み具合を共有するための道具です。Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

テストの仕事と、身につけ方

テスト計画書を書けることは、ソフトウェアの品質に関わる仕事で大きな強みになります。テストを実際に行う作業だけでなく、計画を立て、関わる人の認識をそろえる力は、どの開発の現場でも求められています。

在宅ワークとフリーランスの仲介を2004年から続けてきた運営者として見てきた限りでは、テストの仕事は、開発の終盤に人手が足りなくなった会社から、外部の人に頼まれることが多い分野です。依頼する側と受ける側が間に人を入れずに直接やり取りできる形では、依頼する側は同じ予算で丁寧な確認を頼みやすく、受ける側は手元に残る報酬が厚くなります。計画書を書ける人は、テストを行うだけの人よりも上流の工程から任されることが多く、継続した依頼につながりやすいのも特徴です。

テストの仕事の内容や求められる力について詳しく知りたい人は、QA・テスト・コードレビューのお仕事で、仕事の種類と始め方が紹介されています。セキュリティのテストに関心がある人は、AI・マーケティング・セキュリティのお仕事も参考になります。テストの知識を体系的に身につけたい人は、JSTQBの資格の学習が入口になります。シラバスは無料で公開されているので、まずは読んでみると、テスト計画書に書くべきことの全体像がつかめます。

よくある質問

Q. テスト計画書とテスト仕様書はどう違いますか？

テスト計画書は、テスト全体の目的、範囲、方法、体制、日程、終わりの基準を決める文書で、テストの準備の最初に作ります。テスト仕様書は、計画書で決めた範囲に沿って、確かめる手順、入力する値、期待する結果を1件ずつ書いた文書です。計画書が全体の方針を示す設計図、仕様書が個々の作業の手順書と考えると分かりやすくなります。

Q. テスト計画書には最低限何を書けばよいですか？

小さな案件であれば、確かめる範囲、確かめる環境、確かめる人、日程、終わりの条件の5つを書けば、計画書としての役割を果たせます。特に、確かめない範囲と終わりの条件をはっきり書いておくと、発注者との認識のずれを防げます。大きなプロジェクトでは、これに加えてリスクと対策、不具合の扱い、報告の方法などを書きます。

Q. テストの終了基準はどう決めればよいですか？

誰が見ても同じ判断ができるよう、できるだけ数字で決めます。たとえば、計画したテストケースをすべて実施した、重大な不具合と優先度の高い不具合がすべて直っている、残っている不具合について発注者の了承を得ている、といった条件です。不具合の重さの区分もあわせて決めておくと、見つけた人によって判断がぶれません。

Q. テストの日程が足りなくなるのを防ぐにはどうすればよいですか？

見積もりの段階で、不具合の修正と再確認、回帰テストにかかる時間を必ず含めることが大切です。そのうえで、テスト全体の期間の1割から2割ほどの予備の期間を最後にまとめて取っておきます。途中の節目ごとに進み具合を確かめ、遅れに早く気づけるようにしておくと、範囲の調整などの手を早めに打てます。