テスト計画とは？目的や種類・作り方・注意点をわかりやすく解説

テスト計画は、テスト工程における目的やテストの対象を認識し、テストの手法や成果物などを明確にすること。また、工数やスケジュール、実施時に起こりうるリスクを明示化する作業です。

「テスト計画」をせずとも何とかなってしまうものと捉えてはいないでしょうか？小規模な改修や緊急リリースなど作業量が限定されている場合には、テスト計画がなくても問題とならないことはあります。

しかし、テスト計画がない状態でテストをすると、さまざまな問題を引き起こす可能性があります。たとえば、テストの網羅性や効率性を考慮できずに不具合が多く残った状態でリリースすることになってしまう、テストの準備を考慮できずにテストを開始する時に多くの時間ロスが発生してしまう、進捗管理の指標が把握できずにテストケースの消化が遅延してしまうなどです。

本記事では、テスト計画の概要と目的、タイミング、種類、流れについて解説します。

テスト計画とは、実施するテストの目的、対象、手法、スケジュール、責任者、必要なリソースなどを定義することです。定義した内容はテスト計画書としてドキュメント化します。ソフトウェアテストの国際規格「ISO/IEC/IEEE 29119」では、Part3にドキュメントに含める項目が定義されています。以下、テスト計画書の項目として示されているものの一部を取り上げます。

・テスト方針（プロジェクトの背景、テストの目的、テスト対象、対象外のもの、前提と制約）
・テスト基準（テストレベル、テストタイプ、そのマッピング、テスト手法、タスク）
・関係者（ステークホルダー、承認、役割と責任範囲、要員トレーニング）
・スケジュール（工程、期間）
・テスト環境（テストシステム構成、テストデータ、作業場所、適用ツール）
・管理基準（管理項目、開始終了基準、一時停止基準、成果物）
・リスクと対策（プロダクト品質観点、プロジェクト遂行観点）

一言で表すと、テスト計画は、テストにおける5W1Hを詳細に洗い出していくプロセスといえるでしょう。

テスト計画は、スケジュールや工数だけ決めて終わりという方も多いのではないでしょうか。しかし計画をするからには、求められる品質を、どのようにし、設定したスケジュールや工数で実現するかを示さなければなりません。
例えば、それぞれのテストレベル* でどのようなテストをするのかを決めておかないと、人によって認識が違ってテスト漏れやテスト重複につながります。

それぞれのテストでどのくらいのテストケースを作るかということを決めておくことも重要です。設計したテストケースが多すぎたり少なすぎたりすることで、スケジュールや工数も予定と大きく異なってしまいます。

また、テストでどのくらいの不具合が見つかるだろうということを想定しておくことも必要です。想定を怠ると、不具合レポートに必要な工数が把握できず、これもスケジュールや工数に影響します。

さらに、準備すべきことを明確化することに加えて、「予想より多くの不具合が出た」「開発が遅れてテスト開始が伸びた」などの問題が発生した時の対処を予め検討しておくことで、失敗を予防することができます。

このように、より効果的なテストを失敗なく実施するためには、テスト計画を策定することは欠かせない作業となります。

*テストレベル：単体テスト、統合テストのようなテスト工程と似ているが、工程とずれたり後戻りすることがあるためテストレベルという　※テストレベルに関しては、こちらのコラムで紹介

テスト計画は、大きく2種類にわけることができます。

◆ 全体テスト計画
◆ 個別テスト計画

この２つはそれぞれスコープが異なります。

全体テスト計画は、そのプロジェクトにおけるテストの計画を策定するプロセスです。テストのスコープや品質目標を定義します。最終的な品質に向けて、それぞれのテストレベルでどのくらいの工数でどのようなテストをして、何をもって完了とするかを明確にします。前回のプロジェクトの実績や反省を踏まえて、工数やスケジュールを見直すことは重要です。新しいツールや技法を導入する場合や、要員の異動がある場合は、訓練のスケジュールも必要となります。

個別テスト計画は、各テストレベル単位の計画を策定するプロセスです。全体テスト計画の時点より開発量が明確になり、前工程までの品質が見えるため、スケジュールやテストケース数・工数の精度が上げていきます。また、テスト環境の整備や、進捗と不具合の管理方法などを具体化することが可能です。特に前工程までで品質に不安要素がある時は、個別テスト計画でフォローアップの方針を検討します。

両者ともテスト計画で明確化する内容は似通っていますが、全体テスト計画はテストの方針決めにより重きをおき、個別テスト計画はテストの実施により重きをおくといえるでしょう。

テスト計画を作成するタイミングは、以下の通りです。

・全体テスト計画
全体テスト計画は、開発全体におけるテストの計画です。そのため、開発計画をたてるなかで検討しておく必要があります。実際にテストを実行するのは開発の後半になるため、プロジェクトの進捗に合わせて見直しや修正を行います。

・個別テスト計画
個別テスト計画は、テストレベルごとの計画なので、そのテストを開始するまでに決める必要があります。実際には準備や調整が必要なため、それよりも先行して検討を進めるのがいいでしょう。

テスト計画は、テストに対して指針を定めるものです。

テスト計画を作成する際は、テストの設計から実施、管理まですべての活動・項目に指針を設けましょう。実際にテスト計画を作成する流れについて、以下で具体的に解説します。

【テスト計画作成の流れ】
1．テストに求められる要求を整理
2．実際に行うテストの実行計画を作成
3．テスト段階で必要となる管理項目の整理と管理計画の作成

テスト計画を作成するうえで重要なことは、なぜテストを行うのかを再認識して求められる要求を整理することです。この要求をベースに実際の実行計画を立て、テスト段階で必要となる管理について細かく設定していきます。

テスト計画を作成する流れは全体テスト計画も個別テスト計画も同じです。全体テスト計画では、全体的な要求整理、実行計画、管理計画を作成するのに対し、個別テスト計画では、個々のテストレベルでの要求整理、実行計画、管理計画を作成します。

まずは、テストに求められる要求を整理しましょう。具体的には、以下のポイントを意識して整理していきます。

【要求を整理する際のポイント】
・テストを実施する目的は何か
・実施するうえで重要な項目は何か
・テストの対象・範囲は何か
・テストする対象物の開発進捗や品質レベルはどういった状況にあるのか
・前もって認識できる課題やリスクと言える項目はあるのか

テストにおける目的や重要項目、対象、範囲など細かいレベルで要求を整理していくことが重要です。開発進捗や品質レベルについても、「どこまでテストすれば十分な結果が得られるのか」を知るうえで重要なポイントといえます。

テスト計画を作成する段階で、テストについて把握できるものはすべて整理しておきましょう。

テストに求められる要求が整理できたら、実際にテストを行う際の実行計画を立てます。実行計画を作成する際は、以下のポイントを意識しながら実施してみてください。

【実行計画を作成する際に意識したいポイント】
・実際のテストはどのような段取りで行うか
・テストをする際に必要なツールなどはあるか
・テスト段階の各項目における基準は明確に
・テストにおける役割や実施場所を設定
・どのくらいのテスト期間が必要なのかスケジュールの明確化

段取りはどうなっているのか、いつまでに終わらせるべきなのか、もしくはどのくらいの期間を必要とする可能性があるのか、これらのことを踏まえて実際の実行計画とスケジュールを組み立てる必要があります。

また、テストを実施するうえで必要なツールや各項目における基準、各担当者やツールの役割については実行計画段階で明確にしておくようにしてください。それにより、テスト自体の質を維持、向上させることが可能です。

最後に、テストの実行計画が完成したらテスト段階で必要となる管理項目の整理と管理計画を立てます。実行計画を立てたらすぐにテスト開始できるわけではない点に注意してください。実際に管理する項目は以下の通りです。

【テスト段階で必要となる管理項目】
・リスクの管理
・作成・記録するデータや文書の管理
・進捗管理
・機材・ツール・人材の管理
・仕様変更等の管理

テストを円滑に進めていくために管理を行います。テストではイレギュラーな事態が発生することも珍しくないため、どのように対処すべきか決めておくことも管理計画の一つです。

また、テストの結果はその後に行われる別のテストでも必要となる情報であるため、進捗管理やデータ・文書の管理、仕様変更などの管理はきっちりと行うようにしてください。

テスト計画の骨組はどのテストにおいても共通の考えで成り立っています。今回はシステムテストを事例にテスト計画の骨組を説明いたします。

※システムテスト（ST）とは
テスト計画の骨組は、以下5W1Hに置きかえることができます。

– テスト方針の立案→Why
– テスト基準の決定→What
– 要員・体制の決定→Who
– スケジュールの決定→When
– テスト環境・ツールの決定→Where
– 各種管理基準の設定→How

これらをアウトプットしたドキュメントがテスト計画書となります。
続いて、それぞれのテスト計画における5W1Hについて解説していきましょう。

表1：全体テスト計画の5W1H

全体テスト計画ではテストの概要がメインとなるため、具体的な記載は個別テスト計画と比較すると少なくなります。
全体テスト計画で重視すべきは、Why・What・Whoの部分です。

「Why」は、そのプロジェクトにおける品質水準を決めるプロセスともいえます。プロジェクトとしてどこまで検証し、品質を担保するのかを整理します。
そのためにはどのような開発であるのかを定義する必要があり、ここから目指すべき品質が導かれるのです。

「What」では「Why」で整理したポイントをもう少し深堀します。何がテスト対象となり、どんなテストレベルで、どこまで見るのかを定義します。

このポイントは非常に重要です。例えばマルチベンダーで開発を行っている場合、ベンダーごとで同じテストレベルにもかかわらずテスト粒度が異なったり、結合テストを行うと単体で検知すべき不具合が多発したりするということはないでしょうか？

それは、このWhatが十分に整理されていないことが原因である場合があります。すなわち、各テストレベルの粒度が決定していないために、テストの抜け漏れなどが発生するリスクが高まるのです。

さらに性能試験・負荷試験などの非機能テストの実施の有無と、実施するタイミング、各テストレベルの納品物とエビデンスの取り扱いに関してもこの段階で整理したほうがよいでしょう。

「Who」では誰がテストにかかわるかを整理します。

以上を踏まえて、全体テスト計画ではテストレベル単位で役割を整理したほうがよいでしょう。
特に全体テスト計画では開発やテストといった各チームレベルの責任者を明示化することが重要です。

表2：個別テスト計画の5W1H

設計や実行といった作業レベルでの役割の整理は個別テスト計画で整理したほうが良いでしょう。

個別テスト計画では当該のテストレベルの詳細がメインとなるため、記述はより具体的になります。
ここで重視すべきは、When・Where・Howです。

「When」では、テストレベルのスケジュールを策定します。テスト設計・テスト実行がまず思いつくかもしれませんが、あわせてテスト準備もスケジュール上に加えることが極めて重要です。

例えば、スマートフォンを利用したテストの場合は、その調達やテスト用のアプリインストールなどの準備が欠かせません。このような準備期間を検討しないと予定通りテストを開始できないリスクが高まります。
また、端末の準備だけでなく、検証環境へのリリースといったこともテスト準備に含めて検討することが重要です。

さらに、データの準備も計画しましょう。特にシステムテストの場合は実運用でのデータ量でテストを実施することで、性能やユーザビリティーを確認することが重要です。

「Where」では、テスト環境に関して具体的な策定を行っていきます。前述のようなスマートフォンを利用するテストの場合、OSや端末自体の具体的な選定、バージョンの指定を行う必要があるでしょう。

また、外部接続を伴うテストを想定される場合は、その接続先に関する調整も行う必要があります。接続先が準備できない場合はスタブ／ドライバを利用するかどうかも含めて検討し、整理しなければなりません。

「How」では、どのようにテストを進めていくのか具体的に策定していきます。進捗報告の方法はどのように行うか、不具合管理は何を利用するのかについて決めていきます。

進捗報告に関しては、何をどのタイミングで誰に行うのか具体的に詰めておきましょう。
不具合管理に関しても同様ですが、連絡方法のみならず、修正された場合どのようなフローで連絡し、リリースが行われるかをタイミングも含めて検討しておくとよいでしょう。

最後にテスト計画の作成時／作成後に注意しておきたいことを以下3点あげます。

・想定されるリスクとその対応策を事前に示しておくこと
・テスト計画は変更がありうるものだと認識すること
・2回以上、ステークホルダーを巻き込んでレビューすること

いずれも開発の不確実性に対応するための心構えです。

開発途中で計画通りに進まないことはよくあります。例えば、ドキュメントやプログラムの品質が悪いことやスケジュールが押してテスト開始準備が遅れることなどが要因としてあげられます。

ドキュメントの品質が悪いと、テストを設計している際に何が正しくて何が誤っているかわからなくなり、確認に工数が掛かります。また、プログラムの品質が悪いと不具合が多く検出され、不具合レポートの作成や再テストに時間が取られてしまいます。スケジュールの面では、開発自体のスケジュールが遅れることやテスト環境が整わなくてテスト開始が遅れること、あるいは、テスト要員のスキル不足でテスト設計や実行に時間がかかってしまうということもあります。
そのほかにも、プロジェクト特有の外部要因によって色々な制約がかかることもあります。

このようなリスクのなかには、あらかじめ想定できるものも多いです。プロジェクトを何回も経験するなか、また開発中の状況から予想できたりすることで、リスクを予見することができます。テストは開発工程の最後にあるため、問題となる状況が発生してから対策を検討しているようでは手遅れになることもあります。リスクとして考えられることについては、テスト計画の段階から対策案を考え、ステークホルダーと合意しておくことが肝要です。

開発の状況により、思いもよらぬ変更や追加開発が発生することもよくあることです。

それにあわせて開発のスケジュールの変更や体制の検討などは行われますが、テスト計画の変更は後手に回ってしまうことが多いのではないでしょうか。

しかし、テスト計画ではテストの対象や方法について定めており、変更にあわせて修正することが肝要です。修正を怠ればテスト漏れなどの問題を引き起こす原因になりかねません。

したがって、テスト計画は工程間などのタイミングや、追加開発や仕様変更などで見直し、修正することをおすすめします。

また修正する場合は、全体テスト計画と個別テスト計画で相違が起きないように十分注意しましょう。

テスト計画のレビューを行うと、特に個別テスト計画のテスト方針の立案における要件漏れや検討抜けがレビューの対話を通して明らかになることも少なくありません。これは、早期に不具合を除去することにつながります。

しかしながら、このような早期発見が相次ぐと開発工程のリスク抽出に意識が向いてしまうことが多く、テスト計画自体の問題やテスト工程のリスクに目が向かなくなります。

１回目は開発との認識合わせ、２回目はテスト計画自体の検討という意識をもって行うとよいでしょう。

テスト計画は、場合によってはやる必要のない工程と思われることもあります。しかし、実際はそうではなく、抜けや漏れをなくすためには重要な作業です。テスト計画の策定は、そのまま完成するシステムの完成度に直結すると考えて、しっかりとテスト計画を練りましょう。

テスト計画を策定できない際は、ぜひSHIFTにご相談ください。システム開発の上流工程からリリースまでシームレスに対応できるほか、必要な部分だけのご依頼も可能です。テスト計画の策定やサポートも対応可能です。テスト計画の作り方がわからない、セカンドオピニオンとしてチェックをお願いしたい場合は、ぜひSHIFTまでお問い合わせください。

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座