ソフトウェアの開発において品質を担保する重要な役割を担う、テストのプロセス。これを運営するテストチームには、綿密なテスト計画を立ててその進捗を効率的に管理していくことが求められます。ここでは、テスト計画策定の基本とポイントについて、実践的な視野から学んでいきます。
まずはテストのレベル（スコープ）を定めよう
テスト計画は、チーム内にテストを行う目的と対応の関連づけを明確にするために策定されます。ひとつのテストでソフトウェアの全てを検証できません。テスト計画においては、最初にテストのレベル（スコープ）を明確に定めることが大切です。
■マスターテスト計画
マスターテスト計画は、個別レベルでのテスト計画を統合し、テスト作業全体を俯瞰するテスト計画であり、開発プロジェクト計画書の一部として記載される場合もあります。各個別レベルテストの抜け・漏れ・重複を削減し、よりスムーズにテスト作業を進める役割を担います。
■個別レベルでのテスト計画
納品されたソフトウェアを検収する受け入れテストや、実装した機能が意図どおりに動作するか検査する機能テスト。また、構成単位で実施される単体テスト、システム（統合）テスト、コンポーネントテストなど、行うテストのレベルが明確になることにより、テストの目的が規定され、それぞれのテストの役割と対応付けが明確になります。これにより、システムテストの場合は性能テストやセキュリティテストを行うなど、行うべきテストの系統づけも行えます。
テスト計画書に盛り込むべき要件は
テストレベルを規定することで、テストの手法や必要なリソースが明らかになります。これらの情報を系統的にまとめられたテスト計画書を作成することで、テスト関係者内にテストの概要が共有化されます。「Standard for Software Test Documentation (IEEE 829)」では、以下の要件をテスト計画書にリストアップすることを推奨しています。
- テスト計画識別番号／テスト計画書にナンバリングされる文章番号
- はじめに／テストの目的や戦略、実施方法の概略、参照文献、関連する標準 など
- テストアイテム／テストの対象となる個々の要素
＊ソフトウェアのバージョンやテスト環境（ハードウェア、メディア） など - テストすべき機能／ソフトウェアの機能の中で、テストすべき機能
- テストしない機能／テストが必要ない機能と、そう判断した理由
- アプローチ／テストの手順、テストレベル構成、担当者、手法、使用ツール など
- テストアイテムの合否判定基準
＊各テストアイテムの評価基準（テスト完了の判断基準）を明確にします - テストの中止・再開基準／対象テスト・各テストアイテムの中止・再開基準
- テスト成果物／テストで作成すべきドキュメント類
＊その際、テスト計画書もリストの中に含めてください - テストのタスク／テストで必要となる作業、テストフェーズ
＊準備作業や関連する作業、作業に求められる特殊な技能も記述します - 環境要件／ハードウェアやプロトコルなどのテスト環境
＊必要に応じてテスト対象設置場所も記述します - 責任範囲／テストの関係者と責任範囲
- 要員計画とトレーニング計画／テストに必要なスキルに基づく要員計画・教育計画
- スケジュール／テストの進捗の目安
- リスクと対策／想定されるリスクとその対策
- 承認／当該テスト計画の承認者名
実効性のあるテスト計画とは
実際のテスト作業が効率化されなければ、テスト計画を策定する意味はありません。テスト作業のスムーズな進捗を図るテスト計画を策定するためには、以下を留意して計画を策定し運用する必要があります。
■テストの実行を前提に計画を立案する
必ずしも「IEEE 829」と同じ要件を、テスト計画書に盛り込む必要はありません。たとえば、「IEEE 829」で「リスク」として定義される項目の中には、「テストの緊急性（優先順位）」、「テストにかかる制限／制約」が含まれていますし、JSTQBの定義では「テスト完了の判断基準」は「アプローチ」の1つとして位置づけられています。計画策定時には、実際にテストを行う場面を想定し、プロジェクトで行うテストフェーズ（プロジェクトで管理しやすいフェーズごとに必要なテスト作業をまとめたもの）に従って要件をリストアップすることが大切です。
■テスト計画全体への最適化を図る
テスト時にインシデントが発生したり、これから実施するテストに優先順位がある場合、それを速やかにスケジュールに反映していく必要があります。また、テストアイテムが複雑な設計であれば、それに対応できる要員が必要となります。テストの個別要件に問題がある場合は速やかにほかの要件との調整を図り、テスト活動全体での最適化を図ってください。
■テストチーム全員での共有も重要です
プロジェクト内の判断基準を明確にし、互いの意思疎通を図るために、テスト計画は存在します。テストを行うそれぞれの組織に「テストポリシー」があり、「テストの優先順位」もそれによって変わりますので、テストチーム全員が共有できるテスト計画が求められます。
まとめ
すべての計画は、必ず実行→評価→改善のPDCAサイクルをたどります。その意味において、テスト計画はテストの進捗とともに修正され、進化していくものと言えます。皆様のテストチームに最適化されたテスト計画の運用により、欠陥のない高品質なソフトウェアを実現してください。
■テストの管理に関するその他の解説記事
テストの管理Vol.1 〜テスト計画のレベルと内容を知る〜【本記事】テストの管理Vol.2 〜テストの見積もり〜
テストの管理Vol.3 〜テストの進捗管理〜
テストの管理Vol.4 〜テストの構成管理〜
テストの管理Vol.5 〜テストで考慮すべき２つのリスク〜
テストの管理Vol.6 〜インシデント管理〜
【参考文献】：
『ソフトウェアテスト教科書 JSTQB Foundation 第3版』
【参考URL】：
https://webrage.jp/techblog/planning_method_of_test/ ,（参照 2017年7月28日）
https://togetter.com/li/658180 ,（参照 2017年7月28日）
http://ceblog.mediba.jp/post/143053744037 ,（参照 2017年7月28日）
http://www.itmedia.co.jp/im/articles/0410/27/news110.html ,（参照 2017年7月28日）