最終更新日: 2022年12月8日

ソフトウェアテスト・ゲームテストを行うにあたって必要となるのが「テスト計画書」です。テストが適切に完了できるよう、テスト計画書には様々な項目がまとめられます。

しかし実際にソフトウェアテスト・ゲームテストを行ったことがある人でないと、どのようなドキュメントなのかイメージするのは難しいでしょう。この記事では、テスト計画書とはそもそもどういったものかや、その目的、さらに計画書をまとめる上での要件についてわかりやすく解説しています。

テスト計画書とは

テスト計画書とは、テストの目的や方針、方向性、テストを進める上での留意点、スケジュールなどをまとめたドキュメントのことです。テスト計画書は大きく分けて「全体テスト計画書」と「個別テスト計画書」の2種類に分類されます。

まず「個別テスト計画書」とは、以下4つのテストレベルごとのテスト計画についてまとめたドキュメントです。

単体テスト個々のプログラム（コンポーネント・モジュール）が期待通り動作するかチェックするためのテスト
結合テスト単体テストでチェックしたプログラムを組み合わせたときに、正常に動作するかチェックするためのテスト
システムテストプログラム全体で正常に動作するかチェックするためのテスト
受け入れテストソフトウェア開発の最初に行われる「要求定義」にまとめられている要求を満たせているか確認するためのテスト

一方、全体テスト計画書とは、上記4つのテストレベル全体を見渡した上で、それぞれの個別テストの方針・方向性、大まかなスケジュールなどをまとめたドキュメントを指します。テストを行う際には、全体テスト計画書・個別テスト計画書の両方が作成されます。

テスト計画書を作る目的

たとえば旅行であれば、「行き当たりばったり」でもよいかもしれません。予備知識なしで先入観を持たずに、観光地へ訪れた方が新鮮な気持ちで楽しめるといったこともあるでしょう。一方であとから、「あそこも行っておくべきだった」「交通手段はこっちの方がよかった」と気づくこともあるはずです。

旅行のようなレジャーなら、そんな後悔も含めて「良い思い出」にできるかもしれませんが、ソフトウェアテストではそうはいきません。テストすべき内容を落としていたり方向性が間違っていたりすれば、あとからやり直すのに大変な工数がかかってしまうこともあります。またテストすべき内容が足りず、結果的にソフトウェアリリース後に不具合が発見され甚大な損害が発生してしまうといった可能性も否定できません。

そういったことが起きないように検討漏れを防ぐためにも、テスト計画書を作成するわけです。なおテストを行う初期の段階では、情報が足りない項目も少なくありません。その場合もテスト計画書に”TBD（未確定）”として記載しておけば、忘れられずにすみます。

テスト計画書の要件

それではテスト計画書には、どんな内容が記載されるべきでしょうか。ここでは、その主な要件をまとめて紹介します。

プロジェクト背景/テストの目的

そのテストが、どのような背景のプロジェクトのもとで実施されるのか、テストを行う目的は何なのかをまとめます。たとえば新しくリリースするゲームにおいて実装予定の機能が正しく動作するかのテストであったり、ソフトウェアのバージョンアップに伴い、周辺機能に影響が出ていないかテストする、といったようにプロジェクトの背景やテストの目的を具体的にまとめます。

テストアイテム

「テストアイテム」とは、ソフトウェアのうちテスト対象となる機能のことを指します。テストアイテムと聞くと「テストに使うもの（PC・サーバー等）」とイメージされることも多いですが、そうではないので注意して下さい。

なおテスト計画書においてはクライアントや開発などとの認識齟齬が生じるのを防止するため、「この機能はテストの対象（テストアイテムである）」だけでなく「この機能はテストの非対象」といったように、ソフトウェアの全機能についてまとめるのが理想的です。

テストアプローチ

「テストアプローチ」とはテストの目的を達成するために、テストをどのように行うかという方針・方向性のことです。

テストアプローチは、プロジェクトの状況やプロジェクトを実行する上でどんなリスクがあるのか、テストの目的は何かなどの要素をふまえて決定します。テストアプローチをまとめることによって、テストを行う際の技法やテストタイプ（テストの種類）、テストの開始・終了基準をどの程度詳細に決めるべきかなども決まります。

テスト開始、中断、再開、終了基準

どういった状況になったら、テストを開始・中断・再開・終了するのかという基準のことです。たとえばテストの終了基準であれば、全てのテストケースが完了したら終了と判断するのか、あるいは発見された全ての不具合が修正された時点で終了と判断するのかを定義します。

テストスケジュール

一言でテストと言っても、準備からテストの設計・実行・修正確認などの工程が存在するので、それぞれの工程におけるスケジュールを決める必要があります。また、より詳細なスケジュールが求められる場合は、テスト対象の機能ごとにテストスケジュールを設定します。

【関連記事】テスト計画においてテストスケジュールを作成するメリット、方法、注意点まとめ

成果物

「成果物」とは、テストを実行する成果として提出するものを指します。たとえばテスト項目書・テスト実施結果・バグレポートなどが成果物の例としてあげられます。

体制

テストを行う際の体制を具体的にまとめます。たとえば、どういった役割の担当者がどこ（部署など）と、どのように連携してどうテストを実行していくのかといった内容を、体制図としてまとめることが多いです。

コミュニケーション方法

どの担当者が、どういったツールを使い、どのようにコミュニケーションをとるのかを決めます。たとえば定例会のような定期的な会議体についても、この項目で具体的に定義しておくことが必要です。

BTSチケットフロー

BTS（Bug Tracking System）とは、発見されたバグの内容やその対応予定・対応状況（ステータス）・対応履歴をまとめるシステムのことです。対応状況はチケットによって管理されます。

その上でBTSチケットフローとは、各ステータスにおいてどの担当者が対応するのか、どういった状態になればステータスを変更するのかなど、チケットを管理する上で必要な事項をまとめたものです。

リスク

テスト計画書では、ソフトウェアテストを進めるにあたって、想定されるリスクを洗い出してまとめておく必要があります。このとき、それぞれのリスクに対してどのように対応してくかの方針もまとめます。

 

まとめ

テスト計画書には、テストの目的から方針、スケジュールといったソフトウェアテストを行う上で必要な事項を詳細にまとめておきます。その他、テストを行う上での留意点やテスト対象となる機能（テストアイテム）、リスクなどもテスト計画書に記載されるべき要件です。担当者間の認識の齟齬を防ぎ、テストの目的を達成するためにも、きちんとテスト計画書を作成しておく必要があります。

資料請求