ソフトウエアテストにおいて「全てのテストを実施」が終了条件になることがあります。実施すべきテストのバリエーションは無限大なので、「全てのテスト」は「考えうる全てのテスト」や「仕様書から導出できる全ての組み合わせのテスト」と捉えるべきでしょう。「考えうる全てのテスト」とは、特定のテスト観点などに基づき、システム開発プロジェクトで定めた基準で導出されるテストのボリュームを指すと想定されます。しかし、「考えうる全てのテスト」を実施するには大量の工数が必要となり、工期が長くなってしまうため、必ずしも現代のビジネス環境に適合するとは言えません。

例えば、以下のような2つのアプリケーションがあったとします。

1. （1）1年に1回、全社員の一覧を出力するアプリケーション
2. （2）毎日、社員の働いた時間を集計し、給与を計算するアプリケーション

2つを比較すると、（2）は（1）に比べて重要なアプリケーションと感じられます。給与を計算するアプリケーションにバグがあれば大問題ですが、全社員の一覧を出力するアプリケーションは、仮にバグがあって動作しないことがあっても、年に1回しか動作しないのでその場の工夫で何とか乗り切ることが出来そうです。しかし「全てのテストを実施すること」だけを終了条件にしていては、（1）（2）のどちらのアプリケーションに対しても、大量かつ同等のテストを実施することとなり、システム開発の工期や工数を圧迫する原因になりかねません。

ところで、PMBOKにおけるリスク管理では、プロジェクトにマイナスの影響を与えるリスクに対して「回避」「転嫁」「軽減」「受容」と4つのリスク対応戦略が示されています^参考1。この考え方を先ほどの2つのアプリケーションで適用してみましょう。

1つ目のアプリケーションは、年に1回と滅多に利用しない機能なので、アプリケーションにバグがあるなどのリスクを「受容」することもできそうです。また、「転嫁」「軽減」する方向でマネジメントするのもよいかもしれません。一方、2つ目のアプリケーションは、そのリスクを「受容」するのは難しく、可能な限り「回避」し、更に出来るだけリスクが顕在化しないよう「軽減」に努め、万が一に備えてリスクが顕在化した際の損失を補償できるように「転嫁」の準備をするのがよいかもしれません。

現代のビジネスにおいて、システム開発工期は短縮化の一途をたどっており、ソフトウエアテストにおいても可能な限り効率化することが求められます。すなわち、「全てのテストを実施」といった対応だけではなく、リスク管理の考え方から学び、テスト対象のリスクに応じて効率的な対応をすべきです。例えば、可能なリスクを「受容」することや、テスト以外の方法でリスクを「転嫁」「回避」「軽減」することなどが考えられます。

前述のようにリスクに応じてテストを行うための考え方がリスクベースドテストです。リスクベースドテストでは、テスト対象のリスクの大小に応じて、テストへの力の入れ具合を決めます。リスクの評価方法としては、例えばテスト対象のバグに着目する方法があります。具体的には、「テスト対象にバグが潜在している可能性」と「テスト対象にバグがあった場合の影響」を考える手法があります。「テスト対象にバグが潜在している可能性」は、アプリケーションの製造の難しさや、複雑さを評価します。一方、「テスト対象にバグがあった場合の影響」は先ほどの例のように、アプリケーションの必要性や重要性を評価します。

この考え方に基づいて先ほどの2つのアプリケーションを評価すると、以下のようになります。

こうして整理することで、テスト対象ごとにリスクの大小を評価することができます。「リスク大」と評価された対象については、入念にテストを行い、極力バグが発生しないように努めるべきでしょう。一方、「リスク小」と評価された対象については、最低限のテストに留めても良いかもしれません。このように「リスク大」の対象は入念に多くのテストを、「リスク小」の対象は最低限必要な少なめのテストとなるようにコントロールすることで、限られた工期・工数の中でシステムの品質を高めることができます。

ですが、「リスク大」や「リスク小」といった評価では、結果がざっくりとしすぎていて、評価に応じてテストへの力の入れ具合を変えることが難しいかもしれません。また、人によっては少しでも安全に開発するために、どうしてもリスクを大きくとりたがるかもしれません。そこで、リスク評価をより詳細に、定量的に行うアプローチが有効になります。

定量的なリスクの把握のために、リスクの大きさを点数付けすることも有効です。注意したいのは、ここで言う定量化はあくまでも関係者間の合意を取るための定量化ということです。発注者や開発者、プロジェクトマネージャ等の関係者で議論し、評価対象内で相対的にリスクを評価し、皆が納得できるようにテストへの力の入れ具合を決めるのが良いでしょう。合意が取れなければ議論を行い、テスト対象のリスク順序を定めます。

リスクの大きさを点数付けする場合は、リスクを複数の要素に分割して評価することも有効です。例えば「バグがあった場合の影響」を高める要素を考え、その要素ごとに評価することが有効です。他にも「テスト対象のソフトウエアが人命にかかわるかどうか？」、「金銭の取り扱いを行うか？」、「ビジネスの収益に直結するか？」といった要素が考えられます。リスクを複数の要素に分割した場合は、各要素の評価結果の和や積をとってリスクの最終結果とします。

このようにリスクを評価すると、先ほどの2つのアプリケーションの例では下記のようなイメージになります。

この例では2つのアプリケーションしかありませんが、多くのアプリケーションや機能を内包するシステムでこうしてリスク評価をすると、各テスト対象でどの程度リスクの差があるかを明確化できます。リスク値に応じてテストのボリュームや質に変化をつけることで、受容できるリスクまでのテストに留め、より少ない工期や工数で、かつリスクを最小限に留めたシステム開発が可能になります。

当社はこうしたリスクベースドテストの手法について、リスク評価結果を重回帰分析することで、開発を繰り返しながらリスク評価の精度を上げる手法を研究開発するなど、より素早く、高品質なシステムを提供できるような取組みを継続しています^参考2。