TestRail でのトレーサビリティとテストカバレッジ

TestRailの新規ユーザーから聞かれることが多い質問の1つが「TestRailで要件をトレースするにはどうしたらいいですか?」です。もっと具体的に「TestRailはRTM(要件トレーサビリティマトリクス)をサポートしていますか?」と聞かれることもあります。

この記事では、以下を説明します。

「トレーサビリティ」とは何を意味するか

Wikipediaによれば、トレーサビリティとは、何かをトレースする能力のことです。これは、文書として記録された識別を使用してアイテムの履歴、場所、利用を検証する能力と解釈されることもあります。

ITおよびソフトウェアエンジニアリングの分野では、トレーサビリティとは通常、要件、設計、開発、テスト、保守といった開発ライフサイクルの複数のステージにわたってビジネス要件を追跡する能力を指します。

トレーサビリティを実現するには、要件/ユーザーストーリー/エピックなどの成果物から対応するテストケース/テストラン/テスト実行結果(欠陥があればその詳細も含む)へ、またその反対方向への関連付けを行います。

トレーサビリティが重要な理由/RTMの目的

要件トレーサビリティは、要求が満たされており、製品が正しく構築され、テストされたことを保証します。 

テストカバレッジを増やせば、欠陥の見逃し/QAミスを(製品が一般にリリースされる前に)減らせます。RTMは私たちテストチームがテストの計画および実行において適切なカバレッジを達成したことを検証する確実な方法になります。

またトレーサビリティは、カバレッジが不足している領域を確認するためのスナップショットを作成したり、開発ライフサイクル全体の可視化を実現することで開発を加速し、時間や労力の無駄を削減するのに役立ちます。このような見地から、要件ごとに実行、合格、失敗、中断などのステータスにあるテストの数を測定するのに役立つメトリクスとしてカバレッジの追跡を開始し、現在の開発プロジェクトの状態を簡潔に提示することができます。

さらに、トレーサビリティは関連付けられた成果物(要件、テストケースなど)が変更されたときの影響を解析する際に重要な役割を果たします。たとえば、ID R01の要件が変更された場合、文書の一貫性を保つため、関連するテストケースT01およびT02も更新する必要があります。

究極的には、トレーサビリティの目的は、テストアクティビティの計画と管理(欠陥管理を含む)を改善することです。

要件トレーサビリティマトリクス(RTM)とは何か

通常、ソフトウェアの世界で「RTM」と言えば、ワークシート—たいていはExcelのワークブックまたはGoogle Sheetsで作成されます—にプロジェクトの要件と可能なすべてのテストシナリオおよびテストケース、それらの現在のステータス(テストケースが成功したか失敗したか)を記載したものです。 

次のように、「ユーザーはE-mailまたはFacebookを使用してサインアップできること」のようなビジネス要件があり、Sprint 1に次の2つのテストケースがあるとします。

1.       T01: E-mailを使用したサインアップ

2.       T02: Facebookを使用したサインアップ

たとえば、これらのテストケースを実行し、それぞれ結果が成功と失敗だったとします。この場合、基本的なトレーサビリティドキュメントは次のようになります。

このスナップショットから、多くの情報をすばやく見て取れます。

  1. 「Facebookを使用したサインアップ」機能はSprint 1に含まれ、実行時に失敗しており、欠陥/課題IDはD1です。
  2. また、テストケースT02は要件/ユーザーストーリーR01に基づいて設計されました。

簡単なExcelまたはGoogle Sheetsファイルでトレーサビリティの追跡を始める方法

基本的なRTMドキュメントの作成はきわめて簡単です。手順は以下のとおりです。

ステップ 1: 目標を定義します(作成するトレーサビリティマトリクスに適した情報を確実に収集するため)

例: トレーサビリティマトリクスを作成し、要件が変更されたときに影響を受けるテストや課題を知りたい。

ステップ 2: すべての成果物を収集します(要件、テストケース、テスト結果、課題/バグなど)。

ステップ 3: RTMのテンプレートを作成します(成果物ごとに列を追加します)。

ステップ 4: 要件ドキュメントから要件を追加します(要件IDと説明を追加します)。

ステップ 5: テストケースドキュメントからテストケースを追加します(ステップ4の要件に対応するテストケースを追加します)。

ステップ 6: テスト結果および課題があれば追加します(ステップ5のテストケースに対応するテスト結果および関連する欠陥があれば追加します)。

ステップ 7: 適宜マトリックスを更新します(いずれかの成果物が変更された場合、必ずマトリックスを更新し、プロジェクトの現在の状態を反映します)。

次の図は、簡単なExcelまたはGoogle Spreadsheetで作成した典型的なトレーサビリティマトリクスの例です(ただし、プロジェクトの複数のイテレーションに対応するため、もっと多くの列があるのが通常です)

ExcelでのRTMの限界

Excelは使い慣れているため、RTMを簡単に作成する方法になりますが、Excelで作成したRTMを維持するのは面倒な作業です。目的どおりの結果を得るには、多大な手作業が必要になります。たとえば、

  • 要件の数が増えるにつれて、シートの列数も増えます。
  • 成果物が変更されるたびにマトリクスを手で更新しなければなりません。これは時間がかかるだけでなく、手作業によるミスが発生しやすくなります。 

マトリクスに正確な情報が反映されていない場合、マトリクスを使用してデータに基づく決定を下すことができません。

TestRailでトレーサビリティレポートを作成する方法

TestRailは[レポート]タブから利用できるさまざまなトレーサビリティ/カバレッジレポートによって要件トレーサビリティをサポートします。

これらのレポートは、要件カバレッジの概要を提供します。テストケースのバグレポートをひとめで把握したり、要件、テストケース、バグレポート間の関係を表す詳細なマトリクスを表示することもできます。

たいていのチームは要件/ユーザーストーリー/フィーチャーリクエストをJiraなどの課題トラッカー、Wiki、専用の要件管理ツールで管理しています。

TestRailでトレーサビリティレポートを作成するには、まず、そのような外部ツールの要件をTestRailのテストケースおよびテスト結果の[参照]フィールドでリンクします。

重要: 以下のレポートは、参照フィールドを使用して要件IDとリンクする必要があります。参照フィールドについての詳細はこちらで確認できます。

それでは、参照のカバレッジ、参照のサマリー、参照の比較などのレポートを使って要件/ユーザーストーリーのカバレッジを表示する方法を確認しましょう。

  • 関連付けられたテストケースがある参照はどれか、参照がある/ないテストケースはどれかを知りたい場合、参照のカバレッジレポートを選択します(特にプロジェクトのテスト計画フェーズでは)。
  • どの参照とテストケースに欠陥が関連付けられているかなどの詳細を知ることが目的であれば、参照のサマリーレポートを選択します。
  • 合格、失敗、その他のステータスにあるテストケースの数などの詳細を知りたい場合は、参照の比較レポートを選択します。

TestRailでJiraの課題(あるいはその他の要件IDのセット)に対するトレーサビリティを作成する方法

参照のカバレッジレポート

デフォルトでは、参照のカバレッジレポートには、TestRailの[参照]フィールドによってすでにリンクされている課題だけが含まれます。

任意の要件管理ツールに登録された要件のリスト全体のカバレッジをレポートするには、(要件管理ツールの)プロジェクトから課題IDのリストをエクスポートし、次の手順に従ってTestRailにリストをアップロードします。

Jiraを使用してユーザーストーリーまたは要件を追跡しているとします。まず、Jiraプロジェクトから要件のリストをCSVとしてエクスポートします。

エクスポートしたら、CSVファイルから課題IDのリストをコピーします。新しく参照のカバレッジレポートを開き、[レポート オプション]>[参照]タブで[次の参照のみ]ラジオボタンをオンにします。

課題ID(TestRailでは「参照」と呼ばれます)のリストをテキストエリアに貼り付けます。

レポートを実行します。TestRailでテストケースと関連付けられているJiraの課題がわかります。

要件をカバーするテストケースがすでに作成済みであることがわかっているが、まだTestRailのテストケースには参照IDを追加していない場合、ただちに追加を行い、レポートを再実行すると、最新のカバレッジの状態をチェックできます。まだテストケースを作成していない場合、このレポートを利用して、現在のテスト計画に不足しており、完全なカバレッジを達成するためにテストケースを追加する必要がある場所を確認できます。

参照のカバレッジレポートは、参照とテストケースの関係を表示します。また、参照がある/ないテストケースも表示します。 

たとえば、次の画面ショットを見てください。[References]列はTestRailの成果物にリンクした要件を表し、[ID]および[Title]列はそれぞれテストケースIDおよびテストケース名を表しています。IM-1の下の[References]列が空白であるのは、以下のテストケースすべてにIM-1が適用されることを意味しています。

参照のサマリーレポート

参照のサマリーレポートは、テスト中に見つかってTestRailのテスト結果に記録された欠陥のサマリーを表示します。このレポートは、テスト時に入力した欠陥IDと共に、参照とそのテストケースをカバレッジマトリクスとして表示します。

注意: 参照のサマリーレポートは、参照も指定されている場合にのみ、テストケースとそれに関連付けられた欠陥を表示します。

参照IDが指定されていないテストケースの結果に欠陥IDを入力した場合、その欠陥はレポートに表示されません。

ここで、参照とは要件を意味しており、IDおよびタイトルはテストケースIDおよびテストケース名を表しています。また、赤色はテストケースのステータスが失敗であることを表し、隣に欠陥IDが表示されています。

参照の比較レポート

参照の比較レポートは、TestRailのトレーサビリティレポートの中で一番従来のRTMに似ており、おそらく最も重要なトレーサビリティレポートです。

このレポートでは、最新のテストの状態を要件のリストと照らし合わせて比較し、テスト全体の進捗と実施中のテストに不足がないかを明らかにし、問題が発生した場合に優先順位を付けることができます。

プロジェクトのさまざまな要件に対して実行されたテストの最新のステータスを参照できるだけでなく、まだテストされていない要件があればそれを明らかにできます。これによって、より現実的にテストのカバレッジを把握し、テストを続けるか製品をリリースするかの決定に関するリスクを評価し、必要に応じてリソースを再配分してカバレッジの不足を埋めることができます。

1つのスイート/ケースリポジトリに対して複数のアクティブなラン/計画を持つことができます。このレポートは参照/要件/ケースおよびテスト結果のマトリクスを生成します。[Latest]列には最新のテスト結果がテストごとに表示されます。

ここで、参照とは要件を意味しており、IDおよびタイトルはテストケースIDおよびテストケース名を表しています。また、テスト結果とそれに対応する色がテストケースおよび参照IDごとに表示されます。

注意: 1つの要件に複数のテストケースが関連付けられている場合、表示が乱雑にならないよう、参照IDはすべての行には表示されません。たとえば、上の画面ショットでは、テストケースC3151、C3152、C3153、C3154、C3155、C3156、C3157、C3158はすべて同じ参照(課題) IM-1に関連付けられています。

結論

ExcelではなくTestRailのレポートを使用してトレーサビリティをレポートすることの主な利点は次のとおりです。

  1. TestRailでは、複数のシステムからスプレッドシートに詳細データをコピー&ペーストする必要はありません。
  2. TestRailはよりすばやくカバレッジを視覚化できます。4時間もかけてすべての要件と関連するテストケースおよび欠陥を収集してスプレッドシートを完成させる代わりに、5分もかからずレポートを生成できます。 
  3. TestRailではすばやくトレーサビリティレポートを生成できるので、プロジェクトのライフサイクル全体を通じてカバレッジを追跡したり、カバレッジが不十分な箇所を特定したり、品質の低下を防ぐアクションを取ったりするのがはるかに容易になります。
  4. 基本的なX/Yマトリックスは、テストランが1つだけの単純なユースケースにしか対応できず、その後のランに合わせてマトリクスを更新するのにかなりの作業量と時間が必要になるいっぽうで、TestRailを利用すると、複数のテストランにわたるトレーサビリティをレポートできます。
  5. TestRailはJira、Azure DevOpsの作業アイテム、GitHub Issues、GitLabをはじめとする20種類以上の要件およびバグトラッキングツールと統合可能であり、どんなツールを使っていても、自動的にトレーサビリティを提供するのを容易にします。
  6. 最後に重要なこととして、TestRailではUIからレポートをスケジュールするか、またはAPIを使用してプログラム的にレポートを生成し、PDFまたはHTMLファイルとして電子メールでメンバーとレポートを共有できるため、トレーサビリティの可視化を拡大し、単一障害点が存在する可能性を低減するのが容易になります。

(この記事は、開発元Gurock社の Blog 「Traceability and Test Coverage in TestRail」2021年3月17日の翻訳記事です。)

タイトルとURLをコピーしました