要件トレーサビリティマトリクス（RTM）

要件トレーサビリティマトリクス（RTM）は、要件とそれをカバーするテストを結びつけ、多くの場合さらに実行結果や欠陥にまでつなげたものです。RTM は 2 つの問いにすばやく答えます。すべての要件がテストされているか、そしてこの要件が変わったらどのテストを更新する必要があるか、です。医療機器、航空、金融などの規制業界では必須であり、カバレッジを証明する必要があるあらゆる場面で役立ちます。

例

要件	説明	テストケース	ステータス	欠陥
AUTH-01	有効な認証情報でログインできる	TC-101, TC-102	合格	なし
AUTH-02	5 回失敗するとアカウントがロックされる	TC-103, TC-104, TC-105	不合格	BUG-311
AUTH-03	パスワードリセットのリンクは 30 分で失効する	（なし）	未カバー	該当なし

読み方：AUTH-03 にはテストがなく、カバレッジの抜けがあります。AUTH-02 はカバーされているものの失敗しているため、特定のバグに結びついたリリースリスクです。

順方向・逆方向・双方向

• 順方向トレーサビリティ（forward）: 要件からテストへ。すべての要件が検証されていることを証明します。
• 逆方向トレーサビリティ（backward）: テストから要件へ。誰も求めていないことを検証しているテストを明らかにします。それらは不要になったテストかもしれませんし、要件の抜けを示しているのかもしれません。
• 双方向（bidirectional）: 両方向です。ほとんどの監査人が期待するのはこれです。

RTM とコードカバレッジの違い

RTM が測るのは要件カバレッジ、つまり明示された各ニーズにテストがあるかどうかです。コードカバレッジは、テスト中にどの行や分岐が実行されたかを測ります。要件カバレッジが 100% でもコードカバレッジが低いことはありえますし、その逆もありえます。両者は異なる問いに答えるものであり、組み合わせて使うのが最も効果的です。

保守しやすく保つには

手作業で管理するスプレッドシートはすぐに古くなります。多くのチームは代わりにツールからトレーサビリティを生成しています。テスト管理ツールでテストケースにストーリー ID のタグを付けたり、自動テストに要件キーの注釈を付けたりして（たとえば Playwright のテストタイトルに @AUTH-02 のようなタグを入れる、あるいは JUnit の @Tag を使う）、レポートでそれらを結合します。マトリクスの質は、新しいテストすべてにタグを付ける規律の徹底度で決まります。