how create requirements traceability matrix
ソフトウェアテストにおける要件トレーサビリティマトリックス(RTM)とは:例とサンプルテンプレートを使用してトレーサビリティマトリックスを作成するためのステップバイステップガイド
今日のチュートリアルは、重要なQCツールについてです。これは、過度に単純化されている(見落とされている)か、過度に強調されています。 トレーサビリティマトリックス(TM)。
ほとんどの場合、トレーサビリティマトリックスの作成、レビュー、または共有は、主要なQAプロセスの成果物の1つではないため、主に集中しておらず、強調不足を引き起こしています。それどころか、一部のクライアントは、TMが(テスト中の)製品に関する驚異的な側面を明らかにすることを期待しており、失望しています。
「正しく使用すれば、トレーサビリティマトリックスはQAの旅のGPSになります」。
での一般診療です STH 、この記事では、TMの「内容」と「方法」の側面について説明します。
学習内容:
要件トレーサビリティマトリックスとは何ですか?
要件トレーサビリティマトリックスまたはRTMでは、クライアントによって提案されたユーザー要件と構築中のシステムとの間のリンクを文書化するプロセスを設定します。つまり、テストケースを使用してユーザー要件をマッピングおよびトレースし、すべての要件に対して適切なレベルのテストが達成されていることを確認するための高レベルのドキュメントです。
要件に対して定義されているすべてのテストケースを確認するプロセスは、トレーサビリティと呼ばれます。トレーサビリティにより、テストプロセス中に最も多くの欠陥を生み出した要件を特定できます。
テストエンゲージメントの焦点は、最大のテストカバレッジです。カバレッジとは、テストする必要があるすべてのものをテストする必要があることを意味します。テストプロジェクトの目的は、100%のテストカバレッジである必要があります。
要件トレーサビリティマトリックスは、カバレッジの側面を確実にチェックする方法を確立します。カバレッジギャップを特定するためのスナップショットの作成に役立ちます。つまり、要件ごとに実行、合格、失敗、ブロックなどのテストケースの数を決定するメトリックとも呼ばれます。
要件のトレーサビリティが必要なのはなぜですか?
要件トレーサビリティマトリックスは、要件をリンクするのに役立ちます。 テストケース 、および正確に欠陥。アプリケーション全体は、要件のトレーサビリティ( エンドツーエンドのテスト アプリケーションの達成)。
C#インタビューの質問を含むセレン
要件トレーサビリティは、すべての機能がテストされるため、アプリケーションの優れた「品質」を保証します。 品質管理 ソフトウェアが予期しないシナリオでテストされ、欠陥が最小限に抑えられ、すべての機能要件と非機能要件が満たされているため、達成できます。
要件トレーサビリティマトリックスは、ソフトウェアアプリケーションが規定の期間内にテストされるのを支援し、プロジェクトの範囲が適切に決定され、その実装が顧客の要件とニーズに従って達成され、プロジェクトのコストが適切に管理されます。
アプリケーション全体がその要件についてテストされるため、欠陥の漏れが防止されます。
トレーサビリティマトリックスの種類
フォワードトレーサビリティ
テストケースへの「フォワードトレーサビリティ」要件。これにより、プロジェクトが目的の方向に従って進行し、すべての要件が徹底的にテストされます。
後方トレーサビリティ
テストケースは、「後方トレーサビリティ」の要件にマッピングされています。その主な目的は、開発中の現在の製品が正しい軌道に乗っていることを確認することです。また、不特定の機能が追加されていないため、プロジェクトの範囲が影響を受けていないことを確認するのにも役立ちます。
双方向のトレーサビリティ
(前方+後方): 優れたトレーサビリティマトリックスには、テストケースから要件への参照、およびその逆(テストケースへの要件)があります。これは「双方向」トレーサビリティと呼ばれます。これにより、すべてのテストケースを要件まで追跡でき、指定されたすべての要件に正確で有効なテストケースが含まれるようになります。
RTMの例
#1)ビジネス要件
BR1 :メールを書くオプションが利用可能である必要があります。
BR1のテストシナリオ(技術仕様)
TS1 :メールの作成オプションが提供されています。
テストケース:
テストケース1 (TS1.TC1) :メールの作成オプションが有効になっていて、正常に機能します。
テストケース2 (TS1.TC2) :メールの作成オプションが無効になっています。
#2)欠陥
テストケースを実行した後、欠陥が見つかった場合は、それもリストして、ビジネス要件、テストシナリオ、およびテストケースにマッピングできます。
例えば、 TS1.TC1が失敗した場合、つまり有効になっているのにメールを作成するオプションが正しく機能しない場合は、欠陥をログに記録できます。自動生成または手動で割り当てられた欠陥ID番号がD01であるとすると、これはBR1、TS1、およびTS1.TC1番号でマッピングできます。
したがって、すべての要件を表形式で表すことができます。
ビジネス要件# | テストシナリオ# | テストケース # | 欠陥# |
---|---|---|---|
BR1 | TS1 | TS1.TC1 TS1.TC2 | D01 |
BR2 | TS2 | TS2.TC1 TS2、TC2 TS2.TC3 | D02 D03 |
BR3 | TS3 | TS1.TC1 TS2.TC1 TS3.TC1 TS3.TC2 | NIL |
テストカバレッジと要件のトレーサビリティ
テストカバレッジとは何ですか?
テストカバレッジは、テストフェーズの開始時に顧客のどの要件を検証するかを示します。テストカバレッジは、最小限の欠陥またはNILの欠陥が報告されるように、ソフトウェアアプリケーションを完全にテストするために、テストケースが作成および実行されるかどうかを決定する用語です。
テストカバレッジを達成する方法は?
最大のテストカバレッジは、優れた「要件のトレーサビリティ」を確立することで達成できます。
- 設計されたテストケースへのすべての内部欠陥のマッピング
- 将来の回帰テストスイートのために、すべての顧客報告欠陥(CRD)を個々のテストケースにマッピングする
要件仕様の種類
#1)ビジネス要件
実際の顧客の要件は、次のようなドキュメントに記載されています。 ビジネス要件ドキュメント(BRS) 。このBRSは、クライアントとの簡単なやり取りの後、詳細に導き出された高レベルの要件リストです。
通常、「ビジネスアナリスト」またはプロジェクト「アーキテクト」によって作成されます(組織またはプロジェクトの構造によって異なります)。 「ソフトウェア要件仕様」(SRS)ドキュメントは、BRSから派生しています。
#2)ソフトウェア要件仕様書(SRS)
これは、すべての機能要件と非機能要件のすべての詳細を含む詳細なドキュメントです。このSRSは、ソフトウェアアプリケーションを設計および開発するためのベースラインです。
#3)プロジェクト要件文書(PRD)
PRDは、プロジェクト内のすべてのチームメンバーが、製品が何をすべきかを正確に伝えるためのリファレンスドキュメントです。これは、製品の目的、製品の機能、リリース基準、プロジェクトの予算とスケジュールなどのセクションに分けることができます。
#4)ユースケースドキュメント
これは、ビジネスニーズに応じたソフトウェアの設計と実装に役立つドキュメントです。これは、アクターとイベントの間の相互作用を、目標を達成するために実行する必要のある役割でマップします。これは、タスクを実行する必要がある方法の詳細なステップバイステップの説明です。
例えば、
俳優: お客様
役割: ゲームをダウンロードする
ゲームのダウンロードは成功しました。
ユースケースは、組織の作業プロセスに従って、SRSドキュメントに含まれる部分である場合もあります。
#5)欠陥検証文書
欠陥に関連するすべての詳細を含む文書化されています。チームは、欠陥を修正および再テストするための「欠陥検証」ドキュメントを維持できます。テスターは、欠陥が修正されているかどうかを検証したり、さまざまなOS、デバイス、さまざまなシステム構成などで欠陥を再テストしたりするときに、「欠陥検証」ドキュメントを参照できます。
「欠陥検証」ドキュメントは、専用の欠陥修正および検証フェーズがある場合に便利で重要です。
#6)ユーザーストーリー
ユーザーストーリーは、主に「アジャイル」開発で使用され、エンドユーザーの観点からソフトウェア機能を説明します。ユーザーストーリーは、ユーザーのタイプと、特定の機能が必要な方法と理由を定義します。ユーザーストーリーを作成することで、要件が簡素化されます。
現在、すべてのソフトウェア業界は、要件を記録するためのユーザーストーリーとアジャイル開発および対応するソフトウェアツールの使用に向かっています。
要件収集の課題
#1) 収集される要件は、詳細で、明確で、正確で、適切に指定されている必要があります。しかし〜がある しない 要件収集に必要なこれらの詳細、明確さ、正確性、および明確に定義された仕様を計算するための適切な手段。
最高の無料のウイルスとマルウェアの除去
#二) 要件情報を提供する「ビジネスアナリスト」または「プロダクトオーナー」の解釈は重要です。同様に、情報を受け取るチームは、利害関係者の期待を理解するために適切な説明を行う必要があります。
理解は、ビジネスニーズとアプリケーションの実装に必要な実際の取り組みの両方と同期している必要があります。
#3) 情報は、エンドユーザーの観点からも導き出される必要があります。
#4) 利害関係者は、さまざまな時点で要件が矛盾または矛盾していると述べています。
#5) エンドユーザーの視点は複数の理由で考慮されておらず、さらなる利害関係者は、製品に何が必要かを「完全に」理解していると考えていますが、通常はそうではありません。
#6) 開発されたアプリケーションのスキルが不足しているリソース。
# 7) アプリケーションの頻繁な「スコープ」変更またはモジュールの優先順位の変更。
#8) 欠落している、暗黙の、または文書化されていない要件。
#9) 顧客によって決定された一貫性のない、または曖昧な要件。
#10) 上記のすべての要因の結論は、プロジェクトの「成功」または「失敗」は要件に大きく依存するということです。
要件のトレーサビリティがどのように役立つか
#1)要件はどこに実装されていますか?
例えば、
要件: メールアプリケーションに「メールの作成」機能を実装します。
実装: メインページのどこに「メールを作成」ボタンを配置してアクセスする必要があります。
#2)要件は必要ですか?
例えば、
要件: 特定のユーザーのみにメールアプリケーションで「メールの作成」機能を実装します。
実装: ユーザーのアクセス権に従って、メールの受信トレイが「読み取り専用」の場合、この場合は「メールの作成」ボタンは必要ありません。
#3)要件をどのように解釈しますか?
例えば、
要件: フォントと添付ファイルを使用したメールアプリケーションの「メールの作成」機能。
実装: [メールを作成]をクリックすると、どのような機能を提供する必要がありますか?
- メールを作成したり、さまざまなフォントタイプで編集したり、太字、斜体、下線を付けたりするためのテキスト本文
- 添付ファイルの種類(画像、ドキュメント、その他の電子メールなど)
- 添付ファイルのサイズ(最大許容サイズ)
したがって、要件はサブ要件に分類されます。
#4)要件の実装に影響を与える設計上の決定は何ですか?
例えば、
要件: 「受信トレイ」、「送信済みメール」、「下書き」、「スパム」、「ゴミ箱」などのすべての要素がはっきりと表示されている必要があります。
実装: 表示する要素は、「ツリー」形式または「タブ」形式で表示する必要があります。
#5)すべての要件が割り当てられていますか?
例えば、
要件: 「ゴミ箱」メールオプションが提供されています。
実装: 「ゴミ箱」メールオプションが提供されている場合は、「削除」メールオプション(要件)を最初に実装する必要があり、正確に機能している必要があります。 「削除」メールオプションが正しく機能している場合、削除されたメールのみが「ゴミ箱」に収集され、「ゴミ箱」メールオプション(要件)を実装することは理にかなっています(便利です)。
RTMとテストカバレッジの利点
#1) 開発およびテストされたビルドには、「顧客」/「ユーザー」のニーズと期待に応える必要な機能があります。顧客は自分が欲しいものを手に入れなければなりません。期待どおりに動作しないアプリケーションで顧客を驚かせることは、誰にとっても満足のいく体験ではありません。
#二) 開発されて顧客に提供される最終製品(ソフトウェアアプリケーション)には、必要かつ期待される機能のみが含まれている必要があります。ソフトウェアアプリケーションで提供される追加機能は、それを開発するための時間、お金、および労力のオーバーヘッドが発生するまで、最初は魅力的に見えるかもしれません。
追加機能も欠陥の原因となる可能性があり、インストール後にお客様に問題を引き起こす可能性があります。
#3) 開発者の最初のタスクは、顧客の要件に従って優先度の高い要件の実装に最初に取り組むときに明確に定義されます。お客様の優先度の高い要件が明確に指定されている場合、それらのコードコンポーネントを最優先で開発および実装できます。
したがって、最終製品が顧客に出荷される可能性は、最上位の要件に従っており、スケジュールどおりであることが保証されます。
#4) テスターは、最初に開発者によって実装された最も重要な機能を検証します。優先ソフトウェアコンポーネントの検証(テスト)が最初に行われるため、システムの最初のバージョンをリリースする準備ができているかどうかを判断するのに役立ちます。
#5) 正確なテスト計画、テストケースが作成および実行され、すべてのアプリケーション要件が正しく実装されていることを確認します。要件にマッピングされたテストケースは、大きな欠陥を見逃さないようにするのに役立ちます。さらに、顧客の期待どおりに高品質の製品を実装するのに役立ちます。
#6) クライアントからの「変更要求」がある場合、変更要求の影響を受けるすべてのアプリケーションコンポーネントが変更され、見落とされることはありません。これにより、変更要求がソフトウェアアプリケーションに与える影響の評価がさらに強化されます。
# 7) 一見単純な変更要求は、アプリケーションのいくつかの部分に対して実行する必要のある変更を伴う場合があります。変更を行うことに同意する前に、どれだけの労力が必要になるかについて結論を出すことをお勧めします。
テストカバレッジの課題
#1)良好なコミュニケーションチャネル
によって提案された変更がある場合 利害関係者 、同じことが開発の初期段階で開発チームとテストチームに伝達される必要があります。これなしで 定刻 アプリケーションの開発、テスト、および欠陥のキャプチャ/修正は保証できません。
#2)テストシナリオの優先順位付けは重要です
優先度が高く、複雑で、重要なテストシナリオを特定することは困難な作業です。すべてをテストしようとしています テストシナリオ ほとんど達成不可能な作業です。シナリオをテストする目的は、ビジネスとエンドユーザーの観点から非常に明確である必要があります。
#3)プロセスの実装
テストプロセスは、技術インフラストラクチャと実装、チームスキル、過去の経験、組織構造と従ったプロセス、コスト、時間とリソースに関連するプロジェクトの見積もり、タイムゾーンごとのチームの場所などの要素を考慮して明確に定義する必要があります。
上記の要因を考慮した統一されたプロセスの実装により、プロジェクトに関係するすべての個人が同じページにいることが保証されます。これは、アプリケーション開発に関連するすべてのプロセスのスムーズな流れに役立ちます。
#4)リソースの可用性
リソースには、熟練したドメイン固有のテスターと、テスターが使用するテストツールの2種類があります。テスターがドメインについて適切な知識を持っている場合、効果的なテストシナリオとスクリプトを作成して実装できます。これらのシナリオとスクリプトを実装するには、テスターは適切な「テストツール」を十分に備えている必要があります。
熟練したテスターと適切なテストツールだけで、アプリケーションを適切に実装し、時間どおりに顧客に提供できます。
#5)効果的なテスト戦略の実装
' テスト戦略自体は、大きくて別の議論のトピックです。しかし、ここでは「テストカバレッジ」について、効果的なテスト戦略の実装により、 品質' アプリケーションの 良い そしてそれは 維持 どこでも一定期間にわたって。
効果的な「テスト戦略」は、あらゆる種類の重要な課題を事前に計画する上で主要な役割を果たし、より優れたアプリケーションの開発にさらに役立ちます。
要件トレーサビリティマトリックスを作成する方法
一緒にいるためには、追跡または追跡する必要があるのは何かを正確に知る必要があります。
テスターは、テストシナリオ/目的を書き始め、最終的にはいくつかの入力ドキュメントに基づいてテストケースを作成します–ビジネス要件ドキュメント、 機能仕様書 および技術設計ドキュメント(オプション)。
以下がビジネス要件ドキュメント(BRD)であると仮定しましょう:( このサンプルBRDをExcel形式でダウンロードします )
(画像をクリックすると拡大します)
以下は、ビジネス要件ドキュメント(BRD)の解釈と、それをコンピューターアプリケーションに適合させた、機能仕様ドキュメント(FSD)です。理想的には、FSDのすべての側面がBRDで対処される必要があります。ただし、簡単にするために、ポイント1と2のみを使用しました。
上記のBRDからのサンプルFSD :( このサンプルFSDをExcel形式でダウンロードします )
注意 :BRDとFSDはQAチームによって文書化されていません。私たちは、他のプロジェクトチームと一緒にドキュメントを消費するだけです。
上記の2つの入力ドキュメントに基づいて、QAチームとして、テストするための高レベルのシナリオの以下のリストを作成しました。
上記のBRDおよびFSDのサンプルテストシナリオ:( このサンプルテストシナリオファイルをダウンロードする )
ここに到着したら、今が要件トレーサビリティマトリックスの作成を開始する良い機会です。
私は個人的に、追跡したい各ドキュメントの列を含む非常に単純なExcelシートを好みます。ビジネス要件と機能要件には一意の番号が付けられていないため、ドキュメント内のセクション番号を使用して追跡します。
(特にケースに最も適したものに応じて、行番号や箇条書き番号などに基づいて追跡することを選択できます。)
単純なトレーサビリティマトリックスがこの例をどのように探すかを次に示します。
上記のドキュメントは、BRDからFSD、そして最終的にはテストシナリオまでのトレースを確立します。このようなドキュメントを作成することで、テストスイートを作成するためにテストチームが初期要件のあらゆる側面を考慮に入れていることを確認できます。
このままにしておくことができます。ただし、読みやすくするために、セクション名を含めることをお勧めします。これにより、このドキュメントをクライアントまたは他のチームと共有する際の理解が深まります。
結果は次のとおりです。
繰り返しますが、前者の形式または後者の形式を使用するかどうかはあなた次第です。
これはTMの暫定バージョンですが、通常、ここで停止してもその目的は果たされません。 欠陥まで外挿すると、最大のメリットを得ることができます。
方法を見てみましょう。
思いついたテストシナリオごとに、少なくとも1つ以上のテストケースが必要になります。したがって、そこに着いたら別の列を含めて、以下に示すようにテストケースIDを記述します。
この段階で、トレーサビリティマトリックスを使用してギャップを見つけることができます。 例えば、 上記のトレーサビリティマトリックスでは、FSDセクション1.2用に作成されたテストケースがないことがわかります。
原則として、トレーサビリティマトリックスの空きスペースは調査の対象となる可能性があります。 したがって、このようなギャップは、次の2つのいずれかを意味する可能性があります。
- テストチームは、「既存のユーザー」機能を考慮して、どういうわけか見落としています。
- 「既存のユーザー」機能は、後で延期されるか、アプリケーションの機能要件から削除されました。この場合、TMはFSDまたはBRDに不整合を示します。これは、FSDおよび/またはBRDドキュメントの更新を実行する必要があることを意味します。
シナリオ1の場合は、100%のカバレッジを確保するために、テストチームがさらに作業する必要がある場所を示します。
シナリオ2では、TMはギャップを表示するだけでなく、すぐに修正が必要な誤ったドキュメントを示しています。
TMを拡張して、テストケースの実行ステータスと欠陥を含めましょう。
以下のバージョンのトレーサビリティマトリックスは、通常、テストの実行中または実行後に作成されます。
要件トレーサビリティマトリックステンプレートのダウンロード:
=> Excel形式のトレーサビリティマトリックステンプレート
注意すべき重要なポイント
このバージョンのトレーサビリティマトリックスについて注意すべき重要な点は次のとおりです。
#1) 実行状況も表示されます。実行中に、作業の進行状況の統合されたスナップショットが提供されます。
#2)欠陥: この列を使用して後方トレーサビリティを確立すると、「新規ユーザー」機能に最も欠陥があることがわかります。 TMは、テストケースが失敗したことを報告する代わりに、ほとんどの欠陥があるビジネス要件に透明性を提供し、クライアントが望むものの観点から品質を示します。
#3) さらなるステップとして、欠陥IDを色分けして状態を表すことができます。 例えば、 赤の欠陥IDはまだ開いていることを意味し、緑の欠陥IDは閉じていることを意味します。これが行われると、TMは、特定のBRDまたはFSD機能が開いているか閉じているかに対応する欠陥のステータスを表示するヘルスチェックレポートとして機能します。
#4) 技術設計ドキュメント、ユースケース、または追跡したいその他の成果物がある場合は、列を追加することで、必要に応じて上記で作成したドキュメントをいつでも拡張できます。
要約すると、RTMは次のことに役立ちます。
- 100%のテストカバレッジの確保
- 要件/ドキュメントの不整合を表示する
- ビジネス要件に焦点を当てて、全体的な欠陥/実行ステータスを表示します。
- 特定のビジネス要件や機能要件が変更された場合、TMは、テストケースの再検討/再作業の観点から、QAチームの作業への影響を推定または分析するのに役立ちます。
さらに、
- トレーサビリティマトリックスは手動テスト固有のツールではなく、自動化プロジェクトにも使用できます。自動化プロジェクトの場合、テストケースIDは自動化テストスクリプト名を示すことができます。
- また、QAだけで使用できるツールでもありません。開発チームはこれを使用して、BRD / FSD要件を作成されたコードのブロック/ユニット/条件にマッピングし、すべての要件が確実に開発されるようにすることができます。
- のようなテスト管理ツール HP ALM トレーサビリティ機能が組み込まれています。
注意すべき重要な点は、トレーサビリティマトリックスを維持および更新する方法によって、その使用の有効性が決まります。頻繁に更新されないか、誤って更新されると、ツールは助けになるのではなく負担になり、ツール自体は使用する価値がないという印象を与えます。
結論
要件トレーサビリティマトリックスは、 マップとトレース テストケースと発見された欠陥に関するクライアントのすべての要件。それは 単一のドキュメント これは、テストケースを見逃さないという主な目的を果たし、アプリケーションのすべての機能がカバーされ、テストされます。
事前に計画された適切な「テストカバレッジ」により、テストフェーズでの繰り返しのタスクや欠陥のリークを防ぎます。欠陥数が多いということは、テストが適切に行われているため、アプリケーションの「品質」が向上していることを示しています。同様に、欠陥数が非常に少ないということは、テストが基準まで行われていないことを示しており、これがアプリケーションの「品質」を否定的に妨げています。
Windows7用の無料ファイアウォール保護
テストカバレッジが徹底的に行われている場合、欠陥数が少ないことは正当化でき、この欠陥数は主要な統計ではなく、サポート統計と見なすことができます。アプリケーションの品質は、テストカバレッジが最大化され、欠陥数が最小化された場合に「良好」または「満足」と呼ばれます。
著者について: STHチームメンバーのUrmilaP。は、経験豊富なQAプロフェッショナルです。 高品質 テストと問題追跡スキル。
プロジェクトで要件トレーサビリティマトリックスを作成しましたか?この記事で作成したものとどの程度似ていますか、または異なりますか?コメントを通じて、この記事に関するあなたの経験、コメント、考え、フィードバックを共有してください。