第260回： 「ALTAのテキストをつくろう」20 （リスク軽減）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「リスクベースドテスト」のリスクアセスメントについて書きました。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「2. リスクベースドテストにおけるテストアナリストのタスク」の「2.4 リスク軽減」について書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、4の「検出されたバグ数が多い」が61%と最も多く、正解も4です。
この問題は、「リスクレベル ＝ 影響度✖可能性」の理解度を確認するものです。
まず1の「発生確率」は上記式の「可能性」を数値化したものです。
2と3の「妥当な回避策の欠如」と「賠償金など金銭的損失」は将来起こってほしくないこと（＝リスク）の大きさを示していますので「影響度」の例です。
例えば、「うるう年の2月29日に、コンビニから預金の引き出しができない」という起こってほしくないこと、すなわちリスクを想定したとします。
このときに、「コンビニからは引き出せないけれど、銀行のATMからは引き出せる」という（妥当な）回避策があるか無いかでは、リスクレベルは大きく異なります。
今回正答とした4の「検出されたバグ数が多い」はどうでしょうか。
テストで多くのバグが検出されたら確かにリリース後のバグの数は多そうです。という意味では、「（リリース後の品質が悪いというリスクの）可能性」とも言えそうです。
しかし、とても良いテストをした結果として「検出したバグ数が多い」のかもしれません。ということで、「検出されたバグ数が多い」だけの情報からリスクレベルを判断するのは危険です。
他に、妥当な選択肢がなければ、消去法で4をリスクレベルを決める要因とするしかありませんが、この問題ではもっと妥当な選択肢があるため、4を正解とします。
# リリース可否判定会議で「テストで何件バグが見つかったの？」と確認されることがあると思います。この質問は「検出したバグ数」から「リスクレベル」を想定しようとしているのですが、「テストケースの質が担保できていること」「テストで見つけたバグの内容を確認していること」とセットだったりします。
ということで、復習は以上とします。
今回のnoteのテーマは「リスク軽減」です。
≡ リスク軽減
■ シラバスに書いてあること
ALTAのシラバスに書いてあるのは「テストをすることはリスク軽減になる。以上。」です。
「この機能、○○の条件下では正しく動作しないんじゃないか？」という「将来起こる可能性がある嫌なこと（＝リスク）」を識別したら、「○○条件下」でテストしてやれば、「○○の条件下で正しく動作」するかどうかが判明するので、それは、もうリスクではなくなるということです。
正しく動作しなければ、リソースを投下してデバッグするか「それは仕様です」といって制限事項にするかを決めればよいですし、正しく動作したら「リスクではなかった」ことが分かります。
いずれにしても、テストをすることはリスク軽減になります。
なお、これは試験には出ないと思うのだけれど、リスクベーステストの方法として、「縦型探索」（depth-first）と「横型探索」（breadth-first）があるというのは、覚えておいてもいいかもしれません。
「縦型探索」は、リスクレベルの高い順番でテストをすることです。
「横型探索」は、あるリスクがないことを検証するために網羅的にテストすることです。
それで、ALTAのシラバスには「リスク軽減」の一般的な話が書いていないので、ちょっと、もやもやするのです。
■ シラバスに書いていないリスク軽減のタイプ
PMBOKのリスクのところを読むと良いと思うのですが、私がCMMIのRSK PA（リスク管理のプラクティスエリア）を学んで得た知識をまとめます。
CMMIのRSK PAは「リスクと機会の管理プラクティスエリア」といいます。不確実な未来のうち、嫌なことがリスクで、良いことが機会と前に書いたとおりです。
RSK PAでは「潜在しているリスクまたは可能性のある機会を特定し、記録し、分析して、管理する。」ことが求められています。
その心は、「嫌なことは起こらないように、良いことは継続するように、ぼーっとしていないで、主体的にリスクや機会を管理してより良い未来を引き寄せよう」ということと私は理解しています。
それで、リスク軽減ですが、軽減方法には「回避」「制御」「転嫁」「監視」「受容」があります。
「回避」は「リスクを生じさせる要因を取り除くこと」ですから、「テストを実施して欠陥を検出しデバッグする」といったことです。
「制御」は「リスク対策を取ること」ですから、「機密が漏れないように、データを暗号化する」といったことです。
「転嫁」は「リスクの所在を移転すること」ですから、「車の事故に備えて、損害補償保険に入る」といったことです。
「監視」は「リスク発生の予兆を捉え小さなうちに対処すること」ですから、「コールセンターへの問い合わせ内容を分析し問題に気づき、先手を打って対処する」といったことです。
最後の「受容」は「リスクを受け入れ、軽減策を取らない理由を明確にすること」ですから、「社内システムなのでバグがあるかもしれないけれど、導入開始する」といったことです。
受容はせざるを得ないが、影響度が大きいリスクにはコンティンジェンシープラン（不測の事態が起こった時にできる限り迅速に通常業務に復旧させその被害を最小限に留める計画）を立てます。例えば「大地震が発生した時の、対応責任者、対応の周知先、対処プロセス、合議が必要な時の合議体を計画する」といったことがコンティンジェンシープランの中身です。
ALTAのシラバスもよく読めば、「回避」「制御」「転嫁」「監視」「受容」っぽい話が書いてあるのですが、明確には書いていません。
まずはリスク軽減には、5つのタイプがあるということを知識として知っておくことが大切と思います。
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
TA-2.1.1 （K3）
特定の状況で、リスク識別に参加し、リスクアセスメントを実行し、適切なリスク軽減策を提案する 。
K3なので、「適用」です。
適用ですので、「概念または技法を正しく選択することができ、それを特定の事例に適用することができる」必要があります。
リスクベースドテストはK1でもK2でもないので、ISTQBとして重要な概念として位置付けられています。
《問題》
リスクの軽減ではないものを選びなさい。
1. テストで見つけた欠陥をデバッグした
2. コールセンターの問い合わせを分析し対策を実行した
3. 賠償金を支払った
4. 無料のツールなのでストレステストを省いた
答えは次回に書きます。
≡ おわりに
今回は、「リスク軽減」がテーマでした。
これで、ALTAシラバスの第2章はおしまいです。
第2章は短かったので、箸休め回は無しで、先に進みます。
次回は第3章の「テスト技法」のイントロダクションとなります。
この記事が気に入ったらサポートをしてみませんか？