リスクベーステスト（Risk-Based Testing）

リスクベーステストは、すべてをテストすることは決してできないという前提に立ち、どこに時間を使うかをリスクに基づいて決める手法です。各機能や領域について、故障の発生可能性（複雑さ、変更量、過去の欠陥、新しい技術）と、故障した場合の影響度（金銭、安全、データ、法的リスク、影響を受けるユーザー数）を採点します。高リスクの領域にはより早く、より深く、より多様なテストを行い、低リスクの領域は軽めのチェックで済ませます。

例

あるリリースが 4 つの領域に影響するとします。それぞれを 1～5 で採点します。

領域	発生可能性	影響度	リスク（L x I）	テストの深さ
決済プロバイダーの移行	5	5	25	機能、ネガティブ、結合、性能、探索的テストをフルで実施
一部地域の新しい税ルール	4	4	16	境界値とデシジョンテーブルのテスト、合計金額の回帰テスト
プロフィールページの刷新	3	2	6	主要フローと見た目の確認
フッターのリンク更新	1	1	1	簡単な確認

締め切りが 2 日短縮されたとしても、何を削るべきかはすでにわかっています。削るのは低リスクの行のテストの深さであり、決済の移行ではありません。

なぜ重要なのか

どのテスト計画にもトレードオフがあります。リスクベーステストは、そのトレードオフを明示し、合意されたものにします。また、状況を報告するための明確な方法も得られます。「高リスクの領域はすべてテスト済み、中リスクの 2 つは一部テスト済み、既知の抜けはこれらです」という報告は、「テストケースの 83% を実行済み」よりもリリース判断にはるかに役立ちます。

よくある間違い

• 1 人で採点する。 影響度を知っているのはプロダクトオーナー、発生可能性を知っているのは開発者です。リスクはチームで一緒に採点しましょう。
• 一度しか採点しない。 コードが取り込まれバグが見つかるにつれて、リスクは変化します。欠陥を出し続けるモジュールは順位を上げるべきです。
• 低リスクの領域を完全に無視する。 リスクが低いとはテストを軽くするという意味であり、ゼロにするという意味ではありません。この基本部分は通常、自動回帰テストでカバーします。
• バグの重大度と混同する。 重大度はすでに見つかった欠陥を評価するものです。リスクはテスト前に行う見積もりであり、どこを調べるかを決めるために使います。