テスト計画の骨格は「5W1H」で考える！テスト計画を成功に導くための心構えとは

テスト計画は、テスト工程における目的や手法、制約などを明確にし、テスト工程の大枠とそのリスクを明示化する作業です。

一方で、なくても何とかなってしまうものと、「テスト計画」を捉えてはいないでしょうか？
たしかに、ごく小規模な改修や緊急リリースなど時間がない場合、テスト計画がなくても問題とならないことはあります。
しかし、計画されていないテストは、テストそのものの遅延やテストケースのレビューに時間がかかったり、不具合の管理ができなかったりなど、さまざまな問題を引き起こす可能性があります。
今回はテスト計画策定時に配慮したい点や作成タイミングについてご説明いたします。

テスト計画とは

JSTQBの用語集では、テスト計画を以下のように定義となっています。

“テスト計画（test plan）：
計画されたテスト活動の狙い、アプローチ、リソース、スケジュールを記述するドキュメント。テストアイテム、テストすべきフィーチャ、タスク、各タスク担当者、テスト担当者の独立の度合、テスト環境、用いるテスト設計技法と開始・終了基準、それらの選択の理論的根拠、それに代替計画を必要とするあらゆるリスクを識別する。これはテスト計画プロセスの記録である。[After IEEE 829]”

一言で表すと、テストにおける5W1Hを決めるプロセスがテスト計画ということです。

テスト計画の種類

一口にテスト計画といっても、２つの種類にわけることができます。

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

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

全体テスト計画

全体テスト計画はそのプロジェクトにおけるテストの計画を策定するプロセスです。開発全体のなかで、テスト期間はどの程度とるのか、どのテストレベル（テストレベルに関しては、こちらのコラムで紹介しております）のテストを実施するのか、各テストレベルのスコープをどこまでとするかなどを定義していきます。

個別テスト計画

一方、個別テスト計画は各テストレベル単位の計画を策定するプロセスです。ここではそれぞれのテストの詳細なスケジュールやスコープなどを定義していきます。

両者の違いを簡単にいいかえるならば、全体テスト計画はテストの要件定義、個別テスト計画はテストの外部設計にあたります。テストを通して何をしたいのかを明らかにしてから、それぞれのテストではどのようなことを検証していくのかを明示化していきます。

テスト計画の骨格

テスト計画の骨格はどのテストにおいても共通の考えで成り立っています。今回はシステムテストを事例にテスト計画の骨格を説明いたします。
※システムテスト(ST)とはテスト計画の骨格は以下5W1Hに置きかえることができます。

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

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

全体テスト計画の5W1H

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

全体テスト計画ではテストの概要がメインとなるため、具体的な記載は個別テスト計画と比較すると少なくなります。
全体テスト計画でウェイトを置くべきは、Why・What・Whoの部分です。
「Why」は、そのプロジェクトにおける品質水準を決めるプロセスともいえます。プロジェクトとしてどこまで検証して、品質を担保するのかを整理します。
そのためにはどのような開発であるのかを定義する必要があり、ここから目指すべき品質が導かれます。
「What」では「Why」で整理したポイントをもう少し深堀りします。何がテスト対象となり、どんなテストレベルで、どこまで見るのかを定義します。
このポイントは非常に重要です。例えばマルチベンダーで開発を行っている場合、ベンダーごとで同じテストレベルにもかかわらずテスト粒度が異なったり、結合テストを行ったら単体で検知すべき不具合が多発したりするということはないでしょうか？
それは、このWhatが十分に整理されていないことが原因である場合があります。すなわち、各テストレベルの粒度が決定していないために、テストの抜け漏れなどが発生するリスクが高まるのです。
さらに性能試験・負荷試験などの非機能テストの実施の有無と、実施するタイミングや、各テストレベルの納品物とエビデンスの取り扱いに関してもこの段階で整理したほうがよいでしょう。
「Who」ではだれがテストにかかわるかを整理します。

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

個別テスト計画の5W1H

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

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

個別テスト計画では当該のテストレベルの詳細がメインとなるため、記述はより具体的になります。
ここでウェイトを置くべきは、When・Where・Howです。
「When」では、テストレベルのスケジュールを策定します。テスト設計・テスト実行がまず思いつくかもしれませんが、あわせてテスト準備もスケジュール上に乗せることが極めて重要です。
例えば、スマートフォンを利用したテストの場合は、その調達やテスト用のアプリインストールなどの準備が欠かせません。このような準備期間を検討しないと予定通りテストを開始できないリスクが高まります。
また端末の準備だけでなく、検証環境へのリリースといったこともテスト準備に含めて検討することが重要です。
「Where」ではテスト環境に関して具体的な策定を行っていきます。前述のようなスマートフォンを利用するテストの場合、OSや端末自体の具体的な選定、バージョンの指定を行う必要があるでしょう。
また、外部接続を伴うテストを想定される場合は、その接続先に関する調整も行う必要があります。接続先が準備できない場合はスタブ／ドライバを利用するかどうかも含めて検討し、整理する必要があります。
「How」ではどのようにテストを進めていくのか具体的に策定していきます。進捗報告の方法はどのように行うか、不具合管理は何を利用するのかについて決めていきます。 進捗報告に関しては、何をどのタイミングで誰に行うのか具体的に詰めておきましょう。
不具合管理に関しても同様ですが、連絡方法のみならず、修正された場合どのようなフローで連絡し、リリースが行われるかをタイミングも含めて検討しておくとよいでしょう。

テスト計画作成時の心構え

最後にテスト計画の作成時／作成後に注意しておきたい点を２点あげます。
いずれも開発の不確実性に対応するための心構えです。

テスト計画は変更がありうるものだと認識すること

開発の状況により思いもよらぬ変更や追加開発が発生するのはよくあることです。
それにあわせて開発のスケジュールの変更や体制の検討などは行われますが、テスト計画の変更は後手に回ってしまうことが多いのではないでしょうか。
しかし、テスト計画ではテストの対象や方法について定めており、変更にあわせて修正することが肝要です。修正を怠ればテスト漏れなどの問題を引き起こす原因になりかねません。
したがって、テスト計画は例えば工程の間などのタイミングや、追加開発や仕様変更などで見直し、修正することをおすすめします。
また修正する場合は、全体テスト計画と個別テスト計画で相違が起きないように十分注意しましょう。

２回以上、ステークホルダーを巻き込んでレビューすること

テスト計画のレビューを行うと、特に個別テスト計画のテスト方針の立案における要件漏れや検討抜けがレビューの対話を通して明らかになることが少なくありません。このことは、早期に不具合を除去することにつながります。
しかしながら、このような早期発見が相次ぐと開発工程のリスク抽出に意識が向いてしまうことが多く、テスト計画自体の問題やテスト工程のリスクに目が向かなくなります。
１回目は開発との認識合わせ、２回目はテスト計画自体の検討という意識をもって行うとよいでしょう。

まとめ

全体テスト計画はテストの要件定義、個別テスト計画はテストの外部設計です。これらの計画が十分につくりこまれていない場合、テストで検出すべき不具合を見逃すリスクは増加します。
またテスト計画を作成するタイミングは開発の不確実性が存在する状態であることがほとんどです。したがって、適宜、見直しと修正を行うことが必要です。テスト計画をきちんと行うことが、テストの成功につながる近道であると考えます。