what are test deliverables software testing
例を使用して、ソフトウェアテストのテスト成果物についてすべて学びます。
授与された割り当てが正常に完了すると、すべてのテスターに安堵のため息がつきます。すべてのテストの最後に、テスターは適切なテスト成果物をクライアントに送信する必要があります。
この記事では、いくつかの重要なテスト成果物について詳しく見ていきます。
一般に、テスト成果物はプロジェクト全体で使用されます。これらはテストのすべてのフェーズで使用され、さらに処理を進めるために常に時間どおりに送信する必要があります。
学習内容：
ソフトウェアテストでのテスト成果物
テスト成果物は、ソフトウェアテストで重要な役割を果たします。この記事では、テスト成果物について詳しく説明します。
重要なテスト成果物のいくつかは、参考のために以下にリストされています。
- テスト戦略
- テスト計画と見積もり
- テストシナリオ
- テストケースとテストデータ
- RTM
- テスト概要レポート
- テスト終了レポート
- 事故報告書
テスト戦略
テスト戦略は、ビジネス要件の仕様に基づいて決定されます。これは、実行するテスト作業のすべての詳細を含む重要なドキュメントです。完全な管理文書です。
テスト計画と比較すると、これは高レベルのドキュメントであり、通常はテストマネージャーまたはリードによって作成されます。ここでは、テストの目的、テストのアプローチ、テストの範囲、開始と終了の基準、テストの種類とレベル、マイルストーン、人員配置などを記載する必要があります。
テスト計画と見積もり
テストの各ステップの詳細レベルの詳細をここに記載する必要があります。一般に、適切な計画は適切な作業構造につながります。同様に、優れた計画は優れたテストにつながります。
ここでは、テストの目的、テストのアプローチ、テストの範囲、開始と終了の基準、テストの種類とレベル、マイルストーン、人員配置などを詳細に説明する必要があります。
単純なプロジェクトでは、テストの実施方法を含むマスタープランが使用されます。
推定： 見積もりとは、テストで各ステップが発生する期間と全体的なコストを定義することです。
また読む=> 完璧なテスト計画のチュートリアル–詳細ガイド
テストシナリオ
これを例で理解します。ここでは、例として列車の予約を取り上げましょう。テストする必要のあるすべての機能は、テストシナリオドキュメントに高レベルの形式で記載されています。簡単に言えば、実行される同様のアクティビティのグループを意味します。
シナリオの2つのテクニック：
＃1）ユースケース
これは、外部要因とシステムの間の一連の相互作用である目標指向の方法です。そのコンポーネントには、プライマリフロー、代替フロー、トリガーまたはアクティビティ、例外フロー、事前条件、事後条件などが含まれます。
例：
(画像 ソース )
＃2）ACE（アクティビティコンポーネント要素）
アクティビティコンポーネント要素プロセスは、ビジネス要件をアクティビティに分割します。
例：
通常、乗客の詳細や性別などを入力してチケットを予約します。したがって、シナリオとなる次のフィールドを検証する必要があります。
- 予約： 予約機能を確認してください。
- 乗客の詳細： 性別、年齢、性別フィールドの機能を確認してください。
- 変更： 変更機能が正しく機能するかどうかを確認します。
- 租界： 譲歩機能が正しく機能するかどうかを確認します。
- 見る： ビュー機能が正しく機能するかどうかを確認します。
- キャンセル： キャンセル機能が正しく機能するかどうかを確認します。
ここで、譲歩は、ユーザーが年齢に基づいて譲歩の有無にかかわらず予約できるため、「代替シナリオ」と呼ばれる場合があります。ただし、目標は同じです。つまり、チケットを予約することです。
手動テスト用の無料オンラインテスト
テストケース
上記の予約ページの例と同じように、テストケースは次のように記述されます。
予約：
- すべてのフィールドに有効な詳細を入力して、ユーザーがチケットを予約できるかどうかを確認します。
- すべてのフィールドに無効な詳細を入力して、ユーザーがチケットを予約できるかどうかを確認します。
- 空白のフィールドを残して、ユーザーがチケットを予約できるかどうかを確認します。
乗客の詳細：
- ユーザーが有効な名前を入力してチケットを予約できるかどうかを確認します。
- ユーザーが無効な名前を入力してチケットを予約できるかどうかを確認してください。
- ユーザーが一度に1つの性別を選択して、チケットを予約できるかどうかを確認します。
- ユーザーが60歳以上を入力してチケットを予約できるかどうかを確認します。
- ユーザーが60歳未満を入力してチケットを予約できるかどうかを確認します。
- 5歳を超える有効な年齢を入力して、ユーザーがチケットを予約できるかどうかを確認します。
- 5歳未満の年齢を入力して、ユーザーが予約できないかどうかを確認します。
変更：
- ユーザーが名前フィールドを変更できるかどうかを確認します。
- ユーザーが性別フィールドを変更できるかどうかを確認します。
- ユーザーが年齢フィールドを変更できるかどうかを確認します。
租界：
- 「」を選択して、ユーザーが譲歩できるかどうかを確認します。 高齢者 」オプション。
- 「」を選択して、ユーザーが譲歩できるかどうかを確認します。 障害者/障害者 」オプション。
見る：
- 予約したチケットを利用できるか確認してください。
キャンセル：
- ユーザーがチケットをキャンセルできるかどうかを確認します。
したがって、テストケースは、正確に何を詳細にテストする必要があるかを示します。テストケースは単純な言語で書かれている必要があり、簡単に理解できる必要があります。関係するクライアントの要求に応じて、適切な形式で作成する必要があります。
テストデータ
一部のプロジェクトでは、テストケースの実行を続行する前に、クライアントからの事前データが必要です。テストを実行するには、テストデータを適用する必要があります。
例： 注射を受けるための病院ポータルでは、注射リマインダーオプションを確認するために患者の詳細を取得することが重要です。
ここで「患者の詳細」はテストデータです。
推奨読書=> テストデータ–例を含む意味と準備のテクニック
RTM /要件トレーサビリティマトリックス
- 名前が示すように、それは単に、すべての要件を適切なテストケースにマッピングする必要があることを意味します。
- テストケースのすべての要件を満たしているかどうかを確認するのに役立ちます。
- これは、プロジェクトのやり直しや次の連続リリースに役立ちます。
- クライアントは、カバレッジステータスを簡単に確認し、テストプロセスを知ることができます。
テスト概要レポート
テスト要約レポートは、実行されたすべてのテストアクティビティを要約し、テスト結果がその中にまとめられます。テストに関与するメンバー、目的、範囲、クライアントの詳細、使用したテストアプローチ、テスト結果、欠陥レポートなど、すべてのテスト情報をここに記載する必要があります。
ただし、テスト要約レポートは、クライアントのアドバイスに従って作成する必要があります。したがって、全体的なパフォーマンスを確認することは、クライアントにとっても有用なドキュメントです。
テストクロージャレポート
これは、テストと欠陥修正の後にプロジェクトを終了することを意味します。したがって、ここでは、テストの実行に関する詳細な分析を提供する必要があります。
見つかって修正された欠陥については、ここに記載する必要があります。このレポートには、全体的な要件の範囲が示されています。通常、チームリーダーまたはマネージャーが作成します。それに応じて、すべての終了基準を満たす必要があります。
事故報告書
フォーメーションの実行中に、ユーザーが欠陥を見つけた場合は、インシデントレポート（IR）を作成する必要があります。これは、欠陥があるため、実行を停止する必要があることを意味します。ここで、別のテストケースとしてエラー領域を再度実行する許可をクライアントに求めるために、クライアントにインシデントレポートを提出する必要があります。
これは確かにブラックマークであり、テスターには期待されていません。すべての欠陥は、ドライラン自体で見つける必要があります。それが見落とされ、正式な実行で見つかった場合、それはIRになります。
例：
モバイルテストで特定の機能を見逃した場合は、「 スクリーンセーバーの変更 「」 オプション。 次に、テストケースの実行中にロックされ、このオプションのためにそれ以上先に進むことができなくなります。次に、IRを上げて、スクリーンセーバーオプションを実行するための別のテストケースを作成します。
結論
STLC中にソフトウェアプロジェクトの利害関係者に送信されるアーティファクトは、テスト成果物と呼ばれます。この記事では、最も重要なテスト成果物を確認しました。
この記事が、ソフトウェアテストのテスト成果物について学ぶのに役立つことを願っています!!