テスト技法・工程

2024.02.09

リスクベースドテストとは？基礎知識から進め方、成功のポイント

監修：小島友美

バルテス・ホールディングス株式会社 R&C部上席研究員

あらゆるソフトウェアには、品質に関するリスクが少なからず存在します。こうしたリスクを低減するうえで、リスクベースドテストは有効なアプローチです。

今回は、リスクベースドテストとは何か、基本からわかりやすく解説します。リスクベースドテストの進め方や成功のポイントもお伝えするため、ぜひ参考にしてください。

もくじ

リスクベースドテスト(リスクベーステスト)の基礎知識
1. リスクベースドテストとは
2. リスクとは
リスクベースドテストを実施する主な目的
リスクベースドテストの大まかな進め方
リスクベースドテストを成功につなげるポイント
まとめ：高品質なリスクベースドテストを実施しよう

1．リスクベースドテスト(リスクベーステスト)の基礎知識

リスクベースドテストは、ソフトウェアに付きまとうリスクに対処するうえで有効です。まずは、リスクベースドテストの基本事項を把握しておきましょう。

1-1　リスクベースドテストとは

リスクベースドテストとは、ソフトウェアのリスクにもとづいてテストを実施するアプローチのことです。具体的には、ソフトウェアに存在するリスクを特定・分析し、それにもとづきテスト計画やテスト技法の選定、テストケースの作成などを行います。

ソフトウェアには多種多様なリスクがありますが、発生確率や発生時の影響度合いは異なります。一般的に、リスクの高いものほど優先的にテストの対応が必要です。リスクベースドテストでは、リスクに優先順位を付けることでテストの対応順序を明確にします。

なお、リスクベースドテストは「リスクベーステスト」とも呼ばれますが、本記事では「リスクベースドテスト」で統一します。

1-2　リスクとは

「リスク」という言葉はソフトウェア分野に限らず広く使われますが、意味を明確に説明できない人も多いのではないでしょうか。英語のリスク（risk）は、日本語で「危険」や「恐れ」などと訳されます。

ソフトウェア開発においては、リスクとは「発生するかもしれない、良くない事象」のことです。特にリスクベースドテストにおいては、多くの場合ソフトウェアの「バグ」や「不具合」を指します。

リスクは、「発生の可能性」と「発生時の影響度」を組み合わせて定量化できます。次のように両者を掛け合わせる計算方法が一般的です。

リスク＝ (発生の可能性)×(発生時の影響度)

ただし、手法やアプローチによっては、発生の可能性と発生時の影響度の足し算を行う場合もあります。ソフトウェアテストに関する書籍を執筆しているリック・クレイグ氏が提唱するリスク分析で採用されているのは、足し算です。どちらの計算方法でも、発生の可能性が高いものや、発生時の影響度が大きいものほどリスクが高いと判断可能です。

ポイントとして、可能性と影響度を細分化せず、3段階～5段階程度で評価します。この後に出てくるリスクマトリックスは5段階で評価しています。

2．リスクベースドテストを実施する主な目的

リスクベースドテストをなぜ実施するのか、その目的を知っておきましょう。リスクベースドテストを実施する主な目的は、次の3つです。

2-1　品質リスクの低減

リスクベースドテストは多くの場合、品質リスクを低減する目的で採用されます。品質リスクとは、ソフトウェアの品質が悪いために顧客やエンドユーザーが被害を受ける恐れのことです。

リスクベースドテストでは、上記の計算式で高いリスクとなったテストケースを優先的に実施します。つまり、バグ発生の可能性が高いテストケースや、バグの影響度が高いテストケースを早期に実施可能です。

ハイリスクな機能や要素を優先的に確認できるため品質リスクを早期に低減でき、ソフトウェアの信頼性を担保しやすくなります。

2-2　リリース判断

リスクベースドテストは、リリース判断の手段としても有効といえます。品質リスクを完全に排除することは、人的リソースや日程の問題もあり現実的には困難です。とはいえ、高い品質リスクがある状態でソフトウェアをリリースすれば、利用者が不利益を被ることになるでしょう。

リリースできるソフトウェアかどうかを判断するうえで、品質リスクの高いテストケースをパスしているかが重要な判断材料です。そこでリスクベースドテストを実施し、懸念される品質リスクを可視化します。その品質リスクに沿ってテスト設計を行うことで、リリース可否に大きな影響を及ぼすテストケースが明確になり、リリース判断の助けとなるでしょう。

2-3　テスト期間の短縮

テスト期間の短縮もリスクベースドテストを採用する目的の1つといえます。テスト対象の機能や観点などによって、リスクの大きさは変わるでしょう。ローリスクなテストケースを全てパスしても、ハイリスクなテストケースが未実施ではリリースできません。

そこで、リスクベースドテストでリスクの高低を明らかにし、ハイリスクなテストケースの優先順位を高めます。高いリスクから優先的にテストケースを実施していくことで、効率的に品質リスクの低減が可能です。結果として、リリース可能かどうかの判断が早期化し、テスト期間も短縮されるでしょう。

3．リスクベースドテストの大まかな進め方

リスクベースドテストの大まかな進め方を解説します。リスクベースドテストは、次の4ステップに沿って進めていくことが一般的です。

① テスト対象の明確化

まずはテスト対象を明確にする必要があります。テスト対象が不明確だと、重大なリスクを効率的に洗い出せません。リスクベースドテストでどのような機能やモジュールをテストするのか、対象外とすべきものはないか、などを明確にしましょう。

② リスク洗い出し

明確化したテスト対象に対して、考えられるリスクを洗い出します。たとえば「ファイルのインポート機能」の場合、対象外のファイル形式を不正にインポートしてしまう、といったリスクが考えられるでしょう。機能の性質、利用者の環境など、さまざまな観点からリスクを考えることが必要です。

③ リスクの評価・分析

洗い出したリスクに対して評価・分析を行います。具体的には「発生する可能性」と「発生時の影響度」を評価し、それらを組み合わせて各リスクの高低を分析します。リスクは、表形式の「リスクマトリックス」に落とし込むことが一般的です。

下記はリスクマトリックスのイメージですが、記載方法に特に決まりはありません。チームによって可能性や影響度の区分が変わる場合もあるでしょう。リスクの可能性や影響度に応じて、該当するセルにリスクの内容を記載していきます（下記は簡略表記としています）。

可能性＼影響度	1：無傷	3：中程度	4：重大	5：致命的
5：高	リスクA
4：高～中		リスクB
3：中
2：中～低				リスクD
1：低			リスクC

④ 優先順位付け

リスクを評価・分析した後に行うのが、各リスクの優先順位付けです。冒頭に挙げた計算式にもとづきリスクを定量化し、ハイリスクなものほど優先順位を高くすることが一般的です。優先順位の高いリスクを抱える機能やモジュールから順番に対応していきます。テストケースの作成やテストの実施などについては、通常のソフトウェアテストの手法と同様です。

4．リスクベースドテストを成功につなげるポイント

リスクベースドテストを正しく行えないと、リスクの低減につながりません。リスクベースドテストを成功につなげる3つのポイントを知っておきましょう。

4-1　リスクのレビューを実施する

リスクが発生する可能性や発生時の影響度といった評価は、テスト担当者の主観に左右されやすいといえます。評価を誤るとリスクの高低も疑わしくなるため、1人だけでの判断は危険です。そのため、チーム内でリスクの評価に対してレビューを実施しましょう。複数人の意見を反映することで客観性が高まり、リスクの評価が正確になります。

4-2　リスクを定期的に見直す

リスクの評価は変動する場合があるため、一度のレビューで評価を確定すべきではありません。たとえば、顧客の運用体制が変わり、特定のリスクに影響を受けやすくなるケースも考えられます。各リスクの可能性や影響度が変わっていないか、定期的に見直すことが望ましいです。リスクの評価に変動が生じた場合は、優先順位も見直しましょう。

4-3　テスト教育により理解を深める

リスクベースドテストに限った話ではありませんが、テスト教育を推進し、チームメンバーの理解を深めることも大切です。テスト担当者に正しい知識を浸透させることで、リスクベースドテストの品質を向上できます。また、リスクベースドテストは他のテスト技法と組み合わせることも多いため、テストに関する幅広い知識を身につけることが理想です。

バルテスでは、テストやソフトウェア品質に関してWebで学べるeラーニングを提供しています。動画とテキストを組み合わせて効率的な学習が可能です。チームのテスト教育を推進したい場合は、ぜひご利用ください。