【実践ガイド】テスト計画の基礎と策定方法

はじめに: テスト計画の難しさ

近年、IT業界は最先端テクノロジーを筆頭に益々の拡大を続けています。
ソフトウェア開発市場もその例に漏れず、 2023年は前年比9.5%の拡大をしています。
(参考: IDC Japan)

マクロな視点では右肩上がりの成長を続けている一方、
ミクロな視点(開発ベンダーの立場) では、年々ソフトウェア開発の難易度は増しています。

顧客から求められる数々の要望、そしてその要望を叶えたうえで不具合は極力発生しない
高度なシステムが求められます。

不具合が極力発生しないシステムを開発するためには、高精度なテストが不可欠です。
しかし、テストの根幹を担う「テスト計画」は一筋縄で策定できるものではなく、
プロジェクトの納期および求める品質の達成に向けて様々なファクターを定義する必要があります。

開発プロジェクトのPMを任された新任の方は特に重荷に感じることでしょう。

今回はシステム開発プロジェクトの実経験を基に、テスト計画の策定方法について解説いたします。
システム開発プロジェクトのPMを任されたもののテスト計画書の策定経験がなく困っている方、
テスト計画書策定の経験はあるもののさらに品質を高めたい方は、ぜひご一読ください。

テスト計画とは

システム開発プロジェクトにおいては、システムの品質を確認するテスト工程が設けられます。
テスト工程は「テスト計画」「テスト設計」「テスト実施」「テスト報告」の大きく4ステップで構成されています。

その内、本稿の対象であるテスト計画は、テスト工程を滞りなくかつ求める品質で進められるよう準備するステップを指します。

例えば、テストを実施するスケジュールがプロジェクト関係者間で合意していなければ
テスト実施者は納期を意識してテストすることもなく、当然テストが期日内に完了する可能性は下がります。

そういった事態が発生しないよう
「どのような種類のテストを誰が、いつ、どうやって、なんのために実施するか」を定義するのがテスト計画のステップです。
一言で言えば、開発したシステムの品質担保を網羅的、かつ期日通りに実施するために必要となります。

テスト計画の策定タイミングと策定者

テスト計画を策定する際の重要なポイントの1つに、策定するタイミングがあります。
テスト実施前までに策定すれば良い、というのはその通りなのですが
その準備期間を甘く見積もっていると、プロジェクト遅延の一因になりかねません。

テスト計画は原則、いくつかのステップで構成されており
想定以上に時間を必要とします。（以下、ステップ例）

1. テストに対する要求(期日/テスト精度)の整理
2. テスト計画書（案）作成
3. テスト計画書（案）レビュー　※プロジェクト上位層
4. テスト計画書最終化
5. テスト計画書の説明/展開　  　※To:プロジェクト関係者

特に3:レビューと5:説明/展開は、プロジェクト規模が大きくなればなるほど
所要期間も長引く傾向にあるので、その点を考慮したタスク設計が必要です。

早ければ設計フェーズから、遅くとも開発フェーズ時点で策定するのが望ましいです。

プロジェクト規模にも依りますが、想定以上に時間が必要な作業工程であることを
十分留意してプロジェクトに臨むのが良いでしょう。

テスト関連ドキュメントの構成

これまでに説明の通り、テスト計画においては「テスト計画書」を策定します。
しかし、実際にテストを実施するに当たっては、その他いくつかのドキュメントが必要となります。

テスト計画書含む、テスト関連ドキュメントそれぞれの役割を捉え違えていると、
本来、テスト計画書で定義するべきことが漏れたり、粒度感がズレる可能性があります。
そのため、テスト関連ドキュメントの内容・目的を正しく理解することは非常に重要です。

ドキュメント	内容	目的
テスト計画書	テスト方針(誰が、いつ、どうやってテストするか)を定めたドキュメント	テストを網羅的かつ期日通りに完了させること
テスト仕様書	テストする機能やテストのより具体的な方法を記したドキュメント	テスト実施者全員が同じ方法でテストできるよう認識を統一すること
テストシナリオ	システム利用(業務)の一連の流れを記したドキュメント ※テスト仕様書の一部	ユーザの業務フローに沿ってシステムが正常に動作するか確認すること
テストケース	操作手順、合格基準を記したドキュメント ※テスト仕様書の一部	テスト実施者全員が同じ手順・観点でテストできるよう認識を統一すること
各種テスト管理表	テストの進捗・発生した障害を管理するドキュメント	テスト計画で定めた方針通りにテストを完了できるようにすること
テスト報告書	実施したテストの結果を取り纏めたドキュメント	ステークホルダーへ結果を示し、テスト完了を合意すること

テスト計画書策定の方法

ここからは具体的にテスト計画書を策定する上で、
何を定義すべきか、また定義する際のポイントについて解説いたします。

テスト計画書では、主に以下5つの項目を定義する必要があります。
　※プロジェクト規模や特定に応じて変動します

1. テスト方針・目的
2. テストスケジュール
3. テストスコープ
4. テストレベル・観点
5. テスト技法

各項目にて定義すべきことのサンプルと併せて順に見ていきましょう。

1:テスト方針

テスト計画書では、まずテストの全体的な方針について記載します。

テスト方針は、プロジェクト規模・特性によって変動しますが
基本的にはテストにおいて、QCD（Q:品質/C:コスト/D:納期）の内どれを重視するかを定義します。

例えば現行システムの契約期間が迫っており、いち早くシステムをリプレイスする必要がある場合
「D:納期」を重視するため、テストは最低限必要な品質を担保するに留め、短期間で完了させる方針となるかもしれません。

★作成時のポイント
テスト方針は、そのプロジェクトのテストの進め方を決定づける重要な要素です。
そのため、関係者間で認識にズレが発生しないよう、表現には十分注意しましょう。
例えば、先の例で挙げた「D:納期」を重視する方針において、テスト実施者が「Q:品質」は一切無視して
とにかく短期間で終わらせるという認識を持ってしまったら致命的です。(実際に発生するケースは稀ですが)

関係者誰もが同じ認識を持つことができる伝え方を意識することが大切です

2:テストスケジュール

次に、テストのタイムラインを示すスケジュールを定義します。

基本的には、テスト（単体テスト～受入テスト）毎に、
いつから開始して、いつまでに完了させるか記す必要があります。

スケジュールの策定手法はいくつか種類がありますが、
大きく2つの軸（トップダウン/ボトムアップ）から考慮するのが一般的です。

・トップダウン（納期から逆算）
・ボトムアップ（テスト工数積み上げ）

上記2つの軸のバランスを取って全体のスケジュールを決定することになります。
プロジェクト方針に応じて、どちらの軸を重視するべきかが変動する点には留意しましょう。
（納期重視であれば、トップダウンの軸が優位となる）

★作成時のポイント
スケジュールには可能な限りバッファを織り込みましょう。
プロジェクト全体スケジュールを策定する際にバッファを織り込む思想はごくごく当たり前なことですが、
特にテストスケジュールを策定する際には、バッファの重要性が高まります。

なぜならテスト工程には不確定要素が多く潜んでいるからです。
テストを通じて、どの程度バグが発生するか、またそのバグの深刻度がどの程度かは、実際にテストをしなければわかりません。
そしてバグはテスト工程の中で修正が必要なので
バグの量、深刻度に応じて、テスト工程が延伸する可能性があります。

そのため、テストスケジュールを策定する際は
深刻なバグが多数発生した場合に備えて、ある程度余裕を持った設計が大切です。

 

3:テストスコープ

次に、テストスコープ（テスト対象）を定義します。

どのシステムのどの機能に対してテストが必要かを定義することによって
関係者間の認識を統一し、テスト漏れを防止することが目的です。

基本的にはシステム構成図の内、新規構築・改修したシステムがテストスコープに該当するので
システム構成図ベースで示すのが良いでしょう。

★作成時のポイント
先述の通りテストスコープを定義する目的は、テスト漏れを防止することです。
テスト漏れを防止するためには、漏れのないテストスコープ定義が必須です。

どのシステムに対してテストが必要か判断するのは、一見容易に思えますが
短絡的な判断をすると、後々痛い目を見るかもしれません。

特に様々なシステムが複雑に絡み合ってサービスを提供している場合、
1つのシステムを改修するだけであっても他のシステムへ影響を及ぼすケースがあります。
（例えば、システム間の結合部分等）

プロジェクト関係者間で認識を合わせれば漏れが発生することはないかと思いますが、
新規構築もしくは改修したシステムのみが必ずしもテストスコープになるわけではないことは念頭に置いておきましょう。

4:テストレベル・観点

次にテストレベルとテスト観点を定義します。

簡単に言えば、「どのような種類」のテストを「どんな観点」で実施するかを記すことで、
テスト実施者間のテスト内容に対する認識統一を図ることが目的です。

プロジェクトの特性に応じてテスト種類の指す定義も若干変動することはありますが、
基本は以下4種類のテストを順番に実施するのが一般的です。

・単体テスト　　
・結合テスト
・システムテスト
・受入テスト

★作成時のポイント
テストレベル・観点を定義する際は、必ず各テストで求めるレベル感（合格基準）を明確に定めましょう。

求めるレベル感を定義していない場合、本来1つ前のテストで確認が完了しているべき機能で不具合が発覚し、後から不具合修正・改修の無駄な手戻りが発生する可能性が高まります。

例えば、単体テストにおいて「開発したモジュールが正常に動作することを確認すること」とした場合、
単体テスト終了時の品質は各実施者で異なる可能性があります。

なぜなら、どの程度正常に動作すればよいかが定義されていないためです。
理想は100%正常に動作することかもしれませんが、バグが一切発生しないシステムは存在しません。

テストレベル・観点を定義する際は、誰もが同じゴールに向かって進めることができるよう
事前に求めるレベル感（合格基準）を明確に定めましょう。

 

5:テスト技法

次に、テスト技法（テストの方法）を定義します。

テスト技法を定義することによって、各テスト実施者によるテストの品質を統一させる目的があります。

ここでは実際のプロジェクトでも扱うケースの多い技法を2つ解説します。
（単体テスト・結合テストが対象の技法）
①：ホワイトボックステスト
プログラムの「入力値」に対して正しい「出力値」が表れるか、また過程となる「内部構造」も正常に動作しているかテストする技法を指します。
簡単に言えば、プログラムが出力するまでの過程と結果が全て正常であるか確認する技法となります。

品質は確実に担保できる一方、その分1つのプログラムあたりにかかる工数が増加します。

②：ブラックボックステスト
プログラムの「入力値」に対して正しい「出力値」が表れるか、のみをテストする技法を指します。
プログラムが出力した結果のみに対して正常であるかを判断し、過程は一切確認しない技法となります。

工数面での負担は軽減できるものの、品質はホワイトボックステストと比較して落ちます。

★作成時のポイント
これまで同様、プロジェクト方針に応じて扱う技法を判断しましょう。

仮にプロジェクトで品質を求めているのに、ブラックボックステストを採用した場合
後から不具合が発生するリスクはホワイトボックステストと比較して高まります。

それぞれのテスト技法の特性を理解したうえで、プロジェクトに合致する技法を採用する意識を持ちましょう。

最後に:テスト計画で大切なポイント

本稿では、主にシステム開発プロジェクトを任された新任の方向けに、実プロジェクトを踏まえたテスト計画策定方法について解説をいたしました。

テスト計画は、システム開発プロジェクトの工程において成功を司る1つの要素です。
テスト計画の品質が低ければ、その分テストで不具合が発生する確率は高まり、
その1つの不具合が最終的なシステムの動作上の致命的なリスクになる可能性があります。

テスト計画の品質を高めるためには、ここまでにも何度かお伝えしている通り
「関係者間の認識を確実に統一させること」が非常に大切です。

そのためには文言1つ取っても、誰もが同じ解釈をできるようにこだわりを持つ必要があります。
1つ1つこだわりを持って考えるのは大変なことかもしれません。

しかしそれを積み上げた時に、プロジェクトを成功に導くテスト計画書を策定することができます。
本稿が少しでもそのサポートになれば幸いです。

【参考】
・IDC Japan「2023年の国内ソフトウェア市場は前年比9.5％成長 ～IDC Worldwide Semiannual Software Tracker を発行～」

• 【UiPath Orchestrator】少ない工数でロボットを安定的に運用するための管理ツール