ソフトウェアテスト-ドキュメント

テストドキュメントには、ソフトウェアのテスト前またはテスト中に開発する必要のあるアーティファクトのドキュメントが含まれます。

ソフトウェアテストのドキュメントは、必要なテスト作業、テストカバレッジ、要件の追跡/トレースなどを見積もるのに役立ちます。このセクションでは、ソフトウェアテストに関連して一般的に使用されるドキュメント化されたアーティファクトのいくつかについて説明します。

テスト計画
テストシナリオ
テストケース
トレーサビリティマトリックス

テスト計画

テスト計画は、アプリケーションのテストに使用される戦略、使用されるリソース、テストが実行されるテスト環境、およびテストの制限とテストアクティビティのスケジュールの概要を示します。通常、品質保証チームリーダーは、テスト計画の作成を担当します。

テスト計画には次のものが含まれます-

テスト計画ドキュメントの概要
アプリケーションのテスト中の前提条件
アプリケーションのテストに含まれるテストケースのリスト
テストする機能のリスト
ソフトウェアのテスト中にどのようなアプローチを使用するか
テストが必要な成果物のリスト
アプリケーションのテストに割り当てられたリソース
テストプロセス中に伴うリスク
達成すべきタスクとマイルストーンのスケジュール

テストシナリオ

これは、アプリケーションのどの領域がテストされるかを通知する1行のステートメントです。テストシナリオは、すべてのプロセスフローがエンドツーエンドでテストされていることを確認するために使用されます。アプリケーションの特定の領域には、アプリケーションの規模と複雑さに応じて、わずか1つのテストシナリオから数百のシナリオが含まれる場合があります。

「テストシナリオ」と「テストケース」という用語は同じ意味で使用されますが、テストシナリオにはいくつかのステップがありますが、テストケースには1つのステップがあります。この観点から見ると、テストシナリオはテストケースですが、いくつかのテストケースとそれらを実行する順序が含まれています。これとは別に、各テストは前のテストからの出力に依存しています。

テストケース

テストケースには、テストタスクの実行中に使用できる一連の手順、条件、および入力が含まれます。このアクティビティの主な目的は、ソフトウェアがその機能やその他の側面で合格か不合格かを確認することです。テストケースには、機能、ネガティブ、エラー、論理テストケース、物理テストケース、UIテストケースなど、さまざまな種類があります。

さらに、テストケースは、ソフトウェアのテスト範囲を追跡するために作成されています。通常、テストケースの作成中に使用できる正式なテンプレートはありません。ただし、次のコンポーネントは常に利用可能であり、すべてのテストケースに含まれています-

テストケースID
製品モジュール
製品バージョン
改訂履歴
Purpose
Assumptions
Pre-conditions
Steps
期待される結果
実際の結果
Post-conditions

多くのテストケースは、単一のテストシナリオから導き出すことができます。さらに、テストスイートと総称される単一のソフトウェアに対して複数のテストケースが作成される場合があります。

トレーサビリティマトリックス

トレーサビリティマトリックス（要件トレーサビリティマトリックス-RTMとも呼ばれます）は、ソフトウェア開発ライフサイクル中に要件をトレースするために使用されるテーブルです。フォワードトレース（つまり、要件から設計またはコーディングへ）またはバックワード（つまり、コーディングから要件へ）に使用できます。RTMには多くのユーザー定義テンプレートがあります。

RTMドキュメントの各要件は、関連するテストケースにリンクされているため、前述の要件に従ってテストを実行できます。さらに、バグIDも含まれており、関連する要件とテストケースにリンクされています。このマトリックスの主な目標は次のとおりです。

ソフトウェアが上記の要件に従って開発されていることを確認してください。
バグの根本原因を見つけるのに役立ちます。
SDLCのさまざまなフェーズで開発されたドキュメントを追跡するのに役立ちます。