テスト計画書とは
テスト計画書とは、テストの目的や戦略、テストを実施するうえで必要なタスクやそれらを実行する際の留意点およびスケジュールをまとめたドキュメントです。
テスト計画書は、「全体テスト計画書」と「個別テスト計画書」の2種類に分類されます。
全体テスト計画書は、単体テストレベルや結合テストレベルなどのテストレベルを定義し、各テストレベルで必要な環境や要員などのリソースを定義します。また、進捗や品質のモニタリング、不具合管理などの各テストレベルに共通の各種ルールを定義します。
一方、全体テスト計画書で定義されたテストレベルごとに作成されるのが個別テスト計画書です。テストの準備と実行のタスクを具体的に実行できるまで、詳細にテスト観点やプロセスを定義して計画を策定します。
テスト計画についてはこちらの動画がおすすめです。
＞＞「テスト計画 講座」のページへ
テスト計画書のテンプレートはこちらからダウンロードください。
＞＞「テスト計画書テンプレート」のダウンロードページへ
テスト計画書とテスト仕様書の違い
テスト計画書によく似た名前のドキュメントに、テスト仕様書があります。どちらもテストに関する内容を記載した重要なものですが、テスト仕様書はテスト実施に関わる手順の詳細をまとめたドキュメントです。一方のテスト計画書は、テストの方針や実施に必要な人員およびスケジュールなどを記載したものです。
順番としては、テスト計画書で方針や人員を明確にし、それに則って詳細を記載したテスト仕様書が作成されるという流れになります。テスト計画書は実施するテストの土台であり、テスト仕様書はそのテストの具体的な流れを記載したものと覚えておきましょう。
テスト仕様書についてはこちらをご覧ください。
＞＞テスト仕様書の書き方～テストケース作成のポイント～のページへ
テスト計画書を作る目的とは
テスト計画書は、開発したシステムの品質を担保するために作成します。適切にテストが実施できていない場合、リリース後に不具合が頻発してしまいます。このような状況を分析していくと、プロダクトやプロジェクト特性から行うべきテストが抜け漏れていることが散見されます。原因の多くは、次の2つに集約できます。
・プロジェクト都合ありきでテスト計画を立てている
・過去案件や社内標準サンプルをそのまま流用して、目的に応じたテスト計画になっていない
上記のようなテスト計画では、関係者間の認識齟齬が発生したり、各テストレベルの目的が不明確になったり、十分なテスト実行ができているかの判断ができなかったりという問題が発生し、品質を著しく下げてしまいます。テスト計画書を作成しなかった場合も、同様の事態が発生する可能性があります。
このような事態を防ぐため、テスト計画書の作成は非常に重要なのです。フルスタックエンジニアが数名で開発しているようなスタートアップフェーズであれば、このような問題が顕在化することは少ないでしょう。しかし、ある程度の規模でさまざまなバックグラウンドをもつ開発メンバーが参画すると、顕著に品質の低下に表れてきてしまいます。
リリース後の不具合は、対応に非常に多くのコストがかかるばかりではなく、これまで築き上げたプロダクトへの信頼性を大きく損なってしまいかねません。そのような事態にならないためにも、プロダクト・プロジェクトの目的に適した綿密で検討漏れがないテスト計画を策定することが、プロダクト品質を高めるためのテストにおいては重要な要素なのです。
ソフトウェアテストに外注の選択肢を
「ソフトウェアテストを外注すべき5つの理由とは！？」の資料をぜひご覧ください。
テスト計画書のサンプル
テスト計画書にはさまざまな書き方がありますが、共通しているのはテストの目的やテストレベルの定義、テスト範囲などが記載されている点です。いいかえれば、テスト計画書1冊あれば、どのようなテストをどの程度の規模で行うのかがわかるドキュメントとなっています。以下は、SHIFTが提供しているテスト計画書のサンプルの一部です。
全体をご覧になりたい場合は、こちらのページからダウンロードすることができます。自社のテスト計画書作成の参考にしてください。
＞＞「テスト計画書テンプレート」のダウンロードページへ
テスト計画書に記載する要件とは
テスト計画書に記載する要件は、テストを実施する目的からテストに関するスケジュールまで、テストを実施するために必要な要件を多岐に渡って検討する必要があります。具体的な内容は以下の通りです。
・プロジェクト背景／テストの目的
・テストレベルの定義
・テストの範囲
・アプローチ
・テスト環境
・テスト開始、中断、再開、終了基準
・テストのタスク
・モニタリングと管理
・テストの成果物
・リスクと対策
・要員計画とトレーニング計画
・体制とスケジュール
それぞれの詳細について見ていきましょう。
プロジェクト背景／テストの目的
プロジェクトの背景とは、テストの対象となるシステムを開発するプロジェクトの要件を指すものです。プロジェクトの要件をわかりやすくすると、何のために何を開発するのかが明確になります。
テストの目的とは、プロジェクトの背景を踏まえて、どの程度の品質を求めるべきかということです。テストの目的では、適切なテストを実施できるように、プロジェクトとその成果物であるプロダクトに求められる品質を明確にする必要があります。
例えば、社会インフラを担うシステムとコンシューマー向けITサービスでは、求められる品質が異なります。コンシューマー向けITサービスに対して社会インフラを担うシステムと同様の品質を求めることは、無駄なコストに繋がるかもしれません。
テスト計画書では、これらの開発背景や目的を記載する必要があります。記載しない場合はテストの目的やゴールがぼやけてしまうため、品質の担保が難しくなります。
テストレベルの定義
テストレベルの定義とは、各テストレベルで求められるテストの要求事項を定めることです。コンポーネントレベルまで分割された機能を、開発モデルやテスト対象を勘案し、どのテストレベルでどのように結合させてテストしていくのかを決めます。検討イメージは下表を見てください。
＜テストレベル定義の検討イメージ＞
テストレベルの定義は、開発チームまたは開発者によって概念や認識が異なることも珍しくありません。関係者を交えて認識合わせを行いながら、検討を進めてテスト計画書に記載することが肝要です。本要件がテストの成否を決めるもっとも重要な要件といっても過言ではないでしょう。
テストの範囲
テスト対象となるソフトウェアとハードウェアの範囲や、ほかシステムとの接続点を明記します。また、テストの制約事項（テスト環境の制約や、実施できないテストなど）を明記し、計画時点で想定されるテストで担保できない事象を記載します。
アプローチ
テスト対象の機能やシステムの構成、テストタイプやテスト環境を勘案し、それぞれのテストレベルをどんなテストでどこまでで実施するのか、直列・並列での実施が可能かなど、テストレベルの構成を記載します。
テスト環境
テスト環境とは、どのようなデバイスやネットワークでテストを行うのかを記載する項目です。テスト計画書には、テスト環境に必要なスペック・構成・ネットワークなどの情報を記載します。複数のサブシステムやプロジェクト外部のシステムが必要な場合は、必要な構成と利用時期を明確にしてテスト環境を確保してください。
なお、漏れがちなのが、ドライバ・スタブなどのテストツールとクライアント環境の考慮です。忘れずに検討しましょう。
テスト開始、中断、再開、終了基準
テストを開始する条件、テストを中断させなければならない基準（再開の条件も含む）、終了条件を明記します。特に終了条件は、テストを完了とする条件を記載しますが、スケジュールやリソースなどの関係ですべてのタスクが終わらなくても完了とする場合もあり、終了させてよいと判断できるような許容できる条件も明記しなければなりません。
テストのタスク
テスト実施に向けた準備タスク、テスト実施に必要なタスクを記載します。また、そのタスクを実施する際に特殊な技能が必要であれば、その技能要件も記載しましょう。
モニタリングと管理
テストの進捗や、機能単位の不具合混入率などの品質状況を適時モニタリングしなければなりません。それらのモニタリング内容を定義し、テスト進捗管理や不具合管理などの管理ルールを記載します。
テストの成果物
テストで作成すべきドキュメント類とそれを作成するタスクの関連性を定義します。もちろんテスト計画書も成果物の一部です。
リスクと対策
プロジェクトで発生しうるリスクを一覧にまとめ、リスクの予防策やリスクが顕在化した場合の是正策を検討し、その対応の優先順を明記します。
要員計画とトレーニング計画
テストに必要なスキル要件にもとづき、要員計画を策定します。また要員に対してトレーニングが必要な場合は、そのトレーニング計画を策定しなければなりません。
体制とスケジュール
テストで発生するタスクをもとに、それらを実施する組織・部門、外部委託先の体制を明記し、その役割や担当（責任）範囲を記載します。また、タスクを担う役割の関係を定義し、アプローチとして決めた施策を加味してスケジュールを策定しましょう。
関連サービスについて
テスト計画書を作成する際のポイント
では、実際にテスト計画書を作成していくために、どのようなことに注意すればいいのでしょうか。必要となるコツは、主に次の3つです。
・国際標準規格「ISO/IEC/IEEE 29119-3: Test Documentation」を活用する
・テスト計画書作成の難しさを理解する
・テスト対象を知る
それぞれの詳細を解説します。
テスト計画書のテンプレートはこちらからダウンロードください。
＞＞「テスト計画書テンプレート」のダウンロードページへ
国際標準規格「ISO/IEC/IEEE 29119-3: Test Documentation」を活用する
「ISO/IEC/IEEE 29119-3: Test Documentation」とは、「テスト計画」や「テスト設計」などのテストプロセスに必要なドキュメントの国際標準規格です。細かな内容が記載されていますが、国際的に合意を得られたソフトウェアテストに関する規格の詳細だと思えばよいでしょう。テスト計画書作成時にこれをベースに検討を進めれば、ゼロベースや過去案件のテスト計画よりも格段に検討漏れが少なくなります。
ただし、この規格はケースバイケースの事例集ではありません。あくまで検討すべきテストの要件を漏らさないためのフレームワークと捉えて活用することをお勧めします。
テスト計画書作成の難しさを理解する
テスト計画の作成には、以下の3つの難しいポイントがあることを理解しておかなければなりません。
・プロジェクト全体とシステム全体の背景と概要を把握することの難しさ
プロジェクトマネージャーやリーダーであっても、詳細を説明できても概要レベルでの全体像の説明や表現ができていないことが意外にも多い。しかし、これらを把握していなければテスト計画を検討できない。特に、システムを機能分解していく過程を理解することが難しい。これが理解できないとコンポーネントから機能、システムと結合していくテストレベルを検討しづらくなるといえる。
・テスト用語の認識の差
同じ用語であっても人によっては定義がバラバラであることを理解しなければならない。テスト用語は「～テスト」となりがちなため、使っている用語で認識齟齬が大きく発生し、いつまでも検討が進まないことがある。
・要否の取捨選択
例えば、過去案件で性能テストのテストタイプを実施していた場合、その選択が必要か否かを判断しなければならない。該当のプロジェクトでも性能テストは本当に必要なのか、不要として判断してよいのかを的確に判断する必要がある。選択一つで品質に大きな影響を与えるため、非常に判断が難しい。
このように、テスト計画は検討過程の難解さをどのように乗り越えるかがポイントだといえます。
テスト対象を知る
もっとも大事なことは、テスト対象をよく知ることです。ここでの「知る」とは、システム概要図レベルのシステム構成や、実装される機能群の構成などを概要レベルで漏れなくおさえることを意味します。また、テスト計画に対する知識も重要な要素です。
現在は、テストの重要性に対する理解が進み、関連する規格や資格、書籍などでテスト計画の知識を手軽に入手できます。テスト対象の正確な把握と理解、有効なテスト計画の知識を活用しながら検討を進めることが重要です。
テスト計画にお悩みを抱えているのであれば、テストマネジメントコンサルティングを導入するというのも一つの手です。特に、前回から期間があいてプロジェクト化すべき大規模な案件が発生した時や、品質保証に対する考え方をシフトする時などのシチュエーションでは、品質に対する豊富な知見をもっている企業や専門家に外注するという選択があってもいいでしょう。
テスト計画の精度を高めるためには・・・
社内に知見のあるテストマネージャーがいれば、精度の高いテスト計画が可能です。しかし、テスト領域に熟練したエンジニアが少ないという実情や、前述の複数のプロジェクトが同時に進行している場合、経験豊富なテストマネージャーが担当できないことで、充分なテスト計画が立てられないことも少なくありません。そのため、テスト領域に特化した第三者企業への支援を依頼する企業も増えています。
これは、品質に対する世間の意識が高まったことだけでなく、近年のシステム開発の複雑化、短納期化なども要因にあるでしょう。そのため、開発という生産的活動と品質保証を並行して実施し、品質を担保することがスタンダードになっており、テスト計画の難易度も従来よりも高くなっているといえます。
まずは、自社の品質保証体制やプロジェクト状況を品質保証の専門企業に共有し、“目的に対して今何をすべきか”を相談してみるのも良いかもしれません。
株式会社SHIFTでは、品質保証業務に関わる方に向けた個別相談も行っています。品質保証のプロに話を聞けるため、こういった専門会社のサービスを活用してみることもオススメします。
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ
関連サービスについて
関連サービスについて
まとめ
テスト計画書は、ソフトウェアテストを適切かつ品質を担保するために必要なものです。テスト計画書を作成する際は、テスト要件の検討や関係者の認識齟齬の解消など、問題となるポイントが多くあります。難しい問題ですが、適宜外部の専門家などに相談するなど、対策を打つ必要があるでしょう。完成したシステムをきちんとテストするためにも、テスト計画書の作成は非常に重要なのです。
相談できる窓口や専門家が社内や身近にいないという方は、SHIFTまでご相談ください。SHIFTでは、これまで数多くのソフトウェアテストを実施しており、社外のソフトウェアテストの専門家としてお力になれることでしょう。開発からも対応しているため、システムに関するすべてのことを相談可能です。テスト計画書の策定で悩みを抱えているなどの場合は、ぜひSHIFTまでお問い合わせください。
＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ
よくある質問はこちら
＞＞ソフトウェアテストのよくある質問にお答えします。目的や種類、作業内容、外注先の選び方などを解説のページへ
ソフトウェアテストの悩みはSHIFTが解決できます！
「自社で効率よくソフトウェアテストを実施できない…。」
「どうしてもテスト工数が膨らんでしまう…。」
「期日に間に合わない…。」
「リリース後に不具合が発生してしまっている…。」
といった悩みを抱えている企業は多いでしょう。
監修
株式会社SHIFT
「ヒンシツ大学」クオリティ エヴァンジェリスト 永井 敏隆
大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。
担当講座
