リスクベースドテストの正体

Bugs Life

» 2021/12/20

事後報告ですが、ソフトウェアテストシンポジウム 2021 九州(JaSST'21 Kyusyu)に、自社の有志によるコミュニケーションにかんする研究発表として、ライトニングトーク形式でお話してきました。
キックオフのプロセスモデルを考えてみた、というものですが、後日資料が公開される予定ですのでその際は一度見てもらえればうれしく思います。

さて、今回のコラムもアドベントカレンダーとのコラボになります。
ベリサーブ Advent Calendar 2021 と併せて楽しんでいただければと思います。

リスクベースドテストの現状

今回のタイトルにある『リスクベースドテスト』。テストにたずさわる者であれば今や一般的に使われるようになってきたワードだと思います。自社でも他チームのテストのアプローチなどを聞いた際にもよく出てきます。

ただ何となくですが・・・「言っておけばいいや」的な風にも聞こえるんですよね。

なぜそう思うかですが、ワードはよく出てくるのですが、その後の深い話があまり出てこない。リスクを考慮していれば『リスクベースドテスト』と名乗って良い、みたいな浅いものを感じてしまっているわけです。事実、私も今ほどテストを知らない頃(今もたいしたことはないですが)、テスト計画には盛り込んだものの、いまいちピンと来ていませんでした。

リスクベースドテストの定義を迷わせるもの

自分がリスクベースドテストにモヤモヤしたものを感じていたのは、そのワードの定義です。
ISTQBの用語集ではこうなっています。

リスクベースドテスト（risk-based testing）
対応するリスクのタイプとリスクのレベルに基づき、テストの活動とリソースの利用をマネジメントし、選択し、優先順位付けするテスト。

マネジメントし、選択し、優先順位を付ける・・・これはテストなのか？
設計でも実行でもなく、優先順位を付けることがバグを減らすことに結びつかなかった、ということです。

ここでJSTQBのシラバスをAdvanced Level テストアナリストに拡げて読んでみます。
リスクベースドテストのタスクは以下のものと定義されています。

• リスク識別：リスクを発見し、認識し、記述する
• リスクアセスメント：リスクを検証し、リスクレベルを決定するプロセス
• リスク軽減：リスクを減らすために判定したり対策する

リスク識別で「リスクを発見し...」と、ここでようやくテストらしいワードが出てきます。
ただ、リスク識別を読み進めると、リスクを検出するためにステークホルダと連携する、となっており、テストというよりはレビューに近いアプローチであることが見えてきます。

また、リスク軽減では「対策する」と書かれているのでそれは設計なのでは？と思ってしまいますが、読み進めるとそうではなく、開発ドキュメントのレビュー参加、リスク軽減活動を特別なテスト技法(?)を使って実装する、などといったテスト活動としての対策が定義されています。

さらに、リスクの軽減の中ではテストの優先度付けにかんして「縦型探索(depth-first)」と「横型探索(breadth-first)」というワードが出てきます。

• 縦型探索：高リスクの順にテストを進めていく
• 横型探索：リスクに重みを付けつつ、全てのリスクをカバーするように進める

このような考え方は自分の中になかったので感心した記憶がありますが、でもやはりこれはテストというよりプロセスではないか？、という印象を持ちました。

総じてリスクベースドテストという定義は、レビューであり、プロセスであり、意思決定である、非常に広義なものである、ということはわかりました。
しかし、ここにはやはりテストがないように思えたところに、私のモヤモヤの正体がありました。

モヤモヤの正体～リスクベースドテストの正体

つまり、私にとってのリスクベースドテストという解釈は、"テストによってリスクを検出する" ことだったようです。これは難しいことを書いているわけではなく、探索テストや異常系のテストと称してテスターが日常やっているようなことです。例えば『システムの起動中に電源タップからコンセントを抜く』といったテストの内容です。しかし、これはリスクベースドテストの定義の中ではリスク対策の立証の一つでしかありませんでした。

結論、リスクベースドテストというのは、こうした「システムの起動中に電源タップからコンセントを抜いたらどうなる？」といったパターンを考える(分析する)ところから始め、有識者によるレビューによって影響を決め、最後に実際のテストによってそのリスクパターンの対策に問題がないことを立証する、という一連のテスト実行を含めたプロセスである、と今は私は理解しています(・・・間違っていたらご教授ください)。

テスト技法などで出てくるペアワイズテストやデシジョンテーブルテストといった名称が意味するテストより、リスクベースドテストの範囲が広すぎることがモヤモヤの正体であり、であるからして、それが正しくテストエンジニアに理解されているのかは気になるところではあります。

それではこの辺で。また2022年にお会いしましょう。