次の方法で共有

テスト計画およびテスト スイートの作成に関するガイダンス

  • [アーティクル]

Microsoft テスト マネージャーを使用してチーム プロジェクトのテスト計画およびテスト スイートを作成する場合は、複数の方法があります。 このトピックでは、使用する開発手法に応じた 2 つの方法を取り上げます。

1 つの方法として、すべてのマイルストーンに使用するテスト計画を 1 つ作成し、進行状況に応じてテスト スイートとテストを追加する方法が挙げられます。 ただし、この方法を使用した場合、それまでのマイルストーンのテスト成功率に関する履歴データは得られません。 したがって、使用する開発手法がどのようなものであっても、特定のイテレーションやマイルストーンに対して設定したテスト目標に基づいたテスト計画を作成する方が適切です。 イテレーションやマイルストーンに対応したテスト計画を作成することにより、テスト目標に基づいてイテレーションやマイルストーンの完了を確認できます。 また、現在のマイルストーンのテストを行いながら、次のイテレーションやマイルストーンのテスト計画も準備できます。 この方法により、それぞれのテスト計画についてテストの進行状況を追跡し、アプリケーションの品質が向上することを確認できます。

テスト スイートに手動テストと自動テストを両方追加すると、テスト スイートおよびテスト計画についてこれら 2 種類のテストの両方に基づいた総合的な品質を確認できます。

アプリケーションの開発およびテストに使用する手法に応じて、次のセクションを参照してください。

  • アジャイル開発

  • その他の開発手法

テスト計画、テスト スイート、およびそれらの作成方法の詳細については、「テスト計画の使用によるテスト作業の定義」を参照してください。

アジャイル開発

アプリケーションの開発およびテストにアジャイル手法を使用する場合、通常はユーザー ストーリーを作成し、スプリントおよびイテレーションを使用して、開発タスクとテスト タスクの進行状況を追跡します。 テスト計画を使用して、各スプリントと関連付けることができます。 たとえば、Web アプリケーションについて次のようなユーザー ストーリーを設定することができます。

  1. ユーザーは、Web サイトから複数の製品を選択して買い物カゴに追加する (スプリント 1)

  2. ユーザーは、クレジット カードを使用して買い物カゴ内の品目を購入する (スプリント 1)

  3. ユーザーは、品目の購入時に、次回はより簡単に購入できるようにするために情報を保存する (スプリント 2)

  4. ユーザーは、品目の購入時に、個人情報を再度入力しなくても済むようにするためにアカウントにサインインする (スプリント 2)

以下の手順では、これらをプロジェクトのユーザー ストーリーと想定しています。 これらのユーザー ストーリーのテスト ケースを作成します。 また、1 つに結合できる複数のユーザー ストーリーについて、エンド ツー エンドの機能をテストするテスト ケースが必要な場合もあります。 たとえば、ユーザーが品目を選択できること、その品目を買い物カゴに追加できること、サインインできること、および品目を購入できることをテストする場合があります。 これらの手順に従うことにより、次の図に示すように、テスト計画のセットを設定できます。

アジャイル開発のテスト計画とテスト スイート

プロジェクトのセットアップ

  1. プロジェクトの開始時に、次のテスト計画を作成します (これは、設定しようとするスプリントの数に基づいています)。

    1. スプリント 1 テスト計画

      これは、スプリント 1 のユーザー ストーリーのテストに使用されます。

    2. スプリント 2 テスト計画

      これは、スプリント 2 のユーザー ストーリーのテスト、およびスプリント 1 からの必要な回帰テストに使用されます。

    3. マスター テスト計画

      これは、複数のスプリントにわたるエンド ツー エンドのテストに使用されます。 サービス レベル アグリーメントに関するパフォーマンス テストにも使用できます。 このテスト計画は、複数のイテレーションにまたがっており、すべてのマイルストーンが完了したときにのみ完了できるため、特定のイテレーションに関連付ける必要はありません。

  2. ユーザー ストーリーのテストに使用する必要があるテスト構成を決定します。 たとえば、アプリケーションのユーザー ストーリーについて、Internet Explorer 8 での実行を構成 1、Firefox 3.5 での実行を構成 2 としてテストします。 次に、Microsoft テスト マネージャーを使用して、これらのテスト構成を作成します。 テスト構成を作成する方法の詳細については、「テスト構成の使用によるテスト マトリックスの定義」を参照してください。

  3. ユーザー ストーリーに必要なテスト構成をテスト計画に追加します。 既定では、これらの構成は、このテスト計画で作成したすべてのテスト スイートに使用されます。

    注意

    特定のユーザー ストーリーまたはテスト ケースに異なる構成を使用する必要がある場合は、それぞれのテスト スイートのテスト構成を変更できます。 詳細については、「方法: テスト計画またはテスト スイートに別のテスト構成を選択する」を参照してください。

スプリント 1 のテスト

  1. スプリント 1 のユーザー ストーリー 1 および 2 をスプリント 1 テスト計画に追加し、要件ベースのテスト スイート 2 つを作成します。 ユーザー ストーリーからテスト スイートを作成する方法の詳細については、「方法: 要件またはユーザー ストーリーをテスト計画に追加する」を参照してください。

  2. ユーザー ストーリーのテスト スイートに必要なテスト構成が正しいことを確認します。 既定では、各テスト スイートは、そのテスト計画のテスト構成を使用するようにセットアップされます。

  3. 受け入れテスト ケースを、ユーザー ストーリー 1 および 2 のこれらのテスト スイートに追加します。 たとえば、次のテスト ケースを適切なテスト スイートに追加できます。

    1. ユーザー ストーリー 1: 買い物カゴに品目を 1 つ追加する

    2. ユーザー ストーリー 1: 買い物カゴから品目を 1 つ削除する

    3. ユーザー ストーリー 2: 買い物カゴの品目を 1 つ購入する

      これらのテスト ケースは、ユーザー ストーリーから作成されたテスト スイートに追加された場合、そのユーザー ストーリーに自動的に関連付けられます。 テスト ケースをテスト スイートに追加する方法の詳細については、「方法: テスト ケースをテスト スイートに追加する」を参照してください。

      注意

      テスト ケースを作成するときに、テスト ステップを追加できます。また、テスト ステップがどのようなものになるかが明確になったときに、別のテスト担当者がテスト ステップを追加することもできます。

  4. 自動テストを作成する場合は、それらをテスト スイートに追加できます。 たとえば、単体テストまたはコード化された UI テストがある場合、それらをテスト ケースに関連付けてテスト スイートに追加できます。 詳細については、「方法: テスト ケースに自動テストを関連付ける」または「自動テストのアセンブリからのテスト ケースの作成」を参照してください。 スプリントの期間中に用意が整ったときはいつでも、これらのテストを追加できます。

  5. ユーザー ストーリーの完了時にテストすることがわかっているエンド ツー エンドのテスト ケースを、マスター テスト計画のエンド ツー エンドのテスト スイートに追加します。

  6. スプリントの期間中にユーザー ストーリーのテストの準備が整ったときは、テスト計画のテスト スイートの状態を [処理中] に設定します。 詳細については、「方法: テスト スイートのテストの状態を変更する」を参照してください。

    注意

    探索的テスト ケースを追加して、各ユーザー ストーリーの探索的テストに使用することもできます。 このテスト ケースは 1 つのテスト ステップで作成できます。バグを見つけた場合は、このテスト ステップでユーザー ストーリーを調べてアクションを記録します。

  7. [テストの実行] ビューで、実行するテスト ポイントを選択できます。 テスト ポイントは、テスト ケースとテスト構成の組み合わせです。 たとえば、テスト担当者 A が、Internet Explorer 8 のみがセットアップされたコンピューターを使用しているとします。 テスト担当者 A は、ユーザー ストーリーのうち Internet Explorer 8 で実行する必要があるすべてのテスト ポイントを選択して実行します。 テスト担当者 B は、ユーザー ストーリーのうち Firefox 3.5 で実行する必要があるすべてのテスト ポイントを選択して実行します。

  8. このユーザー ストーリーのテスト スイートの手動テストと自動テストがすべて完了すると、このテスト スイートのテストの状態を確認できます。 [テスト] アクティビティで、[テストの実行] ビューを選択します。 状態を確認するためのレポートも実行できます。 各スプリントの品質目標に基づいて、スプリントのテスト タスクが完了したかどうかを判断できます。 Microsoft テスト マネージャーからのレポートの詳細については、「テスト計画のテスト進行状況のレポート」を参照してください。

  9. スプリント 1 が完了したら、その次のスプリントに対して回帰テストとして実行する必要があるテストを決定することで、新しいユーザー ストーリーの展開によってスプリント 1 のユーザー ストーリーの機能が無効にならないようにする必要があります。

  10. スプリント 2 テスト計画に回帰というテスト スイートを作成します。 次に、これらの回帰テストに対して識別したテスト ケースを、スプリント 2 テスト計画のこのテスト スイートに追加します。

スプリント 2 のテスト

  1. スプリント 2 のユーザー ストーリー 3 および 4 をスプリント 2 テスト計画に追加し、要件ベースのテスト スイート 2 つを作成します。

  2. 受け入れテスト ケースを、ユーザー ストーリー 3 および 4 のこれらのテスト スイートに追加します。 たとえば、次のテスト ケースを追加できます。

    1. ユーザー ストーリー 3: ログイン アカウントを作成する

    2. ユーザー ストーリー 3: ログイン アカウントを作成しないでチェックアウトする

    3. ユーザー ストーリー 4: ログイン アカウントにサインインする (このテスト ケースにパラメーターを追加して、別のログイン アカウントでサインインすることもできます)。

    4. ユーザー ストーリー 4: ユーザーがパスワードを忘れた

    5. ユーザー ストーリー 4: アカウントの注文を確認する

      テスト ケースを作成するときに、テスト ステップを追加できます。また、テスト ステップがどのようなものになるかが明確になったときに、別のテスト担当者がテスト ステップを追加することもできます。

  3. 自動テストを作成する場合は、それらをテスト スイートに追加できます。 たとえば、単体テストまたはコード化された UI テストがある場合、それらをテスト ケースに関連付けてテスト スイートに追加できます。 スプリントの期間中に用意が整ったときはいつでも、これらのテストを追加できます。

  4. ユーザー ストーリーの完了時にテストすることがわかっている新しいエンド ツー エンドのテスト ケースを、マスター テスト計画のエンド ツー エンドのテスト スイートに追加します。

  5. スプリントの期間中にユーザー ストーリーのテストの準備が整ったときは、テスト スイートの状態を [処理中] に変更します。 次に、このユーザー ストーリーのテスト スイートの手動テストと自動テストを実行します。

    注意

    探索的テスト ケースを追加して、各ユーザー ストーリーの探索的テストに使用することもできます。 このテスト ケースは 1 つのテスト ステップで作成できます。バグを見つけた場合は、このテスト ステップでユーザー ストーリーを調べてアクションを記録します。

  6. [テスト] アクティビティの [テストの結果] ビューで、各テスト スイートのテストの状態を確認できます。 状態を確認するためのレポートも実行できます。 各スプリントの品質目標に基づいて、スプリントのテスト タスクが完了したかどうかを判断できます。

  7. このスプリントに適したパフォーマンス テストまたはエンド ツー エンドのテストを実行します。

  8. スプリント 2 が完了したら、その次のスプリント (存在する場合) に対して回帰テストとして実行する必要があるテストを決定することで、新しいユーザー ストーリーの展開によってスプリント 2 のユーザー ストーリーの機能が無効にならないようにする必要があります。

  9. 次のスプリント (スプリント 3) のテスト計画で、回帰というテスト スイートをスプリント 2 テスト計画からコピーします。 次に、これらの回帰テストに対して識別したテスト ケースを、スプリント 3 テスト計画のこのテスト スイートに追加します。 別のテスト計画からテスト スイートをコピーする方法の詳細については、「方法: 別のテスト計画からのテスト スイートのコピー」を参照してください。

それぞれのスプリントに対してこのプロセスを続行します。 この方法により、スプリントについてテスト計画のセットを作成します。 また、次のテスト計画に繰り越す回帰テストのテスト スイートも作成します。 ベータ 1 などの主要なマイルストーンの場合は、スプリントからテストの一部またはすべてを再実行することも選択できます。 同じテスト計画作成の手法を使用してこのベータ 1 というマイルストーンのテスト計画を作成し、テスト スイートをこのテスト計画にコピーすることができます。 この方法により、このテスト計画のテスト結果を別に記録して、個々のスプリント テスト計画と比較できます。

その他の開発手法

アジャイル手法を使用しない場合、機能に基づいた開発タスクおよびテスト タスクを行うことになります。 ただし、ユーザー ストーリーの代わりに要件を使用することもできます。 要件を使用する場合は、アジャイル開発のセクションの方法を使用して、スプリントの代わりに特定のマイルストーンのテスト計画を作成し、要件をテスト計画に追加することができます。 たとえば、ベータ 1 に対するすべての要件がテスト スイートとして追加されたベータ 1 テスト計画があるとします。 そこでは、受け入れテスト ケースと単体テストをこれらのテスト スイートに追加して、テスト ケースと要件を関連付けることができます。 詳細については、「方法: 要件またはユーザー ストーリーをテスト計画に追加する」を参照してください。 単体テストをテスト計画に追加する方法の詳細については、「方法: テスト ケースに自動テストを関連付ける」または「自動テストのアセンブリからのテスト ケースの作成」を参照してください。

より機能ベースの方法を使用している場合は、Web アプリケーションに次のような機能を設定することができます。

  1. 買い物カゴ (アルファ)

  2. ログイン (アルファ)

  3. チェックアウト (ベータ 1)

  4. 注文確認 (ベータ 1)

以下の手順では、これらをプロジェクトの機能と想定しています。 また、1 つの機能がチーム プロジェクトの 1 つの特定の領域パスに関連付けられると想定しています。 これらの機能のテスト ケースを作成します。 また、特別に複数の機能をテストするテスト ケースが必要な場合もあります。 たとえば、ユーザーが品目を買い物カゴに追加できること、サインインできること、および品目を購入できることをテストする場合があります。 これらの手順に従うことにより、次の図に示すように、テスト計画のセットを設定できます。

機能に基づくテスト スイートのガイダンス

プロジェクトのセットアップ

  1. プロジェクトの開始時に、次のテスト計画を作成します (これは、計画に含まれるマイルストーンの数に基づいています)。

    1. アルファ

      これは、アルファで使用可能な機能のテストに使用されます。

    2. ベータ 1

      これは、アルファのフィードバックに基づく機能の変更やアルファの機能への追加など、ベータで使用可能な機能のテストに使用されます。

  2. これらの機能のテストに使用するために用意する必要があるテスト構成を決定します。 たとえば、アプリケーションのこれらの機能について、Internet Explorer 8 での実行を構成 1、Firefox 3.5 での実行を構成 2 としてテストします。 次に、Microsoft テスト マネージャーを使用して、これらのテスト構成を作成します。 テスト構成を作成する方法の詳細については、「テスト構成の使用によるテスト マトリックスの定義」を参照してください。

  3. 機能に必要なテスト構成をテスト計画に追加します。 既定では、これらの構成は、このテスト計画で作成したすべてのテスト スイートに使用されます。

    注意

    特定の機能またはテスト ケースに異なる構成を使用する必要がある場合は、それぞれのテスト スイートのテスト構成を変更できます。 詳細については、「方法: テスト計画またはテスト スイートに別のテスト構成を選択する」を参照してください。

アルファ テスト

  1. 買い物カゴのテスト スイートおよびログインのテスト スイートをアルファ テスト計画に追加します。 これらを静的なテスト スイートとして作成し、テスト ケースをこれらのスイートに追加できます。 テスト ケースを静的なテスト スイートに追加する方法の詳細については、「方法: テスト スイートを作成して管理する」を参照してください。

    重要

    テストする製品の領域に基づいてテスト ケースを作成するときに、領域パスを選択することもできます。 多くの場合、領域パスは機能または機能のセットに対応付けられます。 領域パスを選択した場合は、この領域パスのクエリに基づくクエリ ベースのテスト スイートを作成できます。 テスト ケースをこの領域パスに追加するときは、常に自動的にクエリ ベースのテスト スイートに追加されます。 これは、テスト スイートの保守に役立ちます。 この例では、1 という領域パスに 1 つのクエリ ベースのテスト スイートを、2 という領域パスには別のクエリ ベースのテスト スイートを、静的なテスト スイートの代わりに作成できます。 これらのクエリ ベースのテスト スイートを作成する方法の詳細については、「方法: クエリ ベースのテスト スイートを作成して管理する」を参照してください。

  2. 各機能のテスト スイートに必要なテスト構成が正しいことを確認します。 既定では、各テスト スイートは、そのテスト計画のテスト構成を使用するようにセットアップされます。

  3. テスト ケースを、それぞれの機能のこれらのテスト スイートに追加します。 たとえば、クエリ ベースのテスト スイートを作成する場合は、次のようなテスト ケースを適切なテスト スイートに追加することも、その領域パスに適した値を使用したテスト ケースだけを作成することもできます。

    1. 買い物カゴ: 買い物カゴに品目を 1 つ追加する

    2. 買い物カゴ: 買い物カゴから品目を 1 つ削除する

    3. ログイン: ユーザー アカウントにログインする

      テスト ケースをテスト スイートに追加する方法の詳細については、「方法: テスト ケースをテスト スイートに追加する」を参照してください。

      注意

      テスト ケースを作成するときに、テスト ステップを追加できます。また、テスト ステップがどのようなものになるかが明確になったときに、別のテスト担当者がテスト ステップを追加することもできます。

  4. 自動テストを作成する場合は、それらをテスト スイートに追加できます。 たとえば、単体テストまたはコード化された UI テストがある場合、それらをテスト ケースに関連付けてテスト スイートに追加できます。 領域パスに基づいてクエリ ベースのテスト スイートを作成した場合は、これらのテスト ケースに対して領域パスの値が正しいことを確認する必要があります。 自動テストをテスト ケースに関連付ける方法の詳細については、「方法: テスト ケースに自動テストを関連付ける」または「自動テストのアセンブリからのテスト ケースの作成」を参照してください。 アルファ テスト中に用意が整ったときはいつでも、これらのテストを追加できます。

  5. プロジェクト テストのアルファ フェーズ中に機能のテストの準備が整ったときは、テスト計画のテスト スイートの状態を [処理中] に設定します。 詳細については、「方法: テスト スイートのテストの状態を変更する」を参照してください。

    注意

    探索的テスト ケースを追加して、機能の探索的テストに使用することもできます。 このテスト ケースは 1 つのテスト ステップで作成できます。バグを見つけた場合は、このテスト ステップで機能を調べてアクションを記録します。

  6. [テストの実行] ビューで、実行するテスト ポイントを選択できます。 テスト ポイントは、テスト ケースとテスト構成の組み合わせです。 たとえば、テスト担当者 A が、Internet Explorer 8 のみがセットアップされたコンピューターを使用しているとします。 テスト担当者 A は、ユーザー ストーリーのうち Internet Explorer 8 で実行する必要があるすべてのテスト ポイントを選択して実行します。 テスト担当者 B は、ユーザー ストーリーのうち Firefox 3.5 で実行する必要があるすべてのテスト ポイントを選択して実行します。

  7. この機能のテスト スイートの手動テストと自動テストがすべて完了すると、[テスト] アクティビティの [テストの実行] ビューで、このテスト スイートのテストの状態を確認できます。 状態を確認するためのレポートも実行できます。 アルファ テストに対して設定した品質目標に基づいて、テスト タスクが完了したかどうかを判断できます。 Microsoft テスト マネージャーからのレポートの詳細については、「テスト計画のテスト進行状況のレポート」を参照してください。

ベータ 1 テスト

  1. テスト スイートをアルファ テスト計画からベータ 1 テスト計画にコピーします。 別のテスト計画からテスト スイートをコピーする方法の詳細については、「方法: 別のテスト計画からのテスト スイートのコピー」を参照してください。

  2. 静的なテスト スイートを使用している場合は、チェックアウトのテスト スイートおよび注文確認のテスト スイートを、ベータ 1 テスト計画に追加します。 領域パスのクエリ ベースのテスト スイートを使用している場合は、領域パス 1 または 2 について作成したテストが、アルファ テスト計画からコピーしたテスト スイートに自動的に追加されます。

  3. エンド ツー エンドというテスト スイートをベータ 1 テスト計画に追加します。 テスト ケースをこのテスト スイートに追加して、複数の機能を含むエンド ツー エンドのシナリオをテストします。

  4. クエリ ベースのテスト スイートを作成する場合は、テスト ケースをこれらの新しい機能のテスト スイートに追加することも、適切な領域パスを使用したテスト ケースだけを作成することもできます。 また、アルファの機能に加える変更のテスト ケース、またはこれらの機能に対する追加機能のテスト ケースを追加することもできます。 たとえば、次のテスト ケースを追加できます。

    1. チェックアウト: 買い物カゴの品目をチェックアウトする

    2. チェックアウト: ログイン アカウントを作成しないでチェックアウトする

    3. ログイン (追加テスト ケース): ユーザーがパスワードを忘れた

    4. 注文確認: アカウントの注文を確認する

    5. エンド ツー エンド: 品目を追加し、ログインし、チェックアウトする

      テスト ケースを作成するときに、テスト ステップを追加できます。また、テスト ステップがどのようなものになるかが明確になったときに、別のテスト担当者がテスト ステップを追加することもできます。

  5. 自動テストを作成する場合は、それらをテスト スイートに追加できます。 たとえば、単体テストまたはコード化された UI テストがある場合、それらをテスト ケースに関連付けてテスト スイートに追加できます。 ベータ 1 の期間中に用意が整ったときはいつでも、これらのテストを追加できます。

  6. ベータ 1 の期間中に機能のテストの準備が整ったときは、テスト スイートの状態を [処理中] に変更します。 次に、この機能のテスト スイートの手動テストと自動テストを実行します。

    注意

    探索的テスト ケースを追加して、ベータ 1 の新しい各機能の探索的テストに使用することもできます。 このテスト ケースは 1 つのテスト ステップで作成できます。バグを見つけた場合は、このテスト ステップで機能を調べてアクションを記録します。

  7. [テスト] アクティビティの [テストの結果] ビューで、各テスト スイートのテストの状態を確認できます。 状態を確認するためのレポートも実行できます。 ベータ 1 に対して設定した品質目標に基づいて、テスト タスクが完了したかどうかを判断できます。

  8. ベータ 1 に必要なエンド ツー エンドのテストを実行します。

プロジェクトのマイルストーンがさらにある場合は、その各マイルストーンに対してこのプロセスを続行できます。 この方法により、各マイルストーンについて新しいテスト計画を作成します。 また、次のマイルストーンのテスト計画にコピーするエンド ツー エンドのテストのテスト スイートも作成します。 前のマイルストーンからのテスト スイートのすべてのテストを実行する十分な時間がない場合は、コピーしたテスト スイートのテストを制限できます。 たとえば、優先度 1 のテストのみに制限する場合があります。 クエリ ベースのテスト スイートを使用している場合は、優先順位に加えるクエリを変更できます。 静的なテスト スイートを使用している場合は、マイルストーンについての再実行の必要がないテスト ケースを単に削除できます。

参照

処理手順

Microsoft テスト マネージャーを使用した手動テストのクイック スタート ガイド

概念

テスト計画の使用によるテスト作業の定義