2021.09.02

テスト計画書とは？その作成方法と乗り越えるべき3つの壁について紹介

Introduction

テスト計画は、システムの品質を左右する重要なドキュメントです。プロダクト品質を決定づけるテストの品質はテスト計画で決まるといっても過言ではありません。

では、そのテスト計画をどのように策定すれば良いのか？そんなお悩みをおもちのみなさんへ、テスト計画書で定義すべき事柄から、計画策定に立ちはだかる壁とそれを乗り越えるコツを紹介します。

テスト計画書とは

テスト計画書とは、テストの目的や戦略、テストを実施するうえで必要なタスクやそれらを実行する留意点、およびスケジュールをまとめたドキュメントです。

テスト計画書は、「全体テスト計画書」と「個別テスト計画書」の2種類に分類されます。

全体テスト計画書は、単体テスト工程や結合テスト工程などのテストレベルを定義し、各テストレベルで必要な環境や要員などのリソースを定義します。また、進捗や品質のモニタリング、不具合管理などのテストレベルに固有しない各種ルールを定義します。

一方、全体テスト計画書で定義されたテストレベルごとに作成されるのが個別テスト計画書です。テストの準備と実行のタスクを具体的に実行できるまで詳細に、テスト観点やプロセスを定義して計画を策定します。

テスト計画入門動画

＜テスト計画書の構成イメージ＞

テスト計画書を作る目的とは

適切にテストが実施できていない場合、リリース後に不具合が頻発してしまうことがあります。このような状況を分析していくと、プロダクトやプロジェクト特性から行うべきテストが漏れていることが散見されます。
この原因の多くは、「プロジェクト都合ありきでテスト計画を立てている」、または「過去案件や社内標準サンプルをそのまま流用して、目的に応じたテスト計画になっていない」ことが見受けられます。
このような状態のテスト計画では、「関係者間の認識齟齬」「各テストレベルの目的が不明確」「十分なテスト実行ができているかの判断ができない」という問題が発生し、品質を著しく下げてしまいます。

フルスタックエンジニアが数名で開発しているようなスタートアップフェーズであれば、このような問題が顕在化することは少ないですが、グロースしてさまざまなバックグラウンドをもつ開発メンバーが参画すると、顕著に品質の低下に表れてきてしまいます。

リリース後の不具合は、失敗コストが増大するばかりではなく、これまで築き上げたプロダクトへの信頼性を大きく損なってしまうことになります。そのような事態にならないためにも、プロダクト・プロジェクトの目的に適した綿密で検討漏れがないテスト計画を策定することが、プロダクト品質を高めるためのテストにおいては重要な要素となります。

テスト計画入門動画

テスト計画書に記載する要件とは

テスト計画書に記載する要件は、テストを実施する目的からテストに関するスケジュールまで、テストを実施するために必要な要件を多岐に渡って検討する必要があります。

テスト計画書テンプレート

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

プロジェクトの背景とは、テストの対象となるシステムを開発するプロジェクトの要件(何のために何を開発するのか)を指します。

テストの目的とは、プロジェクトの背景を踏まえて、どの程度の品質を求めるべきなのかを設定します。
例えば、社会インフラを担うシステムと、コンシューマー向けITサービスでは、求められる品質が異なります。
コンシューマー向けITサービスに対して、社会インフラを担うシステムと同様の品質を求めることは、無駄なコストに繋がる可能性があります。

以上を踏まえ、テストの目的では、適切なテストを実施できるように、プロジェクトとその成果物であるプロダクトに求められる品質を明確にする必要があります。

(2)テストレベルの定義

コンポーネントレベルまで分割された機能を、開発モデルやテスト対象を勘案し、どのテストレベルでどのように結合させてテストしていくのかを決めます。また、各テストレベルで求められるテストの要求事項(検討イメージは下表を参照)を定義します。

＜テストレベル定義の検討イメージ＞

本要件がテストの成否を決めるもっとも重要な要件です。また、テストレベルの定義は、開発チームまたは開発者によって概念や認識が異なることが多いため、関係者を交えて認識合わせを行いながら、検討を進めることが肝要です。

(3)テストの範囲

テスト対象となるソフトウェアとハードウェアの範囲や、他システムとの接続点の範囲を明記します。
また、テストの制約事項(テスト環境の制約や、実施できないテストなど)を明記し、計画時点で想定されるテストで担保できない事象を記載します。

(4)アプローチ

テスト対象の機能・システムの構成、テストタイプ、テスト環境を勘案し、テストレベルをどのような順番で実施するのか、直列・並列での実施が可能かなど、テストレベルの構成を記載します。

(5)テスト環境

テスト環境に必要なスペック・構成・ネットワークなどの情報を記載します。複数のサブシステムやプロジェクト外部のシステムが必要な場合は、必要な面数と利用時期を明確にしてテスト環境を確保します。
なお、漏れがちなのが、ドライバ・スタブなどのテストツールとクライアント環境の考慮です。忘れずに検討しましょう。

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

テストを開始する条件、テストを中断させねばならない基準(再開の条件も含む)、終了条件を明記します。
特に終了条件は、テストの合否条件を記載しますが、スケジュールやリソースなどの関係で条件を満たせずに終了させるケースも想定されるため、許容できる条件も明記します。

(7)テストのタスク

テスト実施に向けた準備タスク、テスト実施に必要なタスクを記載します。また、そのタスクを実施する際に特殊な技能が必要であれば、その技能要件も記載します。

(8)モニタリングと管理

テストの進捗や、機能単位の不具合混入率などの品質状況を適時モニタリングする必要があります。
それらのモニタリング内容を定義し、テスト進捗管理や不具合管理などの管理ルールを記載します。

(9)テストの成果物

テストで作成すべきドキュメント類とそれを作成するタスクの関連性を定義します。
もちろんテスト計画書も成果物の一部となります。

(10)リスクと対策

プロジェクトで発生しうるリスクを一覧にまとめ、リスクの予防策、リスクが顕在化した場合の是正策を検討し、その対応の優先順を明記します。

(11)要員計画とトレーニング計画

テストに必要なスキル要件に基づき、要員計画を策定します。また要員に対してトレーニングが必要な場合は、そのトレーニング計画を策定します。

(12)体制とスケジュール

テストで発生するタスクを基に、それらを実施する組織・部門、外部委託先の体制を明記し、その役割や担当(責任)範囲を記載します。
また、タスクを担う役割の関係を定義し、アプローチ要件を加味してスケジュールを策定します。

テスト計画講座

※ご登録いただくとその場で無料動画の視聴が可能です。
株式会社SHIFTが運営するソフトウェアテスト・品質保証の人材育成を手掛けるヒンシツ大学のお試し講座「テスト計画」をご視聴いただけます。テスト計画とはどのようなものか、テスト計画には何が必要なのかといった基礎的な考え方について事例を交えてご紹介しています。

ダウンロード

テスト計画書の作成について

では、実際にテスト計画書を策定していくために、必要となるコツと乗り越える壁を説明します。

国際標準規格「ISO/IEC/IEEE 29119-3: Test Documentation」

「明日からゼロベースでテスト計画の策定をお願いします」という依頼があったら、あなたはどうでしょうか？
正直、ゼロベースでといわれたら困りますよね。

そのような時は、「ISO/IEC/IEEE 29119-3: Test Documentation」を活用しましょう。
この規格は、「テスト計画」や「テスト設計」などのテストプロセスに必要なドキュメントの国際標準規格となります。これをベースに検討を進めれば、ゼロベースや過去案件のテスト計画よりも格段に検討漏れが少なくなります。

ただし、この規格はケースバイケースの事例集ではありません。そのため、あくまで検討すべきテストの要件を漏らさないためのフレームワークと捉えて活用することをお勧めします。

テスト計画書作成の難しさ

テスト計画を策定することの難しさとは何でしょうか？
その難しさは次の3つに集約されると考えています。

一つ目は、プロジェクト全体とシステム全体の背景と概要を把握することの難しさです。
プロジェクトマネージャーやリーダーであっても、詳細を説明できても、概要レベルでの全体像の説明や表現ができていないことが意外にも多いのが実情です。しかしこれらを把握することが、テスト計画を検討するうえでの最低条件といえます。特にシステムを機能分解していく過程を理解することが難しく、これが理解できないとコンポーネントから機能、そしてシステムと結合していくテストレベルを検討しづらくなるといえるでしょう。

二つ目は、テスト用語の認識の差です。人によっては定義がバラバラで、かつテスト用語は何でも「～テスト」となりがちなため、使っている用語で認識齟齬が大きく発生し、いつまで経っても検討が進まないことがあります。

そして三つ目は、要否の取捨選択です。例えば、過去案件で性能テストのテストタイプを実施していたとします。その時、今回のプロジェクトでも性能テストは本当に必要でしょうか？もしくは不要として判断してよいのでしょうか？この選択一つで品質に大きな影響を与えるため、非常に判断が難しいものとなります。

このように、テスト計画は検討過程の難解さをどのように乗り越えるのかがポイントだといえます。

テスト計画作成におけるコツ

もっとも大事なことは、テスト対象をよく知ることです。ここでの「知る」というのは、細かな仕様を押さえるのではなく、システム概要図レベルのシステム構成や、そのシステムに実装される機能群の構成などを概要レベルで漏れなく押さえることを意味します。

また、テスト計画を考えるうえでは、テスト計画に対する知識も重要な要素です。現在は、テストの重要性に対する理解が進み、テストに関する規格や資格、そして分科会や書籍などでテスト計画の知識を手軽に入手することができます。

テスト対象の正確な把握と理解、そして有効なテスト計画の知識を活用しながら、テスト計画の検討を進めることが最短ルートといえます。

ただし、最短ルートとはいえ、テスト計画の経験が多くはない方が、自助努力でテスト知識を習得しながら1～2ヶ月でテスト計画を策定することは現実的でしょうか？これは非常に難しいと思います。
これができるのであれば、世の中から失敗プロジェクトは大幅に減っていることでしょう。

テスト計画の検討が効率的に進められない、テスト要件の要否判断で根拠ある判断が難しい、テスト計画に集中したいけど目の前の設計工程が炎上しているなど、テスト計画にお悩みを抱えているのであれば、テストマネジメントコンサルティングを導入してしまうというのも一つの手ともいえます。

特に、久しぶりにプロジェクト化すべき大規模な案件が発生した時や、品質保証に対する考え方をシフトする時などのシチュエーションでは、そもそも品質スペシャリストのリソースが足りていない状況が散見されます。
そのような過渡期的な状況下であれば、自助努力の一択ではなく、「品質に対する豊富な知見」を外注するという選択があってもいいのではないかと考えます。

テスト計画入門動画

テスト計画の精度を高めるためには・・・

もちろん社内に知見のあるテストマネージャーがいれば精度の高いテスト計画が可能です。

しかし、テスト領域に熟練したエンジニアが少ないという実情や、前述の複数のプロジェクトが同時に進行している場合、経験豊富なテストマネージャーが担当できないことで、充分なテスト計画が立てられないことも少なくありません。そのため、テスト領域に特化した第三者企業への支援を依頼する企業も増えています。

これは、品質に対する世間の意識が高まったことだけでなく、近年のシステム開発の複雑化、短納期化なども要因にあります。そのため、開発という生産的活動と品質保証を並行して実施し、品質を担保することがスタンダードになっており、テスト計画の難易度も従来よりも高くなっていると言えます。

まずは、自社の品質保証体制やプロジェクト状況を品質保証の専門企業に共有し、“目的に対して今何をすべきか”を相談してみるのも良いかもしれません。

例えば、ソフトウェアテスト・品質保証の業界大手、株式会社SHIFTでは、品質保証業務に関わる方に向けた無料個別相談会も行っています。品質保証のプロに話を聞けるため、こういった専門会社のサービスを活用してみることもオススメします。

品質保証無料個別相談会のお申込みはこちら

まとめ

テストを適切に実施するためには、適切なテスト計画を立てる必要があります。
テスト計画の策定においては、多岐に渡るテストの要件の検討や、関係者の認識齟齬の解消など、大小様々な壁が待ち受けており、一筋縄ではいかない難しさがあります。
そのような乗り越えづらい壁があれば、テストマネジメントコンサルティングを行っているSHIFTの豊富な品質保証の知見をご活用いただき、お客様と弊社の二人三脚でテスト計画の壁を乗り越えていきたいと考えています。

資料ダウンロード/動画視聴

テスト計画書テンプレート

ソフトウェアテスト入門動画

テスト計画入門動画

SHIFTサービス資料

テストサービス導入事例集

前のページへ

次のページへ

コラム一覧に戻る

テスト計画書とは？その作成方法と乗り越えるべき3つの壁について紹介

Introduction

テスト計画書とは

テスト計画書を作る目的とは