最終更新日: 2024年3月22日
ソフトウェアテスト・ゲームテストを行うにあたって作成されるのが「テスト計画書」です。一口に「計画書」といっても、テスト計画書は単にソフトウェアテストのスケジュールだけをまとめたものではありません。プロジェクトに支障をきたさないようにテストを実施し、テストの品質を確保するために、テスト計画書には様々な項目が盛り込まれます。
ソフトウェアテスト・ゲームテストを行う上で、テスト計画書は不可欠です。この記事では、テスト計画書とは何か、その目的、そして計画書をまとめる上での要件について、わかりやすく解説いたします。
テスト計画書とは
テスト計画書とは、テストの目的や方針、方向性、テストを進める上での留意点、スケジュールなどをまとめたドキュメントのことです。テスト計画書には、テストに関わる指針が全て掲載されます。また、担当者の役割分担、要員の配置、コスト見積もりといったテスト実施にあたって必要となる具体的な情報の掲載も必要です。
テスト計画書は全体テスト計画書と個別テスト計画書に分類される
テスト計画書は「全体テスト計画書」と「個別テスト計画書」の2種類に大別されます。
まず「個別テスト計画書」とは、以下4つのテストレベルごとのテスト計画についてまとめたドキュメントです。
単体テスト | 個々のプログラム(コンポーネント・モジュール)が期待通り動作するかチェックするためのテスト |
---|---|
結合テスト | 単体テストでチェックしたプログラムを組み合わせたときに、正常に動作するかチェックするためのテスト |
システムテスト | プログラム全体で正常に動作するかチェックするためのテスト |
受け入れテスト | ソフトウェア開発の最初に行われる「要求定義」にまとめられている要求を満たせているか確認するためのテスト |
個別テスト計画書では、主に上記テストを実際に行うために必要な情報をまとめます。たとえば各テストが対象とする具体的な機能、テスト観点※1)、境界値※2)などは、個別テスト計画書に掲載される情報です。
※1)プログラムが正常に動作していることを確認するために、どの部分にどのようなテストが必要かをまとめたポイント
※2)プログラムにおいて条件の分岐が生じる境界となる値
一方、全体テスト計画書とは、上記4つのテストレベル全体を見渡した上で、それぞれの個別テストの方針・方向性、大まかなスケジュールなどをまとめたドキュメントを指します。全体テスト計画書と個別テスト計画書の違いは、以下のように理解するとわかりやすいでしょう。
【全体テスト計画書と個別テスト計画書の違い】
全体テスト計画書 | 主にソフトウェアテスト全体の方針や方向性をまとめた計画書 |
---|---|
個別テスト計画書 | 主に各テストを実際に実行する上で必要な情報をまとめた計画書 |
テストを行う際には、全体テスト計画書・個別テスト計画書の両方が作成されます。
テスト計画書を作成する目的
たとえば旅行であれば、「行き当たりばったり」でもよいかもしれません。予備知識なしで先入観を持たずに、観光地へ訪れることで新鮮な気持ちで楽しめることもあるでしょう。一方で、あとから「あそこも行っておくべきだった」「交通手段はこっちの方がよかった」と気づくこともあるはずです。
旅行のようなレジャーなら、そんな後悔も含めて「良い思い出」にできるかもしれませんが、ソフトウェアテストではそうはいきません。テストすべき内容を見落としていたり方向性が間違っていたりすれば、あとからやり直すのに大変な労力がかかります。またテストすべき内容が不足していることで、結果的にソフトウェアのリリース後に不具合が発見され甚大な損害が発生してしまう可能性も否定できません。そうしたことが起きないようにするためにも、テスト計画書を作成するわけです。
具体的には以下のような内容を決定・定義した上で、テスト計画書に記載します。
・テストの範囲・目的・リスク
・必要となる人的リソースと、その他のリソースの見積もり
・テストの設計・実行・評価などのスケジュール
・テスト活動に必要となる予算などの見積もり
これらの内容を決定・定義し、ドキュメントとしてまとめるのが、テスト計画書の具体的な目的です。テスト計画書は、これから実施するテストが一定の品質基準を満たすことを保証するのにも役立ちます。またチームメンバーや各ステークホルダーとテストに関する情報を共有し、コミュニケーションを取る手段としても有効です。
なおテストを行う初期の段階では、情報が足りない項目も少なくありません。その場合もテスト計画書に”TBD(未確定)”として記載しておけば、忘れられずに済みます。
テスト計画書を作成する流れ・プロセス
テスト計画書は、以下の流れ・プロセスで作成されます。
① | コンテキストの理解 | 関係者・利害関係者とコミュニケーションをとるなどして、コンテキスト(テストを行う目的や状況、環境など)を理解する。 |
② | テスト計画書策定の準備 | ・目的を達成するために必要な活動を洗い出し、スケジュールを立てる ・テスト計画書作成に関連する関係者を洗い出す ・関係者からテストの活動内容やスケジュール、参加者についての承認を得る |
③ | リスクの識別と分析 | ・テストに関わるリスクを洗い出し、ランク付けや分類を行う ・リスク評価の結果について、関係者の承認を得る ・リスク評価の内容をドキュメント化する |
④ | リスク軽減策の識別 | リスクの軽減策を検討し、ドキュメント化する |
⑤ | テスト戦略設計 | テストに関わる各種戦略を設計する |
⑥ | 要員配置とスケジュールの決定 | ・テストの実行に必要な要員とスキルを洗い出す ・要員調達にかかる期間や見積もりなどに基づいてスケジュールを作成する ・関係者から要員配置とスケジュールについての承認を得る |
⑦ | テスト計画書の記録 | ・テスト戦略や決定した要員配置、スケジュールに基づいてテストに関わる最終的な見積もりを行う ・テスト戦略や要員配置、最終的な見積もりをテスト計画に組み込む |
⑧ | テスト計画書の合意形成 | ・関係者からテスト計画書に対する見解を収集し、見解が一致しない箇所を解決する ・関係者のフィードバッグに基づいて、テスト計画書を更新する ・関係者からテスト計画書に関する承認を得る |
⑨ | テスト計画書の通知と利用可能か | ・テスト計画書を実際に利用できるようにする ・テスト計画書が利用できる状態になったことを関係者に通知する |
テスト計画書の要件
それでは、テスト計画書にはどんな内容が記載されるべきでしょうか。ここでは、その主な要件をまとめてご紹介します。
テストの範囲
テストの対象となるソフトウェアの範囲や、制約事項(テスト環境の制約・実施できないテストなど)を明記します。計画の段階で、テストによって担保できないことの記載も必要です。
プロジェクト背景/テストの目的
そのテストがどのような背景のプロジェクトのもとで実施されるのか、テストを行う目的は何かをまとめます。たとえば「新しくリリースするゲームにおいて実装予定の機能が正しく動作するか」「ソフトウェアのバージョンアップに伴い、周辺機能に影響が出ていないか」といったように、プロジェクトの背景やテストの目的を具体的にまとめます。
たとえばゲーム製品においては、「不正行為により不当な利益を得る」「市場での成功がプレーヤーの主観的な意見に左右される」など、ゲーム分野特有のリスクが存在します。これらのリスクもプロジェクト背景の一部として考慮し、テスト計画を立てる必要があります。
テストアイテム
「テストアイテム」とは、ソフトウェアのうちテスト対象となる機能のことを指します。テストアイテムと聞くと「テストに使うもの(PC・サーバー等)」とイメージされることも多いですが、そうではないのでご注意ください。
たとえばゲームテストでは、以下がテストアイテムの例として挙げられます。
・ゲームのスコアリングに関わる各種機能
・ポーズメニュー
・ガチャ
・ログインボーナス
・ミッション
・ランキング など
なおテスト計画書では、クライアントや開発担当者などとの認識の齟齬を防ぐため、「この機能はテストの対象(テストアイテムである)」だけでなく「この機能はテストの非対象」といったように、ソフトウェアの全機能について明確にまとめるのが理想的です。
テスト環境
テストが実行される具体的なデバイスやネットワーク条件を明記する部分です。この項目には、テストに必要なハードウェア/ソフトウェアのスペック、およびネットワークの種類と条件などの詳細情報が含まれます。
1.スマートフォンOS:
テストが実施されるスマートフォンのオペレーティングシステム(OS)のバージョン範囲を明記します。ここで、特定のOSバージョンが要確認である場合、その旨を注記し、後で情報を更新できるようにします。
2.スマートフォン端末:
使用するスマートフォン端末を記載します。
3.通信環境:
テストに使用するネットワークの種類を明確にします。たとえばWi-Fi環境のみを使用するといった具体的な条件を設定します。
4.機材調達:
社内で調達可能な機材について説明し、調達が困難な場合の相談プロセスについて言及します。テストデータの受け渡し方法や、テスト管理に使用するツールについて記載します。
【テスト計画書サンプル】
テストアプローチ
「テストアプローチ」とは、テストの目的を達成するためにどのようにテストを行うかについての方針・方向性のことです。テストアプローチは、プロジェクトの状況、実行時のリスク、テストの目的などの要素を踏まえて決定します。より専門的に言うと、テストの全体的な戦略に基づき、個々のプロジェクトにおける方針・方向性を決めたものです。テストアプローチは、各プロジェクトの複雑さやリスクなどに応じて策定され、プロジェクトの状況、リソース、リスクなどに依存します。テストアプローチを策定することによって、テストタイプ(テストの種類)、テスト技法、テストの開始・終了基準をどの程度詳細に決めるべきかなども決まります。
【テスト計画書サンプル】
【ゲームテスト計画書サンプル】
テスト開始、中断、再開、終了基準
どういった状況になったら、テストを開始・中断・再開・終了するのかという基準のことです。たとえばテストの開始基準は、必要なテスト環境・テストツールなどが用意できたときに設定されることが多くなっています。終了基準については、全てのテストケースが完了したら終了と判断するのか、あるいは発見された全ての不具合が修正された時点で終了と判断するのか等を定義します。
仮に終了基準を満たしていなくても、それまでに消費された予算や時間を考慮してテスト活動が終了するケースも少なくありません。プロジェクトのステークホルダーなどがテストを早期終了するリスクを受け入れることで、このような状況でテストを終了することもできます。
【テスト計画書サンプル】
テストスケジュール
「テスト」と一言で言っても、準備からテストの設計・実行・修正確認までの工程が存在します。それぞれの工程におけてスケジュールを決定する必要があります。また、より詳細なスケジュールが求められる場合は、テスト対象の機能ごとにテストスケジュールを設定します。テストスケジュールを決定する際には、優先度や効率、依存関係などを考慮する必要があります。
テストケースの実行順序については、優先度に基づいて決定することが理想といえます。しかしテストケースやテスト対象の機能に依存関係がある場合は、必ずしも優先度によって順序が決められるわけではありません。優先度にとらわれず、適切な順序で行う必要があります。またテストケースを実行する順序が複数考えられる場合は、効率性と優先度を天秤にかけながら慎重に選ばなくてはなりません。
テストの種類に関しては、より迅速にフィードバックした方がよいものから行うのが一般的です。しかし、この場合も依存関係を考慮しなくてはなりません。
【テスト計画書サンプル】
なお、ゲーム開発においては、その独特なクリエイティブな側面と技術的な複雑性により、特別なアプローチを要求します。開発ライフサイクルを意識し、全体にわたって効果的にテスト計画を立てることが大切です。
【関連記事】テスト計画においてテストスケジュールを作成するメリット、方法、注意点まとめ
成果物
「成果物」とは、テストを実行する成果として提出するものを指します。たとえばテスト項目書・テスト実施結果・バグレポートなどが成果物の例としてあげられます。
【テスト計画書サンプル】
体制
テストを行う際の体制を具体的にまとめます。たとえば、どういった役割の担当者がどこ(部署など)と、どのように連携してどうテストを実行していくのかといった内容を、体制図としてまとめることが多いです。
【テスト計画書サンプル】
コミュニケーション方法
どの担当者が、どういったツールを使い、どのようにコミュニケーションをとるのかを決定します。たとえば定例会のような定期的な会議体についても、この項目で具体的に定義しておくことが必要です。
【テスト計画書サンプル】
BTSチケットフロー
BTS(Bug Tracking System)とは、発見されたバグの内容やその対応予定・対応状況(ステータス)・対応履歴をまとめるシステムのことです。対応状況はチケットによって管理されます。
その上でBTSチケットフローとは、各ステータスにおいてどの担当者が対応するのか、どういった状態になればステータスを変更するのかなど、チケットを管理する上で必要な事項をまとめたものです。
リスク
テスト計画書では、ソフトウェアテストを進めるにあたって、想定されるリスクを洗い出してまとめておく必要があります。このとき、それぞれのリスクに対してどのように対応してくかの方針もまとめます。
【テスト計画書サンプル】
テスト計画書の構成例
以下、テスト計画書の構成例をご紹介します。テスト計画書を作成する際の参考になれば幸いです。
1.ドキュメントの諸元情報 1.1.概観 1.2.ドキュメントのUID 1.3.発行組織 1.4.承認権限 1.5.改訂履歴 2.イントロダクション 3.テストのコンテキスト | 4.テストのコミュニケーション 5.リスク登録簿 6.テスト戦略 | 7.テスト活動と見積り 8.要員の配置 8.1.役割,活動,責任 8.2.雇用の必要性 8.3.トレーニングの必要性 9.スケジュール |
テスト計画作成時の注意点
テスト計画を作成するにあたり、テスト関係者はプロジェクトの概要を十分に理解しておくことが必要です。クライアントの要求や考えられるリスク・課題についてもよく考慮して作成しなくてはなりません。
またテスト計画のレビューについては、ステークホルダーも巻き込んで複数回行うことが推奨されます。その上で、テスト計画を途中で変更する必要が生じるものだと認識し柔軟な対応が必要です。テスト関係者が定期的に見直しを行い、適宜更新することも求められます。
まとめ
テスト計画書には、テストの目的から方針、スケジュールといったソフトウェアテストを行う上で必要な事項を詳細にまとめておきます。その他、テストを行う上での留意点やテスト対象となる機能(テストアイテム)、リスクなどもテスト計画書に記載されるべき要件です。テスト計画書は、ただ体裁の良いドキュメントを作成することが目的ではありません。担当者間の認識の齟齬を防ぎ、テストの目的を達成するために、必要な事項について十分に検討して作成し、適宜見直しや更新をしていくことが大切です。
【参考文献】
テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J01
Certified Tester Game Testing (CT-GaMe)

AIQVE ONE株式会社 人材開発セクション
2008年に新卒でベリサーブに入社し、テスト一筋で15年のキャリアを積んできた。入社以来、社内の研究活動を続けながら、ブルーレイプレイヤー、カーナビ、カラオケ機器などの組込みテストで経験を積んだ。その後、自動車の車載ECUのシステムテストマネジメント・テストコンサルティングや航空機の安全評価にも携わり、直近ではXRやAIを活用したテスト支援の研究を行っている。自社プロダクト開発のプロダクトオーナーも経験。2023年5月からはAIQVE ONEにも所属し、教育活動も行っている。幅広い分野でのテストのプロフェッショナル。
資格取得はISTQB-AL-TM/IVEC-Lv4/基本情報技術者