リスクベーステストを考える

リスクベーステストとは、リスクの大きい部分を重点的にテストする方法です。

　リスク＝影響×発生確率

ですので、予想される被害が最も少なくなるようなテスト技法と言えるかもしれません。

しかし、合理的なテスト方法ではあるものの、本来すべき必要最低限のテストを行わずにテストを手抜きすることにつながってしまう可能性も感じてしまいます。

昨日、SEA関西の勉強会で「セーフウェア」を輪講していて、その答えを見つけたような気がしました。この本の中では、一般的なソフトウェア工学の言葉の定義でもある

　エラー(error): 欠陥の元になる間違い
　欠陥(fault)  : プログラムの誤り(原因)
　障害(failure): 欠陥によって生じた正常でない動作・状態(結果)

　　　　*引用ではなく、分かりやすい表現にしています。異なる和訳もあります。

が説明されています。そして、リスクとはハザードと事故との関係と定義されており、

　ハザードレベル：ハザードの過酷度、ハザードの起こりやすさ
　ハザードの暴露：ハザードにさらされること(あるいは継続時間)
　ハザードが事故に至る可能性

の3つがあげられ、広い意味でリスクが使われていました。ハザードとは

「事故をもたらしうるシステムの状態または一定の条件」

なので、ハザードレベルとは原因(fault)のリスク、事故に至る可能性とは結果(failure)のリスク(の確率)といえると思います。このように、リスクに関してもfaultとfailureに分けて考えられるのだと思いました。

そこで、最初の議論に戻って考えると、

・リスクベーステストのリスクとはfailureのリスク
・必要最低限のテストの目的はfaultの軽減

ではないかと思いました。つまり、リスクベーステストはリリース後に起こりうる被害を最小限にする方法であり、failureの影響度と発生確率で語られるべきものである。最低限のテストを考えるならfaultをベースに考えるべきで、品質は規模あたりのfaultで語られるべきではないかと思いました。人間は一定の比率でエラーを起こすと考えられるので、エラーによって生じるfaultを管理することで、最低限の品質が確保できると考えられるからです。

ここで、現場の品質がfailureで管理されていることが気になりました。テスト項目が不合格と言うのは一般にfailureあり、その規模あたりの比率と人間の発生するエラー確率とは必ずしも比例しないと思います。同一のfaultによるものは束ねて、複数のfaultによるものは分けて、規模あたりのfaultの比率で管理すべきかもしれません。

これまでのテストは、faultに基づくべき最低限の品質とfailureに基づく被害を考慮した品質をまぜて考えていたので、結果的に実用的な品質が確保されてうまく行っていたのでしょう。しかし、リスクベーステストを導入するのであれば、効率化と最低限の品質の維持を両立するために、他のテストはfaultベースで管理した方が良いかもしれません。

高品質であれば、fault数≒failure数になるような気もしますので、要らぬ心配かもしれませんが、、、