テスト計画、テスト戦略、テストケース、テストスクリプト、テストシナリオ、およびテスト条件の違い

difference between test plan

例を使用して、テスト計画、テスト戦略、テストケース、テストスクリプト、テストシナリオ、およびテスト条件の違いを学びます。

ソフトウェアテストには、すべてのソフトウェアテスターが知っておくべきいくつかの基本的な概念と重要な概念が含まれています。

この記事では、ソフトウェアテストのさまざまな概念とその比較について説明します。

テスト計画とテスト戦略、テストケースとテストスクリプト、テストシナリオとテスト条件、テスト手順とテストスイート わかりやすく説明しています。

=> 完全なテスト計画チュートリアルシリーズについては、ここをクリックしてください

Sasi C.が尋ねた上記の質問は、私たちの中で最もよく聞かれる質問です。 ソフトウェアテストクラス そして、私はいつも参加者に、経験を積むとこれらの言葉にほとんど気付かず、それらが私たちの語彙の一部になることを伝えます。

しかし、多くの場合、混乱がこれらを取り囲んでおり、この記事では、一般的に使用されるいくつかの用語を定義しようとしています。

さまざまなソフトウェアテストの概念

以下に、さまざまなソフトウェアテストの概念とその比較を示します。

はじめましょう！！

学習内容：

• テスト計画とテスト戦略の違い
  • テスト計画
  • テスト計画文書
    • テスト計画の種類
  • テスト戦略
  • テスト戦略ドキュメント
    • ＃1）プロジェクトの概要
    • ＃2）要件の範囲
    • ＃3）高レベルのテスト計画
    • ＃4）テストアプローチ
    • ＃5）テストカバレッジ
    • ＃6）テスト環境
    • ＃7）QAの成果物と指標
    • ＃8）欠陥管理
    • ＃9）コミュニケーション管理
    • ＃10）仮定、リスク、および依存関係
    • ＃11）付録
  • テスト計画とテスト戦略
• テストケースとテストスクリプトの違い
• テストシナリオとテスト条件の違い
• テスト手順とテストスイートの違い
• 結論
  • 推奨読書

テスト計画とテスト戦略の違い

テスト戦略とテスト計画は、プロジェクトのテストライフサイクルにおける2つの重要なドキュメントです。ここでは、テスト戦略とテスト計画ドキュメントに関する深い知識を提供しようとしています。

テスト計画

テスト計画は、ソフトウェアアプリケーションをテストするための範囲、目的、およびアプローチを定義するドキュメントとして定義できます。テスト計画は期間であり、成果物です。

テスト計画は、QAプロジェクトのすべてのアクティビティを一覧表示し、それらをスケジュールし、プロジェクトの範囲、役割と責任、リスク、開始と終了の基準、テストの目的、およびその他の考えられるすべてのものを定義するドキュメントです。

テスト計画は、私が「スーパードキュメント」と呼んでいるように、知っておくべきことや必要なことすべてをリストしたものです。お願いします このリンクを確認してください 詳細とサンプルについては。

テスト計画は、要件に基づいて設計されます。テストエンジニアに作業を割り当てているときに、何らかの理由で、テスターの1人が別のテスターに​​置き換えられます。ここで、テスト計画が更新されます。

テスト戦略は、テストアプローチとそれを取り巻く他のすべての概要を示しています。テスト戦略はテスト計画のサブセットにすぎないという意味で、テスト計画とは異なります。これは、ある程度一般的で静的なハードコアテストドキュメントです。テスト戦略や計画がどのレベルで使用されているかについても議論がありますが、実際には目立った違いは見られません。

例： テスト計画は、誰がいつテストするかについての情報を提供します。 例えば、 モジュール1は「Xテスター」によってテストされます。テスターYが何らかの理由でXを置き換える場合は、テスト計画を更新する必要があります。

テスト計画文書

テスト計画は、ソフトウェアプロジェクトに関連するテストタスクに関する完全な情報を提供するドキュメントです。テストの範囲、テストの種類、目的、テスト方法論、テストの取り組み、リスクと不測の事態、リリース基準、テスト成果物などの詳細を提供します。コーディング後にシステムで実行される可能性のあるテストを追跡します。

テスト計画は明らかに変更される予定です。最初に、ドラフトテスト計画は、その時点でのプロジェクトの明確さに基づいて作成されます。この初期計画は、プロジェクトが進むにつれて変更されます。テストチームマネージャーまたはテストリードは、テスト計画文書を作成できます。仕様を記載しており、それに基づいて変更される場合があります。

何をテストするか、いつテストするか、誰がテストするか、どのようにテストするかは、テスト計画で定義されます。テスト計画では、問題、依存関係、および根本的なリスクのリストを整理します。

テスト計画の種類

テスト計画は、テストの段階に基づいてさまざまなタイプにすることができます。最初に、プロジェクト全体の実行のためのマスターテスト計画があります。システムテスト、システム統合テスト、ユーザー受け入れテストなどの特定のテストタイプに対して、個別のテスト計画を作成できます。

別のアプローチは、機能テストと非機能テストに別々のテスト計画を立てることです。このアプローチのパフォーマンスでは、テストには個別のテスト計画があります。

テスト計画書の内容（ IEEE-829テスト計画の構造 ）

テスト計画の明確な形式を描くことは困難です。テスト計画の形式は、手元のプロジェクトによって異なる場合があります。 IEEEは、IEEE-829テスト計画構造として説明されるテスト計画の標準を定義しています。

標準のテスト計画の内容については、以下のIEEE推奨事項を参照してください。

1. テスト計画識別子
2. 前書き
3. テスト項目
4. ソフトウェアリスクの問題
5. テストする機能
6. テストされない機能
7. アプローチ
8. アイテムの合格/不合格基準（または）合格基準
9. 一時停止の基準と再開の要件
10. テスト成果物
11. テストタスク
12. 環境要件
13. 人員配置とトレーニングのニーズ
14. 責任
15. スケジュール
16. 承認

推奨読書=> テスト計画チュートリアル–完璧なガイド

テスト戦略

テスト戦略は、テストの設計を説明し、テストの実行方法を決定する一連のガイドラインです。

例： テスト戦略には、「個々のモジュールはテストチームのメンバーによってテストされる」などの詳細が含まれます。この場合、誰がテストするかは重要ではありません。したがって、一般的なものであり、チームメンバーの変更を更新する必要はなく、静的な状態を維持します。

テスト戦略ドキュメント

テスト戦略の目的は、テストアプローチ、テストの種類、テスト環境、テストに使用するツール、およびテスト戦略を他のプロセスとどのように連携させるかについての高レベルの詳細を定義することです。テスト戦略ドキュメントは、生きたドキュメントであることが意図されており、要件、SLAパラメータ、テスト環境、ビルド管理アプローチなどがより明確になったときに更新されます**。

テスト戦略は、プロジェクトスポンサー、ビジネスSME、アプリケーション/統合開発、システム統合パートナー、データ変換チーム、テクニカルリード、アーキテクチャリード、展開およびインフラストラクチャチームなどのビルド/リリース管理チームで構成される完全なプロジェクトチームを対象としています。

**** 一度定義されたテスト戦略は決して更新されるべきではないと主張する人もいます。通常、ほとんどのテストプロジェクトでは、プロジェクトの進行に応じて更新されます。

以下は、テスト戦略ドキュメントに必要な重要なセクションです。

＃1）プロジェクトの概要

このセクションでは、組織の概要を説明した後、手元にあるプロジェクトについて簡単に説明します。以下の詳細を含めることができます

• プロジェクトの必要性は何でしたか？
• プロジェクトはどのような目的を達成しますか？

頭字語の表： ドキュメントを参照しているときにドキュメントリーダーが思い付く可能性のある頭字語の表を含めることをお勧めします。

＃2）要件の範囲

要件スコープには、アプリケーションスコープと機能スコープを含めることができます

左内部結合と左外部結合

アプリケーションの範囲 テスト対象のシステムと、新機能または変更された機能によるシステムへの影響を定義します。関連するシステムも定義できます。

機能範囲 システム内のさまざまなモジュールへの影響を定義します。ここでは、機能に関連する各システムについて説明します。

＃3）高レベルのテスト計画

テスト計画は別のドキュメントです。テスト戦略には、高レベルのテスト計画を含めることができます。高レベルのテスト計画には、テストの目的と範囲を含めることができます。テストスコープは、スコープ内アクティビティとスコープ外アクティビティの両方を定義する必要があります。

＃4）テストアプローチ

このセクションでは、テストのライフサイクル中に実行されるテストアプローチについて説明します。

上の図のように、テストは2つのフェーズ、つまりテスト戦略と計画とテスト実行で実行されます。テスト戦略と計画フェーズはプログラム全体に対して1回ですが、テスト実行フェーズはプログラム全体のサイクルごとに繰り返されます。上の図は、実行アプローチの各フェーズにおけるさまざまな段階と成果物（結果）を示しています。

PCをクリーニングするための最高のフリーソフトウェア

テストアプローチには、以下のサブセクションを含める必要があります

a）テストスケジュール： このサブセクションで提案されたプロジェクトのタイムラインを説明する

b）機能テストアプローチ： このサブセクションを使用すると、各フェーズの概要と、それぞれの開始および終了基準が提供されます。さまざまなテストフェーズは、単体テスト、システムテスト、システム統合テスト、ユーザー受け入れテスト、およびエンドツーエンドテストです。

c）主要業績評価指標のテスト：

• テストケースの優先順位付け： 時間の制約がある場合に、テストチームが優先度の高いシナリオを実行できるように、テストケースの優先順位付けアプローチを定義します。計画されたすべてのシナリオを実行しないことに伴う可能性のあるリスクに関して、プロジェクトの利害関係者間で合意が必要です。
• 欠陥の優先順位付け： 欠陥の優先順位付け戦略は、ここで取り上げる次のトピックです。優先度レベルを定義し、クリティカル、高、中などの各レベルに説明を付けます。
• 欠陥のターンアラウンドタイム： 欠陥のターンアラウンドタイムは、欠陥が最初に発生してから欠陥が修正されて再テストが行​​われるまでの時間として定義されます。迅速なターンアラウンドにより、迅速なテストとプロジェクトのタイムラインの順守が保証されます。欠陥の優先度レベルごとに、ターンアラウンドタイムを定義します。

＃5）テストカバレッジ

このセクションでは、テストシナリオとテストケースでビジネス/機能要件の範囲を最適化するためにQAチームが従うプロセスについて説明します。 要件トレーサビリティマトリックス： （RTM）を使用して、それぞれのテストシナリオとテストケースですべての要件を追跡できます。

＃6）テスト環境

利用可能なさまざまなQA環境を定義します。どの環境で誰がどのテストを行うかについて言及します。緊急事態に対処するための環境バックアップ計画を作成します。各環境へのアクセスは規制され、明確に呼び出される必要があります。

使用する予定のテストツールについても、このセクションで説明します。

＃7）QAの成果物と指標

すべてのQA成果物を一覧表示します

すべてのQAメトリクスを一覧表示します

＃8）欠陥管理

欠陥ワークフロー、欠陥追跡方法論、および欠陥トリアージプロセスを作成することにより、欠陥管理戦略を明確に定義します。各テスターの役割に対する欠陥の責任について言及します。定期的な欠陥分析と根本原因分析により、テストの全体的な品質が向上します

＃9）コミュニケーション管理

ステータスレポート、ステータス会議、およびオンサイトとオフショアのコミュニケーションのガイドラインを設定します。

＃10）仮定、リスク、および依存関係

プロジェクトの基礎となる仮定を説明してください。これらには、タイミング、リソース、およびシステム機能が含まれる場合があります。他のプロジェクト、一時的なリソースの可用性、プロジェクトに影響を与える可能性のある他の期限などの依存関係を説明してください

＃11）付録

このセクションには、役割と責任、作業時間帯、参照などを含めます

参考文献=> 優れたテスト戦略ドキュメントを作成するためのガイド 。

テスト計画とテスト戦略

これら2つのドキュメントの違いは微妙です。テスト戦略は、プロジェクトに関する高レベルの静的ドキュメントです。一方、テスト計画では、何をテストするか、いつテストするか、どのようにテストするかを指定します。

テストケースとテストスクリプトの違い

私の意見では、これら2つの用語は同じ意味で使用できます。はい、違いはないと言っています。テストケースは、アプリケーションで特定のテストを実行するのに役立つ一連の手順です。テストスクリプトも同じです。

現在、テストケースは手動テスト環境で使用される用語であり、テストスクリプトは自動化環境で使用されるという考え方があります。これは、それぞれの分野のテスターの快適さのレベルと、ツールがテストを参照する方法（テストスクリプトを呼び出すものとテストケースに呼び出すもの）があるため、部分的に当てはまります。

したがって、実際には、テストスクリプトとテストケースはどちらも、手動または自動化によってその機能を検証するためにアプリケーションで実行されるステップです。

参考文献=> 効果的なテストケースを書く方法は？ そして テストケースサンプルテンプレート 。

テストシナリオとテスト条件の違い

テストシナリオ： これは、アプリケーションをテストするためのすべての可能な方法を定義する方法です。これは、アプリケーションをテストするためのすべての可能な方法をカバーする単一のステートメントです。

試験条件： テスト条件は、テスターがアプリケーションをテストするために従わなければならない仕様です。

これは、テスターがテスト設計フェーズへの最初の移行ステップとして作成する1行のポインターです。これは主に、特定の機能に関してテストする「何」の1行の定義です。通常、テストシナリオは、テストケースを作成するために入力されます。

アジャイルプロジェクトでは、テストシナリオが唯一のテスト設計出力であり、これらに続いてテストケースは作成されません。テストシナリオでは、複数のテストが発生する可能性があります。

テストシナリオの例：

• 管理者が新しい国を追加できるかどうかを検証します
• 管理者が既存の国を削除できるかどうかを検証します
• 既存の国を更新できるかどうかを検証します

一方、テスト条件はより具体的です。これは、特定のテストの目的/目標として大まかに定義できます。

テスト条件の例： 上記の例では、シナリオ1をテストする場合、次の条件をテストできます。

• 国名を「インド」（有効）として入力し、国が追加されていることを確認します
• 空白を入力して、国が追加されるかどうかを確認します。
• いずれの場合も、特定のデータが記述されており、テストの目的ははるかに正確です。

参考文献=> Webおよびデスクトップアプリケーションをテストするための180以上のサンプルテストシナリオ。

テスト手順とテストスイートの違い

テスト手順は、エンドツーエンドの状況を実行するなど、特定の論理的な理由に基づいたテストケースの組み合わせです。テストケースが実行される順序は固定されています。

テスト手順： それはテストライフサイクルに他なりません。テストライフサイクルには10のステップがあります。

彼らです：

1. 労力の見積もり
2. プロジェクトの開始
3. システム研究
4. テスト計画
5. デザインテストケース
6. テスト自動化
7. テストケースを実行する
8. 欠陥を報告する
9. 回帰試験
10. 分析および要約レポート

例えば 、Gmail.comからのメールの送信をテストする場合、テスト手順を形成するために組み合わせるテストケースの順序は次のようになります。

1. ログインを確認するためのテスト
2. メールを作成するためのテスト
3. 1つ以上の添付ファイルを添付するためのテスト
4. さまざまなオプションを使用して、必要な方法で電子メールをフォーマットする
5. To、BCC、CCフィールドへの連絡先または電子メールアドレスの追加
6. メールを送信し、「送信済みメール」セクションに表示されていることを確認します

上記のすべてのテストケースは、それらの最後に特定の目標を達成するためにグループ化されています。また、テスト手順には、任意の時点で組み合わされたいくつかのテストケースがあります。

一方、テストスイートは、テストサイクルや回帰フェーズなどの一部として実行する必要があるすべてのテストケースのリストです。機能に基づく論理的なグループ化はありません。構成テストケースが実行される順序は、重要な場合と重要でない場合があります。

テストスイート： Test Suiteは、テスターがテストの実行ステータスを実行および報告するのに役立つ一連のテストを含むコンテナーです。アクティブ、進行中、完了の3つの状態のいずれかを取ることができます。

テストスイートの例 ：アプリケーションの現在のバージョンが2.0の場合。以前のバージョン1.0には、完全にテストするための1000のテストケースがあった可能性があります。バージョン2の場合、新しいバージョンで追加された新しい機能をテストするための500のテストケースがあります。

したがって、現在のテストスイートは、回帰と新機能の両方を含む1000 +500のテストケースになります。スイートも組み合わせですが、目的の機能を実現しようとはしていません。

テストスイートには、数百または数千のテストケースを含めることができます。

結論

ソフトウェアテストの概念は、ソフトウェアテストのライフサイクルにおいて主要な役割を果たします。

すべてのソフトウェアテスターがテストプロセスを効果的に実行するには、上記の概念とその比較を明確に理解することが非常に重要です。

通常、これらのような記事は、より深い議論のための優れた出発点です。それで、あなたの考え、同意、不同意、そして他の何かを以下のコメントで貢献してください。皆様からのフィードバックをお待ちしております。

また、ソフトウェアテスト全般、またはテストのキャリアに関連するものについての質問も歓迎します。これらについては、同じシリーズの今後の投稿で詳しく説明します。

幸せな読書！！

=> 完全なテスト計画チュートリアルシリーズについては、こちらをご覧ください

前のチュートリアル | 次のチュートリアル

推奨読書

• テスト計画チュートリアル：ソフトウェアテスト計画ドキュメントを最初から作成するためのガイド
• テスト戦略ドキュメントの書き方（サンプルテスト戦略テンプレート付き）
• テストケース作成の準備方法(生産性のヒント)
• テストシナリオとは：例を含むテストシナリオテンプレート
• パフォーマンステスト計画とパフォーマンステスト戦略の違い
• テストケースの書き方：例を含む究極のガイド
• フォーマットと内容のサンプルソフトウェアテスト計画テンプレート
• テストシナリオとテストケース：これらの違いは何ですか？