こんにちは、エリアマネージメント部のりきおです。
本記事では、テスト業務において検出された不具合に対して、「不具合ランク」を用いた品質分析のアプローチ方法とその活用事例についてご紹介していきます。不具合の分析作業やリスクアセスメントなどのマネジメント業務の際に少しでもご参考になれば幸いです。
準備作業
致命度・再現度の定義
まずは不具合ランクを算出するための準備として、「致命度（＝不具合発生時のシステムやステークホルダに対する影響度合）」と「再現度（本記事ではユースケースとしての遭遇しやすさ）」の2軸を設定し、「Sランク」～「Dランク」をそれぞれ定義して振り分けることで、発生した不具合がどの位置づけにあるかを識別することができます。
※今回は以下のように設定していますが、対象システムやプロジェクト規模等によってこれらの定義の基準や粒度感は異なります。
例えば、「特定の管理者アカウントが〇〇画面で✕✕操作をしたとき、アプリが落ちる」といった旨の不具合であれば、「特定の管理者アカウント（特定のユーザーかつ特定の機能）でアプリが落ちる（クラッシュ）」不具合となるため、致命度＝A・再現度＝B と判定することができます。
「優先度」との区別
インシデントレポート等で検出した不具合を報告する際の指標として「優先度」が挙げられることがあります。この優先度を「テスト項目での阻害影響（発生した不具合によってテストが実施できない影響度合い）」に設定し、致命度及び再現度と区別することによって、より明確な情報をステークホルダに提示することができます。
テストマネージャーや開発者はこれらを総合して判断して修正順位を割り当てることで、適切にテスト（リスク）をコントロールすることができる場合があります。
分析作業
致命度・再現度のランクの算出
続いて、上節で定義した致命度・再現度の各評点をもとに不具合ランクを算出します。以下の通り、Sランク～Dランクを評点 × ウェイトで振り分けて計算することで各ランクを量的に算出することができます。
ウェイト（重みづけ）について
プロジェクトの方針やテスト対象によっては、致命度と再現度のウェイト（不具合としての重み）が異なる場合があります。例えば、「ある程度の検出数は許容するが致命度の高い不具合が発生することは問題」となるケースもありますし、反対に「内容に関わらずそもそも不具合が発生すること自体が問題」となるケースもあります。こうした基準の振り幅は、ウェイトで重み付けすることで対応することができます。
不具合ランクの算出
「致命度のランク * ウェイト (1.1)」＋「再現度のランク * ウェイト (0.9)」 で求めた値を振り分けることで総合的な不具合ランクを算出します。今回は以下のように各ランクの評点範囲を設定しました。
一覧化すると以下のようになります。
準備作業で例に挙げた 致命度：A（＝4.4点）・再現度：B（＝2.7点） の不具合であれば、不具合ランクは「A（＝7.1点）」という結果になります。
インシデントレポートでの運用
インシデントレポートといった不具合が一覧で記載されたドキュメントでも、不具合ランクを導入することができます。今回はスプレッドシートに「致命度」「再現度」「評点」「不具合ランク」の4列を導入して運用する例をご紹介します。
各不具合に対して、致命度・再現度をプルダウンリストから選択すると、評点・不具合が関数で自動出力される仕組みとなっています。
関数
参考までに評点・不具合ランク列の各関数をご紹介しておきます。
・評点
=(IF(致命度のセル番号="S",5,IF(致命度のセル番号="A",4,IF(致命度のセル番号="B",3,IF(致命度のセル番号="C",2,IF(致命度のセル番号="D",1)))))*致命度のウェイトのセル番号)+(IF(再現度のセル番号="S",5,IF(再現度のセル番号="A",4,IF(再現度のセル番号="B",3,IF(再現度のセル番号="C",2,IF(再現度のセル番号="D",1)))))*再現度のウェイトのセル番号)
・不具合ランク
=IF(評点結果のセル番号=0,"",IF(評点結果のセル番号>=9,"S",IF(AND(評点結果のセル番号>=7,評点結果のセル番号<9),"A",IF(AND(評点結果のセル番号>=5,評点結果のセル番号<7),"B",IF(AND(評点結果のセル番号>=3,評点結果のセル番号<5),"C",IF(評点結果のセル番号<3,"D"))))))
不具合ランクで品質を『見える化』する
上図のように集計した不具合をグラフ化することで、「欠陥の偏在」や各機能に対する影響度合いなどを『見える化（可視化）』して測定することができ、これらは不具合や品質を分析する際に有効な情報として提供できます。
欠陥の偏在とは？
リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。
JSTQB Foundation Level シラバス – 1.3 テストの 7 原則 より
テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリ
スク分析を行う。
活用事例
アドホックテストでの活用事例
機能テストで検出された各不具合を分析し、その結果をもとにアドホックテストを行うプロジェクトがあったとします。各機能ごとの不具合数が上図の場合、純粋な検出数だけを考慮して分析すると 「機能A ＞ 機能B ＞ 機能C」 の優先度でアドホックテストを行う方針となりそうですね。
しかし、不具合ランクを導入し、かつ各機能ごとの不具合ランクが以下の状態だった場合はどうでしょう。
一概に 「機能A ＞ 機能B ＞ 機能C」 の優先度は割り付けられないのではないでしょうか。
このように、不具合ランクを定義して不具合を分析すると、これまで定義前では見えてこなかった品質を可視化することができる場合があります。
※不具合ランクは絶対的な指標ではありません。運用する際は、プロジェクトや不具合といったあらゆる状況を加味したうえで、適切な用途を心掛けましょう。
おわりに
品質分析は、対象のプロジェクトや検出された不具合の状態に応じて様々なアプローチ方法があります。今回ご紹介した不具合ランクの定義を含め、各方法や状況を適切に判断・運用し、商品やサービスに対してよりよい品質の分析・向上・担保に努めていきましょう！
