テスト計画を作成する方法 (手順、サンプル、テンプレート)

DocumentTeam

2日前

Hannah Son著

ソフトウェア開発では、テスト計画とは、テストチームのテスト戦略、ゴール、範囲を定義するものであり、それらすべてが合わさって、究極的にはすべてのソフトウェアコンポーネントがリリースの前に適切にテストされていることを保証します。

次の６ステップに従うことで、効率的にテスト計画を作成できます。

リリース範囲を定義する
タイムラインをスケジュールする
テストの目標を定義する
テストの成果物を確定する
テスト戦略を定義する
テスト環境およびテストデータを計画する

テスト計画の作成方法

1.リリース範囲を定義する

何らかのテストアクティビティが発生する前に、リリースに向けたテスト範囲を定義することが重要です。つまり、リリースに影響を及ぼす可能性がある制約や依存関係を考慮し、リリースのタイプを確認したうで、リリースに含めるべき機能を定義します。

リリース範囲を定義する際に尋ねるべき質問には、次のようなものがあります。

このバージョンで新機能はリリースされるか?
リスク領域はどこか?
過去にリグレッションが発見された特に問題のある領域はあるか?
リリースのタイプは何か? バグ修正を含むメンテナンスリリースか? マイナーな機能リリースか? メジャーな機能リリースか?
チームにとって「完了」とは、実際にはどのような状態か?

たとえば、組織が新規 E-コマースサイトをローンチするにあたって、ローンチ前にテストを行う場合、どのような情報が必要になるでしょうか?

開発者と話をしてプロジェクトの範囲を理解するにせよ、製品マネージャーと協力して新機能およびユーザーフローをウォークスルーするにせよ、範囲を定義することによって正確な情報が共有され、プロジェクトのゴール、期待値、機能に関して共通の理解を確立できます。

2.タイムラインをスケジュールする

リリースの締め切りを設定すると、テストの時間と順序を決定するのに役立ちます。以下は、タイムラインを決定する際のヒントです。

プロジェクトマネージャーと相談し、現在のリリースタイムラインを把握します。
過去のリリースの時間とスケジュールを調べます。
外部的要因を考慮します。リリースはカンファレンスやイベントなどの外部的不確定要素と同時に行う必要があるでしょうか? それらをリリース日の予測に組み込みます。
開発のタイムフレームを考慮します。開発チームはすでに開発作業完了に向けたスケジュールを設定している可能性があります。テストスケジュールを調整できるよう、開発のタイムフレームを把握しておくようにします。
多少の変更の余地を含めます。予期しない遅延に遭遇することはよくあります。予期しないイベントに対応するための余分な時間を含めておくと、計画を遵守するのに役立ちます。
頻繁にスケジュールを見直し、更新して、テストのタイムテーブルが達成可能であるようにします。

3.テストの目標を定義する

テストの目標とは、テストを設計し実行する目的です。目標があることは、最終的にテストアクティビティの範囲を導き出し、定義するのに役立ちます。

全般的なテストの目標には以下のようなものがあります。

欠陥を特定し、レポートする
新機能をテストする
一定レベルのテストカバレッジ

特定のタイプのテストの目標には以下のようなものがあります。

機能テストの目標: ソフトウェアが期待どおり動作することを確認する。この目標のために達成するべき事項には次のようなものがあります: ユーザーワークフロー、データ処理の確認、入力/出力パラメーターの検証
パフォーマンステストの目標: ソフトウェアが効率的であり、さまざまな負荷を処理できることを確認する。この目標のために達成するべき事項には次のようなものがあります: ソフトウェアの反応時間、スループット、スケーラビリティを検証する
セキュリティテストの目標: プログラムのセキュリティ欠陥を明らかにする。この目標のために達成するべき事項には次のようなものがあります: 認証および認可機能を検証し、潜在的脅威を識別する
ユーザビリティテストの目標: 使いやすさとユーザーエクスペリエンスに集中する。この目標のために達成するべき事項には次のようなものがあります: ソフトウェアのアクセシビリティを確認し、ユーザーフローを検証し、ユーザー関連の問題を検出する

適切なメトリクスでテストを測定する

メトリクスはリリースの全体的な品質、特定のテストサイクルまたはテスト全体におけるテストの進捗と有効性を評価します。

メトリクスはテストプロセスおよび全体的な製品の品質に可視性をもたらし、最終的にリリース準備ができているかを判断するのに役立ちます。考慮すべきメトリクスの計算式には以下のようなものがあります。

欠陥密度

欠陥密度 = 欠陥数/リリースの大きさ(コード行数)

例: ソフトウェアに150個の欠陥と15,000行のコードがある場合、欠陥密度は1コード行当たり0.01です。

テストカバレッジ

テストカバレッジ = (テストケースにマップされた要件の総数/要件の総数) x 100

欠陥検出効率(DDE)

DDE = フェーズで検出された欠陥のパーセンテージ / 欠陥の総数

Time to Market

TTM = アイデアからローンチまでにかかる時間

4.テストの成果物を確定する

テストの成果物とは、テストの進捗を追跡するのに役立つテストの産物です。成果物は、プロジェクトおよびクライアントのニーズを満たす必要があります。テスト計画に含めることができるよう、早期に成果物を特定し、適宜スケジュールするべきです。ソフトウェア開発ライフサイクルの各フェーズにそれぞれ異なる成果物があります。テスト前、テスト中、テスト後に重視するべき重要な成果物には、以下があります。

テスト前

テスト計画文書: テスト作業の範囲、目標、アプローチはすべてテスト計画に概要を記述します。
テストスイート: テストケースは、入力データ、期待される結果、成功/失敗の条件など、テストをどのように実行するかを説明します。
テスト設計および環境仕様: テスト環境は、テストに使用するハードウェアおよびソフトウェア構成の概略を示します。

テスト中

テストログ: テストログは、問題および解決方法も含めた各テストケースの結果を記録します。
欠陥レポート: 欠陥レポートは、深刻度、優先度、再現性ごとにテストの課題をリストしたレポートです。
テストデータ: International Software Testing Qualifications Board (ISTQB)の定義では、テストデータとは、実行の事前条件を満たすために作成または選択されたデータおよび1つまたはそれ以上のテストケースの実行に必要な入力コンテンツです。
テストサマリーレポート: テストサマリーレポートは、実行されたテスト数、成功したテスト数、失敗したテスト数、およびオープンな欠陥数をリストします。

テスト後

テスト完了レポート: テスト範囲、製品の品質、発見された教訓をカバーします。
ユーザー受け入れテスト(UAT)レポート: 発見および修正された問題があれば指摘します。
リリースノート: リリースに含まれるものについての情報をリストします。たとえば、新機能、改善、修正などがあります。

テスト計画の内容および構成は、コンテキストによって異なります。テスト計画の作成には画一的な方法はありませんが、テスト計画作成のベストプラクティスに従うと、品質の高いソフトウェアのデリバリーに役立ちます。

TestRailは、テスト計画作成のベストプラクティスに容易に従うことができるよう設計されたテスト計画ソフトウェアです。TestRailでは、事前条件、テスト手順、実行結果、優先度、作業見積りとともにテストケースを入力できます。

画像: TestRailでは、再利用可能なテストケースをフォルダーで整理して構造化したり、アジャイルテスト計画を作成したり、テスト実行の進捗を追跡したりできます。

このようなレベルの柔軟性と可視性をテストプロセスにもたらすことによって、TestRailはどのような組織のテスト計画にも容易に組み込むことができます。テスト計画にどのように役立つか、TestRailの無償評価版でご確認ください。

5.テスト戦略を定義する

テスト戦略はテストのコスト、テスト作業、テスト範囲の(テスト対象として計画される)機能とテスト範囲外の(テスト対象として計画されない)機能を判断するのに役立ちます。

テストタイプの特定

どんなタイプのテストをいつ実行するか、何を手動でテストして何を自動でテストするか、自動テストの範囲、新規テストケースの作成にどの程度の作業が必要か、誰がその作業を行うかを特定することは重要です。

いくつかの要因に基づいて、テスト計画に含めるべきテストのタイプにはさまざまなものがあります。

実行するテストのタイプを選択する際に考慮するべき要因には、以下のようなものがあります。

テストの目標
プロジェクトの機能要件
製品の複雑度
チームの経験レベル
法的要件
時間および予算

テスト計画に含めることを検討するべき一般的に行われるテストのタイプには、以下があります。

手動テスト	自動テスト	その他
•スモークテスト •探索的テスト •新機能のユーザビリティテスト	•単体テスト •既存の機能の回帰テスト •統合テスト	•パフォーマンステスト •セキュリティテスト •アクセシビリティテスト

リスクおよび課題を文書化する

テスト中に発生する可能性があるリスクおよびリスクの影響を文書化することが重要です。リスクには以下のようなものがあります。

厳しい締め切り
不十分または不正確な予算の見積り
管理不足
コードの問題
ビジネス環境の変化
テストのためのリソースが限られている
テスト中の予期しない遅延

テストロジスティクスを文書化する

テストロジスティクスは、「誰が、何を、どこへ、いつ、どのように」という質問に答えられなければなりません。テストロジスティクスを文書化すると、すべての人的およびシステム関連のテストリソースが利用可能であることを保証できます。たとえば、誰がテストを実行でき、テスト中に必要になった場合に誰がサポートするかを特定することが重要な場合があります。さらに、リソースの計画を立てる際、代替リソースを指定したり、テスト計画に余裕を見込んだりすることが、プロジェクトを確実に完了するために役に立つ可能性があります。

テスト条件を確立する

テスト条件は、テストプロジェクト内のすべてのアクティビティを統制する基準です。テスト条件の主要な2つのタイプは、保留条件と終了条件です。

保留条件: すべてのテストを保留する条件を確立します。
終了条件: 終了条件は、テストフェーズを終了とするために完了する必要がある特定の項目または目標です。テストの終了条件は、次のテストフェーズに移行するために達成する必要がある、あらかじめ決められた結果です。たとえば、顧客に機能をリリースできる状態だとみなすには、すべての重要なテストケースの92%が成功する必要があるといったものです。

6.テスト環境およびテストデータを計画する

テスト環境を計画すると、正確で安定したテストを保証できます。テスト環境には、ソフトウェアテストのためのハードウェア、ソフトウェア、ネットワーク構成が含まれます。次の手順に従って、テスト環境をセットアップします。

ハードウェアおよびプログラム要件を確定します。OS、ブラウザー、データベース、テストツールなどのテスト環境のデバイスおよびソフトウェアを選択します。
必要なソフトウェアをインストールします。事前条件が確立されたら、必要なツールをテスト環境にインストールします。これには、アプリケーションをホストするために個別のサーバーをセットアップしたり、データベース管理システムやその他のツールをインストールしたりといった作業が必要になる場合があります。
ネットワークを構成します。ネットワーク構成の中でも、ファイアウォールプロトコル、IPアドレス、DNS設定がテスト環境と運用環境で同一であることを確認します。
テストデータを作成します。アプリケーションのテストに必要なテスト材料を準備します。テストデータは、運用環境のデータから手動で作成することも、既存の運用環境およびデータベースから取得することも、自動のデータ生成ツールで作成することもできます。
ビルドにアクセスします。テスターがテスト対象のビルドにアクセスできることを確認します。たとえば、ファイル共有やバージョン管理システムをセットアップして、テスターが最新のビルドにアクセスできるようにします。
テスト環境を検証します。テスト環境をセットアップしたら、環境が要件を満たしていることを確認します。

1ページのテスト計画テンプレート

テスト計画 タイトル
作成者: John Doe

1.はじめに
　•エグゼクティブサマリー (簡潔に)

2.テストリソース
　•テスター名と役割

3.テストの範囲
　•範囲内: テスト対象モジュール
　•範囲外: テスト対象ではないモジュール

4.テストアプローチ
　•テストアプローチおよび手法
　•実施するテストのタイプ (例: 機能テスト、パフォーマンステスト、セキュリティテスト、ユーザビリティテストなど)

5.テストスケジュール
　•各テストフェーズのタイムライン

6.リスクおよび問題
　•テストプロセスに関するリスク
　•特定されたリスクの軽減策

テスト計画が１ページに収まらなくても、心配はいりません。肝心なのは、不要な情報を最小限にし、ステークホルダーおよびテスターが計画を実行するために不可欠な情報を捕捉することです。

テスト管理ツールでのテスト計画

テスト管理ツールは、テスト計画作業にも役立ちます。目標がよりアジャイルになることであっても、テスト計画を加速することであっても、TestRailのようなテスト管理ツールで包括的でアジャイルなテスト計画を作成するには、効果的なアプローチがあります。

マイルストーン

TestRailでは、マイルストーンとは、テスト成果物を集約し、同一の成果物に関連するさまざまなテストアクティビティを追跡するコンテナーです。たとえば、TestRailでマイルストーンを作成してリリースを追跡し、関連するすべてのテストランおよびテスト計画を接続すると、該当リリースで行うさまざまなアクティビティをすべて1箇所で参照できます。

**画像:** マイルストーンおよび進行中のテストプロジェクトをすべてTestRailで管理します。

TestRailのマイルストーンには説明フィールドがあり、1ページのテスト計画を記載するのに最適の場所です。開始時からテスト計画情報をすべてマイルストーンに関連付けると、計画時に定期的に見直して、「何がテスト範囲に入るか」「何がテスト範囲に入らないか」「何をテストして何をテストしないか」「このマイルストーンでは自動テストを実行するか」といった質問に答えを出すのに役立ちます。

マイルストーンは、実際のテスト管理ツール内でテスト計画情報をすばやく見直す効率的な方法を提供します。

テストケースの優先度およびタイプ

テストケースは、何をテストするかをあらかじめ定義します。本質として、テストケースは何を実行するかの概略を実行前に記述するものです。TestRailでは、多数の階層に基づいてテストケースを整理できます。これは、テスト計画の構築を開始する際のキーとなる方法です。

たとえば、高機能なメッセージングアプリを開発している場合、アプリの最もリスクの高い領域は、アプリをインストールして実行できなければならないという点です。この例では、この領域のスモークテストからテストを開始し、より詳細な機能テストや探索的テストを行うとよいでしょう。

テストケースの優先度や特定のテストケースで採用する予定のテストアプローチをあらかじめ把握することは、事実上、テストケースの計画を始めることです。

テストレポート

TestRailなどのテスト管理ツールを使用してテストを実行すると、リアルタイムのレポートを利用できるため有用です。たとえば、TestRailで計画を作成し、テスト計画に沿って実行している場合、TestRailのマイルストーンサマリーレポートなどのレポートは、当初のテスト目標、当初の1ページのテスト計画、マイルストーンに追加されたすべてのテストランおよび計画、割り当てられた優先度などを表示します。レポートをダウンロードしてチームや他のステークホルダーと共有することもできます。

**画像:** マイルストーン(サマリー)レポートを使用すると、プロジェクト条件を付加し、マイルストーンのアクティビティをわかりやすく共有可能な形で解釈して視覚化することができます。

プロジェクトが複雑になるにつれて、スプレッドシートをテスト計画テンプレートとして使用するのは煩雑になり、より洗練されたアプローチが必要になります。TestRailなどのテスト管理ツールを使用して、テスト計画を最大限に柔軟にしましょう。

（この記事は、開発元Gurock社の Blog 「How To Create A Test Plan (Steps, Examples, & Template)」2023年8月21日の翻訳記事です。）