キャッチイメージー_-_リスク

32号:わたしは、リスクベースドテストが嫌いです


≣ はじめに

「わたしは、リスクベースドテストが嫌いです」と言ったら、「じゃあ、なんでブログに書くの? 好きで楽しいことだけを書いたらいいじゃない?」と言われると思います。
まったくその通りです。ぐぅの音もでません。ただ、嫌いなくせに、「リスク」や「リスクへの対応」の話はしているので、ひょっとしたらツンデレなのかも? とも思います。
ということで、自分がどう考えているのかを書き出してまとめることで、一歩進めないかな? とそんな期待をもって書き始めています。ですから、今回のエントリーは「単なる意見(思い込み)」であって、「普遍的な何か(証明済みの真理)」ではないことを初めにお断りします。


≣ リスクベースドテストとは

『ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J03』では、「リスクベースドテスト」をテスト戦略のひとつ(分析的テスト戦略)に位置付けています。該当部分を引用します。

テスト戦略は、通常、プロダクトまたは組織のレベルでの、テストプロセスに関する汎用的な考え方を提供する。テスト戦略の一般的な種類は以下の通りである。

・ 分析的:いくつかの要因(要件やリスクなど)の分析に基づく。分析的アプローチの例としては、リスクのレベルに基づいてテストを設計し優先度付けするリスクベースドテストがある。


さらに「5.5.3 リスクベースドテストとプロダクト品質」の項で詳細な説明があります。こちらは、ちょっと長いので要約しています。(オリジナルが気になる方は、JSTQB FLシラバスの71-72ページをご一読ください。)

リスクを使用して「テストの内容・優先順位・実施順番を決めること」ができる。また、テストを「プロダクトリスクを減らし残存リスクを明らかにすることを目的とした活動」と位置付けることができる。
識別されたリスクに対して、(期待しない事象が)「発生する可能性」と「発生した場合の影響」を評価する。

(残存リスクに対して)リスクマネジメントで実施することは下記の通り。
・ リスクを分析する(定期的に再評価する)。
・ コンティンジェンシープラン(緊急対応計画)を作る。


≣ PRISMAメソッド

リスクベースドテストをこれから始めようという人は、まずは、こちらを読まれることを強くお勧めします。PRISMAメソッドは、現実的な方法ですので、リスクベースドテストに懐疑的なテストマネージャーも一度は、実プロジェクトで実施されると良い経験が得られると思います。(少なくとも私にとって良い経験でした)


≣ 湯本さんのnote

湯本さんが、リスクベースドテストについて書かれた記事です。とても良いです。



≣ リスクベースドテストが嫌いな理由

FLシラバスによる説明を読んで、リスクベースドテストのことを、「良いテスト戦略である」と思った人が多いと思います。東海大の山浦先生も、JaSST 2012 Tokyoの招待講演で「リスクベース」でテストを考えることの大切さを説いています。
また、Hetzel氏によると、ソフトウェアテストのパラダイム(パラダイムとは、常識的な考えの基盤のことをいう)には下記があり、

1. デバッグ指向(~1956年)
2. 論証指向(1957年~1978年)
3. 破壊指向(1979年~1982年)
4. 評価指向(1983年~1987年)
5. 予防指向(1988年~)

現在は予防指向パラダイム、すなわちリスクベースとのことです。

さらに、「PRISMAメソッド」として、形式知化されています!!

このように、広く受け入れられている主要なテスト戦略である「リスクベースドテスト」を私が嫌いな理由を以下に述べます。

1. リスクの評価ができない

リスクは、「起こってほしくない事象」ですから、例えば、金融システムであれば、「お客様への請求金額が間違っている」等の事象を想定することで見つけることができます。こんなに大きなリスクでなくても「文字化け」もリスクですし、「画面がチラつく」もリスクです。
FLシラバスでいう「リスクの評価」を再掲します。

リスクについては、(期待しない事象が)「発生する可能性」と「発生した場合の影響」を評価する。

下表(R-Mapと呼びます)は、経済産業省が2011年に公開した『リスクアセスメント・ハンドブック【実務編】』の10ページにあるものです。

FLシラバスがいう「発生する可能性」がこの表の「発生頻度」で、「発生した場合の影響」が「危害の程度」にあたります。リスクを評価する方法は、(乱暴に言えば、)この表のセルの文字(C, B1, B2, B3, A1, A2, A3)を読み取るということです。読み取る目的は、該当するリスクごとに、
 A: 「許容できないリスク」なので、商品化を断念する
 B: リスク対策コストを考慮しつつ最小限のリスクに低減する
 C: 「社会的に受け入れ可能なリスク」なので無視する
という管理(コントロール)を行うためです。

さて、ソフトウェアでこのR-Map手法を用いた「リスクの評価」が行えるでしょうか?
似た方法を使っているところは何度もみました(頻度×影響を、3×3のマトリクスにした評価が多かったです)が、いつも疑問で頭がいっぱいになりました。
「発生した場合の影響」の評価については、まだわかります。「ATMで1万円を振り込んだ時に3,000円しか相手に届かなかった」というリスク(起こってほしくない事象)の影響だったら「翌日、新聞の一面になるだろう。その結果として、その金融機関の株価は暴落して場合によっては倒産してしまうかもしれない」、だから、「このリスクが発生した場合の影響は重大(もしくは致命的)」と評価できそうです。
ところが、R-Map手法では「発生した場合の影響」に加えて、「発生する可能性」が分かりませんと、リスクの評価はできません。したがって、「ATMで1万円を振り込んだ時に3,000円しか相手に届かなかった」というリスクに対して、リスク評価はできません。

そもそもリスクは「未来に発生するかもしれない起こってほしくない事象」のことです。リスクの「発生する可能性」(発生頻度)が予測できるケースの方が少ないように思います。

これが、ハードウェアや自然現象(事前災害等)でしたら物理法則や化学法則から頻度を予測できることもあります。例えば、地震や台風の頻度について予測していますよね。
(毎日、天気予報でチェックしている降水確率は、「雨に降られる」というリスクに対する「発生する可能性」の予測です。)

ソフトウェアでも、ユーザープロファイリングを行って操作頻度を予測することは多少はできるかもしれません。しかし、一般に、ソフトウェアに起因するリスクの発生頻度を求めることは簡単ではありません。

≪参考≫
経済用語において「リスク」は「不確実性」を意味します。したがって、起こってほしい事象、例えば購入した株価が上がることもリスクと言います。
投資などのコンテクストにおいて「リスクを取れ」というのは「大きな不確実性に賭けないと大きなリターンは得られないよ」という意味です。
このように、経済用語としての「リスク」はプラスにもマイナスにもなる要素のことですが、リスクベースドテストをはじめ一般的には、起こってほしくない嫌なマイナスの事象(危険・危機)のみをリスクと呼びます。

さて、上述のように普通は発生頻度が分かりません。そこで、たいていは「そんなことは起こらない」と誰かが請け負って、「発生する可能性」をゼロとして、そのリスクをリスク一覧から削除します。先ほどの、「ATMで1万円を振り込んだ時に3,000円しか相手に届かなかった」ことをリスクにあげたとしても、誰かが「こんなこと、あり得ないよ、もし起こったら俺が責任取るから」と。
※ 現実は、あり得ないはずのことが発生して新聞をにぎわしています。

仕事では、「そんなことは起こらない」と請け負うと、万が一発生した時に「あんたが無いって言った!」と責任を追及されかねないので「まず起こらないよ」とか「見たことないよ」と言って、「そうだよねえ」と玉虫色の曖昧な意見表明が受け入れられ、、、以下同文です。

ところで、失敗すると人命を失ったり、数十億円が吹っ飛ぶような、例えば、「宇宙船が爆発するリスク」はだれも請け負ってくれません。

そのようなときは、しかたがないので、そのリスク事象をトップノードにしたFTAを作ります。FTAは非常に大きくなります。模造紙にも収まらず、部屋いっぱいに広がることもあります。また、そんなに大きいFTAを作っても、全ての要因を描き切ることはできません。(例えば、部品が4か所同時に故障するようなケースはFTAには描きません。場合の数が多くなりすぎるからです。例えば部品の数がわずか100個でもそこから4個の部品を選ぶ組合せ数は400万程度となります。)

小惑星探査機 はやぶさは、小惑星「イトカワ」のサンプルを採取し2010年に帰還しました。その道のりは平たんではなく、ミッションクリアまでに、幾多のトラブルに見舞われました。しかし、そんなトラブルもめげずに「こんなこともあろうかと」と「事前にプログラミングされたトラブル対処」をした結果帰還できたのです。このことは、人々の感動を呼び、映画にもなりました。
このエピソードの「こんなこと」がリスクです。「事前にプログラミングされたトラブル対処」がコンティンジェンシープラン(緊急対応計画)です。
きっと、しっかりとFTAでリスク対策していたのでしょう。

2. こんなに粗くて役に立つのか

「リスクベースドテスト」が嫌いな理由として、「リスクの評価ができない」ことを挙げました。そのことに関係するのですが、「リスクの評価ができない」というと、「もっと粗くてよいのです」という助言をいただくことがあります。その人曰く「銀行のATMだって、【振り込み】や【預け入れ】の機能と比べたら【預金の残高表示】機能はリスクが低いでしょ!?」、「だったらリスクが高い機能に重点をおいたテストをするよね? 普段当たり前にしていることを意識的にするだけですよ」と。

ハードウェアでは、欠陥が現象に影響する箇所が限定していることが期待できます。例えば、自転車のチェーンに油を指し忘れたときに、キーキーと耳障りな音がするのはチェーン周りだけです。チェーンに油を指し忘れた結果、前照灯が点かなくなるような(関係のないユニットの故障につながるような)ことは滅多にありません。車のワイパーのゴムが劣化して雨粒の吹き残しという故障が発生したとしても、ゴムの劣化という欠陥がクラクションの音に影響することはまず無いのです。
ところがソフトウェアの場合はそうはいきません。【預金の残高表示】機能の欠陥のほとんどは、【預金の残高表示】機能のバグとして現れますが、【預金の残高表示】機能の欠陥がシステムをクラッシュさせることは無きにしも非ずです。システムのクラッシュは全機能に影響しますので、【振り込み】や【預け入れ】といった高リスクの機能にも当然影響します。

ATMでは設計上、【預金の残高表示】と【振り込み】と【預け入れ】の機能が並列動作することはありませんので、クラッシュしても問題ないかもしれません。
しかし、新幹線の座席予約をする券売機はどうでしょう? 複数台並んでいる券売機は1台のコンピュータにつながっていると聞いたことがあります。ある券売機の領収書発行機能がクラッシュしたときに、別の券売機の重要な機能を巻き込みクラッシュさせるかもしれません。

以上のことから「粗い粒度でリスク分析」をしても、それほど意味がないのではないかと私は思っています。

3. 本当に低リスクなのか

「【預金の残高表示】機能は【振り込み】や【預け入れ】の機能と比べたらリスクが低い」といいます。

別の見方として、例えば、【預金の残高表示】機能で頭ゼロ処理に欠陥があって、「1,234円」を「000,001,234円」と表示するバグについて、100億円を預けている富豪が見つけて指摘したときと、残高が数万円の人が見つけて指摘したときと同じ対応となるとは思えません。リスクの高低は、「だれがそのバグを見つけてクレームを上げたか」にも左右されそうです。

また、特に日本人は「品質にうるさい」と言われています。本当に「000,001,234円」という表示は「大したことないよ」と笑って許してもらえるのでしょうか? 私にはそうは思えません。「こんなバグがあるなら他の機能も信用できない」と考える人の方が日本人には多いと思うからです。

私の経験では、海外の市販ソフトウェアに不具合を見つけて指摘してもなかなか直してもらえません。「なんで直してくれないのですか?」と聞くと、「そのバグを直したら何本売れるんだ? 直さなかったら何件クレームが増えるんだ?? 直すことが本当に売上や利益の向上につながるのか???」と言われます。
だから、海外の品質関係の本には「軽微なバグを直すことによって、サポートコストがxx百万ドル削減できた」といった話がよく載っているのですね。

このように、私には、「低リスクのバグ」が何かわかりません。「見た目の問題は低リスク」という人もいますが、「会社のロゴマークの間違えや、人名の間違え(例えば、斎藤と斉藤)」は許されるものではありません。
企業名もしかりで、「シヤチハタ」「キユーピー」「キヤノン」「エドウイン」「富士フイルム」を、「シャチハタ」「キューピー」「キャノン」「エドウィン」「富士フィルム」と表示する欠陥は高リスクです。

4. 何もしないことに対するリスクを過小評価しがち

こちらについては、「そんなことないよ」と言われる人がいらっしゃるかもしれません。私の経験上の話と思って読んでいただければと思います。

まず、リスクベースドテストで洗い出すリスクはプロダクトリスク(テスト対象の商品やサービスがリリースされた後に発生したら嫌な品質問題)だけのことが多いです。

例えば、「デプロイメントパイプラインを作ろう」といった意見に対して「今回は、これまで通りでいいんじゃない? それよりも高リスクのXXに注力しよう」といった消極的な意見が出て、先送りされることがありました。このときに、「デプロイメントパイプラインを作らない(何もしない)」ことに対するリスクについては検討されませんでした。

ひょっとしたら、マネジメントの問題かもしれませんが、「リスクベースドテスト」は「テスト戦略(テストアプローチ)」レベルで決まることですので、

リスクベースドテストを行うときには何もしないことに対するリスクについて注意する。

ことが大切なのではないか? と思っています。


≣ どうすべきか

まずは、「財産、健康、環境」を損なう事象を洗い出し、仕様・設計・コードレビューでこれについては発生しないことを確認します。というのは、これらについてはどれも発生したら企業の存続を脅かすほどの影響を持つからです。
なお、レビュー確認は完璧ではありませんのでFLシラバスがいうとおり、コンティンジェンシープラン(万が一、そのリスクが発生してしまった時の緊急対応計画)を作ります。
その他のリスクについては発生頻度や影響を同じと考えて「バグを見つけたらすべて直すこと」を基本とします。ただし、「デバッグが3日で終わらなかった場合は、対応方法について相談する」をルールとします。バグは直すだけでなく、その機能をドロップする(諦める)したり、これを使うとこういう問題がでると周知する対策もあるためです。


≣ まとめ

リスクベースドテストが嫌いな理由を知りたくて書いてきましたが、書き終わっても嫌いのままでした。第三者検証組織やテストベンダーがテスト範囲を限定する言い訳に使うもののような気がするのです。
ということで、はじめにに書いた「一歩進めないかな?」については進めませんでした。チクショー!

この記事が気に入ったらサポートをしてみませんか?