2016年7月14日

イマ旬キーワード

リスクベースドテスト

現代はより速くビジネス環境の変化に追従すること、また変化を起こすことが求められる時代です。システム開発でも開発工期を短縮することが強く求められています。今回はそのような現代のシステム開発で活用できる「リスクベースドテスト」を紹介します。

技術開発本部 課長代理 熊川 一平

「全部テストする」って本当?

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

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

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

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

リスクの考え方

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

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

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

ソフトウエアテストにおけるリスク

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

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

【図】

図1:アプリケーションのリスク評価例

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

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

関係者で合意した量のテストにする

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

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

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

【図】

図2:アプリケーションのリスク評価例(数値化)

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

更なる発展に向けて

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

著者プロフィール

【写真】

技術開発本部 課長代理 熊川 一平

大規模金融機関向けシステムにて数年間システム開発を経験。その後、現組織にてテストプロセス改善やテスト自動化の研究開発、技術支援に従事。社外講演、記事執筆なども行う。JaSST’14 Tokyo (ソフトウエアテストシンポジウム2014東京)ベストスピーカー賞受賞。

お気軽に
お問い合わせ
ください

リスクベースドテストの活用でビジネススピードを上げるに関するお問い合わせ

お問い合わせフォーム