ソフトウェア開発において、「テスト計画なんて作らなくても何とかなる」と捉えてはいないでしょうか？
小規模な改修案件では、確かにテスト計画がなくても問題にならないことがあります。しかし、大規模なシステム開発やマルチベンダーでの開発では、十分なテスト計画がない状態でテストを進めると、以下のような問題を引き起こす可能性があります。
・テストが網羅的でなく、不具合が多く残った状態でリリース
・スケジュールの見積もりが甘く、テスト開始時に多くの時間ロスが発生
・進捗管理の指標が把握できずに、テストケースの消化が遅延してしまう
この記事では、こういった事態を防ぐために、テスト計画の基本から作成手順、注意点までを初心者向けにわかりやすく解説します。
テスト計画はなぜ重要？ 目的とメリット
1.テスト計画とは
一言で表すと、テスト計画は、テストにおける5W1H（誰が、いつ、どんな目的で、どのようなテストを実施するか）を詳細に洗い出していく作業です。
具体的には、実施するテストの目的や対象、手法、スケジュール、責任者、必要なリソースなどを定義します。定義した内容はテスト計画書としてドキュメント化し、プロジェクト関係者が参照します。
なお、ソフトウェアテストの国際規格「ISO/IEC/IEEE 29119」では、ドキュメントに含める項目として、以下が挙げられています。
| 項目 | 内容 |
| テスト方針 | テストの目的、背景、対象、除外範囲を定義 |
| テスト基準 | テストレベルとタイプ、手法など |
| 関係者 | ステークホルダーの一覧、役割責任など |
| スケジュール | 工程を並べ、期間を設定。マイルストーンを提示する |
| テスト環境 | システムやテストデータ、作業場所の確保手段、使用ツールなど |
| 管理基準 | 管理項目、開始終了基準、一時停止条件、成果物を定義 |
| リスクと対策 | リスクを抽出し影響評価と対策を練る |
2.テスト計画のメリット
テスト計画を策定する目的は、プロジェクトの品質を確保し、効率的なテスト実施を実現することです。
具体的には以下のメリットがあります。
メリット①テスト漏れや重複を防止できる
それぞれのテストレベルでどのようなテストをするのかを決めておかないと、人によって認識が違うためにテスト漏れやテスト重複につながります。
計画段階でプロダクト/プロジェクト特性に応じた必要十分なテスト範囲と観点を洗い出すことで、実施すべきテストが抜け落ちたり、逆に不要なテストに工数を割いてしまうリスクを低減できます。
メリット②不具合を早期発見・是正しコスト削減につながる
テスト計画を入念に練ることで、テスト工程を計画的に進め、可能な限り上流で欠陥を摘み取り、後工程での手戻りコストを減らします。
実際、仕様書の不備に起因するバグのテスト工程以降における修正コストは、上流工程で修正を行うコストと比べ20倍～200倍にも及ぶと言われています。
テスト計画の種類・作成する文書
1.『全体テスト計画』と『個別テスト計画』の違い
テスト計画は、プロジェクトの規模や目的に応じて以下のように分類されます。
全体テスト計画
全体テスト計画では、そのプロジェクトにおけるテストの計画を策定します。テストのスコープや品質目標を定義します。最終的な品質に向けて、それぞれのテストレベルでどのくらいの工数でどのようなテストをして、何をもって完了とするかを明確にします。
具体的には以下の項目を定めます。
・プロジェクト全体のテスト戦略を定義
・テストの目的と範囲
・全体スケジュール
・リソース配分
個別テスト計画
個別テスト計画は、各テストレベル単位の計画を策定するプロセスです。全体テスト計画の時点より開発量が明確になり、前工程までの品質が見えるため、スケジュールやテストケース数・工数の精度が上がっていきます。
個別テスト計画ではさらに、特定のテストフェーズ（例：単体テスト、結合テスト）に特化した詳細な実施計画を記載します。特に前工程までで品質に不安要素がある時は、個別テスト計画でフォローアップの方針を検討します。
両者ともテスト計画で明確化する内容は似通っていますが、全体テスト計画はテストの方針決めにより重きをおき、個別テスト計画はテストの実施により重きをおくといえるでしょう。
2.テスト計画書とテスト仕様書の違い
テスト計画に関連する文書として、「テスト計画書」と「テスト仕様書」がありますが、それぞれの役割は異なります。
①テスト計画書
テスト全体の方針・体制・スケジュールなどマネジメント寄りの事項を記載。テストの目的や戦略、必要なリソース、リスク管理など、プロジェクト全体のテスト活動を俯瞰した内容をまとめたものです。
②テスト仕様書
個々のテストケースや手順などテスト実行に関する詳細をまとめたもの。具体的なテスト項目、期待される結果、テストデータなど、実際のテスト実施に必要な詳細情報を記載します。
プロジェクトではまずテスト計画書で「何をどのようにテストするか」「必要な人員・期間はどれくらいか」といった骨子を定め、その指針に沿って具体的なテストケース一覧や実施手順を書くテスト仕様書（＝テストケース集）を作成する流れになります。
テスト計画の作成手順３ステップ
テスト計画の策定は以下のステップで進めます。
1. テストの要求を整理する
まずは、何をテストするのか（機能、非機能）を明確にします。
主な確認事項は以下のとおりです。
・テスト対象・範囲は何か
・テストの目的、重点項目は何か
・テスト対象の開発状況はどうか
・どんな課題やリスクがあるか
なぜそれが要求されているのか、理由や背景も言語化しておきましょう。未決事項・課題・リスクの抽出に役立ちます。
2. テストの実行計画を策定する
要求と状況を整理した上で、課題とリスクを踏まえながら、実行計画を策定します。
ここで考慮する要素は下記の通りです。
①テストの種類と順序
単体テスト→結合テスト→システムテストなど、段階的な品質の積み上げを計画します。
②テスト環境
必要なハードウェア、ソフトウェア、ツールを明確にします。
③スケジュール
各フェーズの開始・終了時期を設定します。
ここで注意すべき点は「実施するテスト」を計画するだけでなく、「実施しないテスト」も計画することです。なぜそれをテストしないのか、理由も一緒に明らかにします。
3. 管理項目と成果物を定義する
テストを下支えする各種マネジメントの準備を定義します。
管理項目：進捗管理、不具合管理、リスク管理の方法を決定します。
成果物：テスト計画書、テストケース、テスト結果報告書など、必要な成果物を明確にします。
テスト計画書の記入項目
テスト計画書には以下の項目を含めることをおすすめします。
| 1. プロジェクト概要 | プロジェクト名、目的、背景を記載し、関係者がプロジェクトの全体像を理解できるようにします。 |
| 2. テストの目的と範囲 | テストに求められているもの、開発の状況を整理し、更に、未決事項・課題・リスクの整理を行います。テスト対象、品質基準を定義します。 |
| 3. テストの種類と方法 | 単体テスト、結合テスト、非機能テスト（性能、セキュリティなど）の実施方法を記載します。 |
| 4. テスト環境 | ライセンスの取得、ID登録の数やタイミング、機材、ツール・環境のセットアップ、初期動作確認、テストデータの調達・作成 これらの準備は、意外に時間も労力もかかります。 |
| 5. スケジュールと体制 | 「When」では、テストレベルのスケジュールを策定します。テスト設計・テスト実行がまず思いつくかもしれませんが、あわせてテスト準備もスケジュール上に加えることが極めて重要です。 |
| 6. リスクと対策 | 想定リスクとその対応策を事前に記載しておきます。 |
| 7. 成果物 | テストケース、結果報告書など、各フェーズで作成する成果物を定義します。 |
テスト計画作成時のチェックポイント5選
テスト計画を作成する際は、以下の5つのポイントに注意してください。
ポイント1. 想定されるリスクとその対応策を事前に示しておくこと
開発途中で計画通りに進まないことはよくあります。例えば、ドキュメントやプログラムの品質が悪いことやスケジュールが押してテスト開始準備が遅れることなどが要因としてあげられます。
このようなリスクのなかには、あらかじめ想定できるものも多いです。リスクとして考えられることについては、テスト計画の段階から対策案を考え、ステークホルダーと合意しておくことが肝要です。
ポイント2. テスト計画は変更がありうるものだと認識すること
開発の状況により、思いもよらぬ変更や追加開発が発生することもよくあることです。テスト計画ではテストの対象や方法について定めており、変更にあわせて修正することが肝要です。修正を怠ればテスト漏れなどの問題を引き起こす原因になりかねません。
変更が起こる可能性が高いからといって、テスト計画を作成しないのは適切ではありません。変化に柔軟に対応できる計画を作成することで、プロジェクトをスムーズに進めることができるでしょう。
ポイント3. ステークホルダーを巻き込んでレビューすること
テスト計画のレビューを行うと、特に個別テスト計画のテスト方針の立案における要件漏れや検討抜けがレビューの対話を通して明らかになることも少なくありません。
例として、レビューは２回行うことをお勧めします。１回目は開発との認識合わせ、２回目はテスト計画自体の検討という意識をもって行うとよいでしょう。レビューを通して、誤字脱字、記載漏れ、曖昧な表現、矛盾点などをチェックし、修正することで、より質の高いテスト計画を作成することができます。
ポイント4. 品質特性を活用して役割分担を明確にすること
大規模システム開発では、単体テスト・結合テスト・総合テスト・受入テストと段階を踏んで品質を積み上げていく必要があります。「ISO/IEC25010ソフトウェアの品質モデル」に定義されている「品質特性」を利用することで、各工程の役割を整理できます。
たとえば、以下のように各テスト工程で重点を置く品質特性を決めていきます。
・単体テストでは、設計書通りに正確に動作する「機能正確性」
・結合テストでは、モジュールを結合させて機能の集合を確認する「機能完全性」
・総合テストや受入テストでは、システムの目的が達成されるかを確認する「機能適切性」
ポイント5. 読者を念頭に置いて分かりやすく作成すること
テスト計画は、プロジェクトの関係者全員が参照する重要なドキュメントです。そのため、誰にでも理解できるように作成することが重要です。
略語を避け、平易な言葉で記述しましょう。技術的な情報を、ビジネス側にも理解できる形で表現する配慮が求められます。
まとめ
テスト計画は、場合によってはやる必要のない工程と思われることもあります。しかし、実際はそうではなく、抜けや漏れをなくすためには重要な作業です。テスト計画は、ウォーターフォール型開発、アジャイル開発、DevOpsなど、どのような開発手法を採用していても不可欠です。
テスト計画の策定は、そのまま完成するシステムの完成度に直結すると考え、しっかりとテスト計画を練りましょう。
STELAQのソフトウェア開発支援サービスでプロジェクトを成功に導きます
STELAQでは、自動車、金融、医療、IoTなど多様な産業での豊富な開発実績を基盤に、貴社のソフトウェア開発プロジェクトを成功へと導きます。体制構築や要件定義含む上流工程のコンサルティングから、開発及びソフトウェアテストまで一気通貫の支援で、プロジェクト全体の課題解決をサポートします。
- 多様な産業・ドメインでの豊富な開発実績
- 上流工程から開発・検証・教育まで一気通貫の支援体制
- 個社に合わせた柔軟なサポートと早期戦力化
ソフトウェア開発プロジェクトの推進、品質向上、人材育成に課題をお持ちでしたら、ぜひ一度STELAQにご相談ください。貴社の状況に合わせた最適な支援プランをご提案し、プロジェクト成功を全力でサポートいたします。
お問い合わせ