.svg)
ソフトウェアテストでは、システムを運用する上で必要な要件を全て満たしていることを確認することができます。そのため、アプリケーションの目標に沿った適切なテスト計画は、潜在的な問題を見つけ出すために非常に重要です。
本ブログでは、効果的なテスト計画を作成し、ソフトウェアテストを成功させるための方法を解説していきます。
テスト計画書とは、ソフトウェアの検証方法、利用可能なリソース、スケジュールを示すドキュメントのことです。
例えば、実行するテストの種類と量、各テストの目的、場合によっては使用ツール、テスト結果分析後の結果の保存先などを記載し、テスト中には、気付きや新たな戦略を反映するために頻繁に更新されます。
似たような言葉にテスト仕様書がありますが、こちらはよりテストの具体的な手順を示したドキュメントになります。
テスト計画があることで、テストの対象や理由、実行方法を全員が把握することができます。言わば、テスト計画書は関係者とテストチームメンバー間のコミュニケーションツールです。
また、テスト結果の報告方法、合格／不合格の基準、その他の関連する基準も詳細に記述されていたり、予想される結果を明示してテストが想定通りに行われるようにするなど、テスト計画は様々な側面から重要とされています。
テスト計画は、テストの実行方法を保証するソフトウェア開発とテストの基本コンポーネントです。テスト計画書には、以下のような、テスト戦略、範囲、目的、テスト対象のリソース、テストプロセスのスケジュールといった詳細を記述します。
・テストの目標
テストの明確な目的範囲を設定し、テストされる機能や仕様の一覧とそれらの要件を記載します。
・範囲とアプローチ
テスト対象、使用する手法やアプローチ、テストの実施方法の詳細を決めます。
・テスト環境
テストの実行に必要なハードウェア、ソフトウェア、ネットワーク構成、追加で必要があればサードパーティのツールで構成します。
・詳細とリソース
テストケース、スクリプト、レポートなどの成果物や、テストのタイムラインを概説したスケジュールなど、何をいつ行うかや必要なリソースを記載します。
・人員と設備
テストを完了するために必要な人員、設備、施設を洗い出します。
・潜在的な問題
テスト中に発生する可能性のある潜在的な問題と、その対処方法も検討しておきます。
・承認
すべてのステークホルダーとプロジェクトチームメンバーがテスト目標を理解し、計画の明確な承認プロセスも定めておく必要があります。
【 テスト計画の種類 】
テスト計画には主に3つの種類があります。
1 . マスターテスト計画
プロジェクト内のすべてのテスト作業の包括的な指針となる、複数のテストレベルを含むテスト戦略です。
例）単体テスト、統合テスト、システムテスト、ユーザー受け入れテスト（UAT）を計画し、最小のコード単位からシステム全体に至るまで、プラットフォームが正しく機能することを確認する
2 . フェーズテスト計画
全体的なテスト戦略の中で、特定のテストフェーズの目的や範囲に焦点を当てます。
例）統合テストのみに焦点を当て、システムテストに進む前に、様々なモジュールとサービスが相互に正しく相互作用することを確認する
3 . 特定のテスト計画
ソフトウェアの非機能的側面に焦点を当て、パフォーマンステスト、セキュリティテスト、負荷テストなど、特定のテストに向けて設計します。
例）多数の同時ユーザーの処理や大量のトランザクションの処理など、様々な負荷条件下でシステムの応答性と安定性をテストする
【 テスト計画の量 】
テスト計画は、詳細をたくさん記載して作成すればいいという訳ではありません。大規模で複雑なアプリケーションは、多くのテストを必要とするため、必然的に文章量が増えます。しかし、膨大な量のテスト計画書を読みたい！という人はなかなか居ないでしょう。多くの人は内容を飛ばして読んだり、もしくは読むのが億劫になって、ほとんど読まない可能性も出てきてしまいます。
テスト計画書の内容を取りこぼすことなく読んでもらうためには、読み手の立場に立った文章の作成が必要です。
読み手を無視したテスト計画書では、テストに何が求められているか把握できず、場合によっては、ドキュメントを全て読まない可能性も出てきます。例えば、技術者がテスト計画書を読む場合、ビジネス要素の強い話では深く理解できない可能性がある上に、技術的な記述が少ないため計画不足と受け取る可能性があります。
テスト計画は、役割関係なくすべての関係者が理解できる必要があるため、読み手のことも考えて適切な文章に調整することが大切です。ソフトウェアテストにおけるテスト計画の特徴は以下のとおりです。
・簡潔さ
短文で箇条書きにすることで、読みやすい文章を意識します。
・整理された構成
テスト計画書のテンプレート、番号付セクション、サブトピックなどを活用し、簡単な計画から、徐々に詳細へと掘り下げていくことで、理解しやすく、簡単に参照できるようにします。
・読みやすさ
読みやすさを高めるために、頭字語や複雑な用語の使用は避け、誰でも簡単に理解できる言葉を使用します。
・変化への適応性
将来、ビジネス要件が変更された場合に発生する可能性のある変更を予測します。
・正確性
特定されたエラーは速やかに報告し、修正します。
テスト計画の主な目的は、テストの詳細を関係者全員に効果的に伝えることです。そのため、より多く人に理解してもらうために、テスト計画書は明確かつシンプルに書くことが大切なポイントです。
まずは、テストするソフトウェア、その目的、ユーザー側の要件を洗い出します。それを基に、テスト戦略、目的、基準、リソース、テスト環境、スケジュールを決定します。
【 ステップ1：製品の分析 】
開発する製品が何を行うものなのか、どのように機能するのか、ユーザーが何を期待するのかなど、徹底的に理解することから始めます。この分析で潜在的な問題箇所を認識することで、的を絞ったテスト計画／最も効果的なテストの種類を決定をすることができます。
【 ステップ2：テスト戦略を策定 】
テストの種類、必要なリソース、テストのスケジュールなど様々な要素を考慮して、テスト戦略の1つを設計します。
・テスト範囲の定義
テストの目的を明確にし、製品の説明と要件定義書に基づいて、アプリケーションのどの範囲（機能領域、特徴、コンポーネントなど）をテストするのかを定義します。
・テストの種類の特定
一般的なテストの種類は以下のとおりです。
- 機能テスト
指定されたすべての要件がソフトウェアでカバーされていることを確認するテストで、手動もしくは自動化ツールを使用して行われます。
- パフォーマンステスト
ソフトウェアの速度と安定性を評価するテストです。
- セキュリティテスト
脅威に対するソフトウェアの脆弱性を評価します。
- 互換性テスト
様々な環境におけるソフトウェアのパフォーマンスをテストします。
- ユーザビリティテスト
このテストでは、ソフトウェアの使いやすさを評価します。
使用されるテストの種類は、ソフトウェアの目的や対象ユーザーによって決まりますが、リリース前に基本的な機能テストとパフォーマンステストを受けるのが一般的です。
▼ 関連記事 ▼
【 ステップ3：テスト目的の定義 】
ソフトウェアの目的に基づいたテスト目標を設定します。この目的には、ソフトウェアがユーザーの要件を満たしているかの確認、不具合の発見、完全性の評価などがあり、この目標によって、実行するテストの種類や結果分析と報告方法の指針が決まります。
【 ステップ4：テスト基準の定義 】
テストの目的を定義した後、テストの合否を判断する基準となるテスト基準を決定します。これらの基準はテストの種類に応じたもので、誤解を防ぐために明確に定義する必要があります。
例えば、データの精度をテストする際、特定の精度の割合を基準として設定するとします。しかし、テストと開発時のデータソースの違いなど、環境の変化によって変動が生じる可能性があることに注意が必要です。
・一時停止基準
テストを一時停止／再開する条件を定めた基準です。例えば、重大なバグの発見や、範囲の変更、その他の重大な問題が発生した場合など一貫した意思決定ができるよう、すべての関係者の同意を得て、最初から明確に定義しておく必要があります。
・終了基準
終了基準は、システムの機能性に関連する機能基準と、パフォーマンス、スケーラビリティ、セキュリティなどの非機能基準に分けられ、テスト完了と判断するために満たすべき条件を示します。
【 ステップ5：リソース計画 】
テストに必要なスキルや適正を判断し、リソースを計画します。場合によっては社外リソースを検討し、中断を回避するための安全要件も含める必要があります。
・人的リソース
テスター、開発者、その他スタッフなど、プロジェクトの規模や複雑さによって必要なリソースやスキルを踏まえて決定します。また、タスクを割り当てるときは、チームメンバーのスキルと経験を考慮し、進捗状況を追跡してリソースのギャップに対処するための計画も立てます。
・システムリソース
ハードウェアやソフトウェアなど、テストに必要なシステムリソースを検討します。また、テストに関連する可能性のある様々なリスクを洗い出し、これらのリスクを軽減するために何を行うかも記載します。
【 ステップ6：テスト環境の計画 】
実行するテストの種類（機能テスト、ユーザビリティテスト、負荷テスト）に基づいて、テスト環境のすべての要件を定義します。テスト環境は、実際のデータ、ネットワーク接続、その他の関連要素の使用など、可能な限り実環境に近づける必要があり、次の重要な要素を考慮する必要があります。
・ハードウェアとソフトウェアの要件
・テストツール
・テストデータ
・ネットワーク構成
【 ステップ7：スケジュールと見積もり 】
テストスケジュールの概要と、テストプロセスに必要な時間を見積もります。その後、テストスケジュールを作成し、テストコストを見積もり、これらのコストをどのように決定し、管理するかについて詳細な計画も合わせて共有します。
【 ステップ8：テスト成果物 】
最後に、テストレポート、不具合ログ、改善要求といったテスト成果物を作成します。テスト成果物はソフトウェア成果物とは異なり、テストに関連する情報にのみ焦点を当てる必要があります。
・概要
テスト対象製品の概要で、全体の機能を大まかに説明します。
・目標
マスターテストプランに沿ったテストの目標を定義します。
・タスク
テスト、事後テスト、問題報告など、テスト計画に記載されているすべてのタスクをリストします。
・範囲
テストの範囲を説明します。
・テスト戦略
全体的なテストアプローチについて説明し、使用するテストアプローチ、ツール、主要なテスト活動を記載します。
・問題の報告
テスト中に問題が発生した場合の手順をドキュメント化します。
・変更要求
ソフトウェアモジュールの変更が必要な場合は、それをドキュメント化し、関係チームとフィードバックを共有します。
・テストする機能
テストする機能と仕様を洗い出します。
・テストしない機能
テストしない機能についてはその理由を明記します。
・リソース／役割と責任
テストに関わる全員の、チームにおける役割や責任を明確にします。
・スケジュール
テスト計画書、テストケース、テストインシデントレポート、テストサマリーレポートなどの成果物リストを作成します。
・重大な影響を受ける部門 （SID）
影響を受ける部署、テスター、ビジネスの範囲、ビジネスの関係者を洗い出します。
・依存関係
アイテムやリソースの可用性や期限など、テストに大きく影響する制約を確認します。
・リスクの仮説
リスクの高い事項の仮説を立て、緊急時対応計画を明記します。
・ツール
テスト自動化ツールとバグ追跡ツールをリスト化します。
テスト計画書そのものは、テストプロセスの基礎を定めるために必要なドキュメントですが、包括的なテスト計画書を作成するためには、他にも以下のような資料を作成する必要があります。
・要件仕様書
テスト対象のソフトウェアやシステムのすべての機能要件と非機能要件を明記したドキュメントです。これがテスト目標の土台となり、テストケースの設計方法を定義します。
・設計ドキュメント
システムアーキテクチャ図、ソフトウェア設計仕様、インターフェイス仕様など、ソフトウェアの内部構造に関する理解を深め、テスト領域を特定するのに役立ちます。
・ユースケース／ユーザーストーリー
一般的なユーザーインタラクションとシナリオをまとめたもので、システムで期待される動作を明確にし、テストシナリオを定義するのに役立ちます。
・テスト戦略
テストレベル、手法、環境設定など、全体的なテストアプローチの概要を示します。
・テスト見積りドキュメント
効果的な計画とリソース配分のため、テスト活動に必要な工数、リソース、スケジュールの概算をまとめたドキュメントです。
・テストケース仕様書
入力値、期待される結果、前提条件など、個々のテストケースの詳細がまとめられ、テスト実行のガイドとなります。
・不具合管理プロセス
テスト中に発見された不具合を報告、追跡、解決するための手順についてまとめてあります。
テスト計画変更の適切な管理は、プロジェクトを滞りなく進めるために重要です。以下で、変更を効率的に処理する手順を紹介します。
【 変更の原因を特定する 】
変更の原因が新しい要件、不具合、その他の要因によるものかを理解することで、即座に対応が必要か否かを判断できます。
【 変更の影響を評価する 】
追加作業の量、テストスケジュールへの影響、リソースの調整が必要かどうかなど、変更が現在のテスト計画にどのような影響を与えるかを評価します。
【 実施計画を立てる 】
変更を反映するため、以下のような内容を決定します。
・責任の割り当て
・変更の計画
・関係者への変更の共有
テスト計画の作成は、ソフトウェアの高い品質と信頼性を保証するために必要不可欠なプロセスです。製品分析、戦略策定、目的と基準の定義、リソースと環境の計画を経て、効果的なテストのための基盤を築くことができます。
テスト計画を行う際は、テスト計画はテストプロセスをガイドするツールであるだけでなく、起こり得るリスクをコントロールし、プロジェクトを目標達成に導く手段であることを念頭に置いておきましょう。
テストプロセスの改善、ソフトウェアの品質向上、ユーザーの期待とビジネス要件を満たす製品の提供のため、ここまで上げてきた方法を組み合わせることで、より円滑なテストの実施を後押しします。
