テスト計画書について

テスト計画書とは

テスト計画書とは、ソフトウェアテストをどのように行うかをまとめたものです。含まれる項目としては、テストの目的、範囲、方針・種類、環境といったものから、テストのスケジュール、また、テストを行う体制や担当、そして、考えられるリスクと対策などが挙げられます。実際にテストが実施される前に、この計画書が出来上がっていれば、チーム内またはチーム外の関係者とも共通の認識ができて、テストの漏れ・重複また、トラブルを回避するのに役立ち、テストが円滑に進みます。

　テスト計画書には、「全体テスト計画書」と「個別テスト計画書」の2種類があります。全体テスト計画書は、テスト全体の方針や枠組みを決めるものと言えます。個別テストレベル(単体テストレベルや結合テストレベルなど)全体を横断的に考慮し、各個別テストレベルの方針・方向性、スケジュールをまとめたものです。

各個別テストレベルで必要となる環境、体制・担当者、などのリソースも決めます。また、各テストレベルで共通となる進捗や品質についての報告や不具合管理のルールも決定されます。一方で、個別テスト計画書は、全体テスト計画書で定義されたテストレベルごとに作成されます。一つのテストレベルに特化した詳細な計画書となっており、実務的で具体的な内容となっています。

テスト計画書の目的

　テスト計画書はソフトウェアテストを正しく実行し、テストに求められる役割を果たさせるために必要なものといえます。テスト計画書がテストの実施前に作成されて、テストの全体像が明確になっていれば、テストすべき内容の見落とし(抜け漏れを防ぐ)や方向性の誤りがないかを事前に確認しておくことができます。

　そして、テスト実施中においては、テスト計画書があれば、関係者間での認識の齟齬を減らしたり、各テストレベルの完了基準で迷うという事態を避けることができます。このような認識のズレによる問題は数名のチームでは起こることは少ないですが、ある程度の規模で様々なバックグラウンドをもつ人員が集まる現場ではよく起こりえます。また、テスト計画書にはテストに関してのリスクとその対応策についても記載されます。テスト中に想定された問題が起こったとしても、限られたリソースを有効活用して対処にあたることができます。

　テスト終了後においては、例えば、後工程で不具合が見つかったとしても、前工程でテスト計画書を作成しておけば、どこまで検証をしたかということを振り返るための資料になり、不具合の対処に役立ちます。そして、同様のプロジェクトでも再利用することができるので有益な資料となりえます。

テスト計画書に記載する要素

テスト計画書に記載する要素には以下のようなものがあります。

以下では、これらについて一つづつ紹介していきます。

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

　プロジェクトの背景としては、そのプロジェクトの要件を記載することができます。製品の概要、何のためにどんなものをつくるのか、新規開発か改修か保守なのか、さらに、なぜ、その開発や改修が必要なのか(外的要因：ユーザーや顧客などからの希望についても書かれることがある)という内容を記載することができる。そして、テストの必要性についても書くことができる。ここでいうテストの必要性にあたるのは、例えば、品質の確保が必要、仕様変更があったため、外部公開前の最終確認など、プロジェクトの内容に沿った様々なものが挙げられる。

　テストの目的としては、どの程度の品質が求められているかを記載します。具体的には、何を確かめるためのテストなのか、テストのゴールは何か、テストをしていく上でのリスクにどう対応するかといったことを記載します。このようにして、どの程度の品質が求められているのかを明確なものにしておきます。

テストレベルの定義

　テストレベルとは、「単体テスト」「結合テスト」「システムテスト」「受け入れテスト」といったテスト工程でのステップのことです。各テストレベルでのテストの要求事項を記載します。このとき各テストレベルの目的と範囲を明確に記載するようにしてください。ここで、コンポーネントレベルまで分割された機能をどのように結合してテストしていくか決めることになります。この部分でテスト計画書の完成度が決まると言えるので、作成に先だって関係者間でテストレベルの認識のすり合わせを行うようにしましょう。

テストの範囲

　テスト対象となるソフトウェアやハードウェアの範囲と、ほかのシステムとの範囲のことを指します。特に、テスト対象となる機能、インターフェース、対象外の機能については明確に記載します。何をテストするのか、何をテストしないのかをはっきりさせることで関係者間の認識を一致させることができます。

テスト環境とアプローチ

　テスト環境の項目ではどのようなデバイス、ネットワーク、サーバーでテストが行われるかが記載されます。テスト環境に必要なサーバーの総合スペック、構成、ネットワーク情報などが記載されます。ドライバやスタブといったテストツールと本番環境についての考慮についても書くようにしましょう。

　アプローチの項目では、「どんな段階のテストを、どんな目的で、どう進めるか」について整理して記載します。テスト手順、テストレベル構成、担当者、テスト方法、使用するツール、機器台数などについても記載されます。

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

　この項目は、テストの進行管理や品質判断の基準を明確にするために重要ポイントであると言えます。テストの開始基準の条件が明記されていれば、テストの準備が整っていることがわかります。また、テストの中断基準の条件があれば、重大な障害やリスクに対応することができますし、テストの再開基準の条件があれば、問題が解決したかを確認することができます。（ここで、テストの中断、再開を判断する権限が誰にあるかも明記しましょう。）そして、テストの終了基準の条件があれば、品質が確認されてテストの目的を達成したかどうかがわかります。このような4つの基準があれば、「いつ何を判断材料に進める・止めるか」を共通認識とすることができます。基準は定量的なものであることが望ましいと言えます。

体制とスケジュール

　体制の項目には、テストに関わる組織、部門、役割や担当者を記載します。役割や担当者については責任の範囲も書くようにしましょう。外部委託先などの外部関係者との関係性も記載します。

　続いて、アプローチで決めた内容を考慮して、テストスケジュール表(ガントチャートで表されることが多い)、マイルストーン(テスト開始日、終了日、レビュー日などの重要な節目)、余裕日を決定していきます。

テストのタスク

　この部分で、テスト活動全体の作業を洗い出して、それぞれの作業が何なのかを明確にします。また、そのタスクを行うのに必要な特殊な技能があれば記載します。テストの準備のためのタスク、テストを実施するためのタスク(テスト設計、テスト実行、結果整理・報告)を記載します。

要員計画とトレーニング

　テストに必要とされるスキルをもとに要員計画を立てます。どんなスキルを持つ人がいつ、何人ほど必要なのかを明確に記載します。トレーニングが必要な場合は、その期間と計画についても記載されます。　

モニタリングと管理

　テストが実施されていく中で、進捗や品質を適宜、把握する必要があります。この項目で、進捗や品質の把握をどのように行い、問題が生じたときにどのように対応するのかを記載します。進捗の把握には、実施済みのテストケース数、不具合件数などが用いられます。品質の把握には、機能単位の不具合混入率などが用いられます。

リスク管理

　プロジェクトで起こりうるリスクを一覧にまとめます。多くは表形式です。起こりうるリスクの説明、発生率、影響度を記載します。それぞれのリスクの予防策や、発生した場合の対応策も記載します。重要なこととして、リスク対応の優先度も記載します。プロジェクトでよくあるトラブルに備えて、あらかじめ手を打つことで、納期遅れや品質トラブルを防げるようになります。

成果物

　この項目では、テストで作成される文書やデータを一覧でまとめます。もちろん、テスト計画書自身も成果物の一つです。一覧でまとめるときには、文書の名前、目的、内容、作成者、作成時期、提出時期がわかるようにしましょう。また、成果物のフォーマットが決まっているときは、使用ツールや格納場所も書いておくと確認しやすくなります。

テスト計画書を書く際のポイント

　ここでは、テスト計画書を書く際に気を付けておきたいポイントについて紹介します。一つ目は、よく考えられたテンプレートを利用すること、または、国際的に合意されたソフトウェアテストの規格の詳細を示したISO/IEC/IEEE 29119を参考にするという点です。よく考えられたテンプレートやISO/IEC/IEEE 29119を活用すれば、考慮の抜け漏れを防ぐことができるでしょう。しかしながら、もし国際規格を参考にするのであれば以下のような点にも注意を配りたいところです。

規格は“参考”であって“強制”ではない

　規格はあくまで参考にとどめておきましょう。対象のプロジェクトの規模に沿わないものなどは無理に適用せずに、使える所だけ使うことを意識しましょう。

形式よりも“目的”を忘れない

　テスト計画書の目的は、品質を保証するためのテストが正しく実行されることです。それで、規格を用いる際は、形式にこだわるよりも、「なぜこのテストが必要か」「どう品質を確保するか」が説明できているかどうかを確かめるようにしましょう。例え立派な文書だとしてもテストのために活用されなければ意味がありません。

用語の定義と対象規格を明記する

　用語は人によって認識が異なることが多々あります。認識が違うままだと、検証がうまく進みません。テスト計画書には用語集をつけるようにしましょう。そうすれば、関係者間で認識の違いに頭を悩ます必要がなくなります。

　また、レビューをしやすくしたり、トレーサビリティを確保するためにも、参考とした国際規格は明記するようにしましょう。通常は、テスト計画書の冒頭に参考にした国際規格を記します。

実務とのギャップを認識しておく

　規格は理想的な内容が書かれています。現実の現場では、納期・人員・予算の制約があります。実行可能性を重視し、「実務で使える形」にカスタマイズする必要があることを覚えておきましょう。過去のプロジェクトで使用したものを使いまわすときには、今回のプロジェクトで必要な内容になっているか十分に検討するようにしましょう。

　これらに加えて、何よりもテスト対象について知ることが大事です。システム概要図レベルのシステム構成や、実装される機能群の構成などを概要レベルで把握しておくことは必要です。これらを把握していなければ、なぜこのテストが必要なのかといったテスト計画の根幹に関わる部分で正しい判断ができなくなってしまいます。

まとめ

　テスト計画書とは、ソフトウェアテストをどのように行うかをまとめたものでした。これがあれば、チーム内またはチーム外の関係者とも共通の認識ができて、テストの漏れ・重複また、トラブルを回避するのに役立ち、テストが円滑に進みます。良い計画をたて、良いテストを行っていく。そのために欠かせないのが、テスト計画書だといえます。テストの概要をよく把握し、テスト計画書に記載する項目についてよく考慮するようにしましょう。

お問い合わせはこちら

この記事をシェアする