テストを実施した後は、テスト結果を分析評価しなければいけません。
不具合が検出されるとプログラムを改修しますが、モグラたたき的な対処を行なっても、システム品質は向上しません。
不具合の原因分析を怠ってしまうと、他のプログラムにも似たような不具合が存在していたとしても、見逃されてしまう可能性があります。
プログラムには多くの条件分岐が含まれているため、すべての条件を網羅したテスト項目を用意するというのは現実的ではありません。
例えば、一つのプログラムに選択値が3つある条件分岐が10か所ある場合、 3×3×3×3×3×3×3×3×3×3＝59049 もの組合せが考えられます。
一つのシステムが100本のプログラムで構成されているとすると、単純計算で590万という膨大な組合せになってしまいます。そこで、テスト作業としては代表的な組合せを選定して実行せざるを得ないということになります。
その際の一つの品質向上策として、あるテスト項目で不具合が検出された場合、その不具合の発生原因と同じ要因が他のプログラムにも存在していないかを水平展開という形 で確認することで、潜在的な不具合を顕在化させます。
そのためにも、不具合が検出された時には詳細な分析を行なって発生原因を特定化する必要があります。特に複数件の不具合が検出されるような時には、不具合の発生傾向をとらえることで不具合の発生原因の見極めが容易になることがあります。
品質見える化ツール
パレート図
不具合の傾向分析にはパレート図が有効です。 パレート図は、不具合の要因として比較検証しやすい要素を用意し、要素ごとに発生件数を積み上げて、件数が多い順に並べて発生要因を見定めるものです。
サブシステム単位に不具合件数をプロットすると、在庫サブシステムと請求サブシステムで不具合全体の7割を占めるといったような情報を押さえることができます。
重大誤り発生傾向グラフ
誤りの重度(影響度)を期間ごとにプロットし、重大な誤りの有無や発生傾向をチェックするためのツールです。
重大な誤りの発生時期を確認することで、システムにどのような誤りが残存しているかを評価します。 危険度が高い誤りがテスト作業の後半になっても頻発しているようであれば、未だシステム品質としては安定していないと想定でき、品質強化のための対策をとる必要があり ます。
ゾーン評価
ゾーン評価は、横軸を試験密度、縦軸を誤り検出率にして、プログラム単位に実績をプロットするものです。
試験密度というのは試験項目数を表す尺度で、誤り検出率というのは誤り検出数を表す尺度です。ともに、システム規模に対する指標(品質メトリクス)で、それぞれ、どれくらいの試験項目を実施すべきか、どれくらいの誤りが検出されるべきか、を示すものです。
ちなみにシステム規模は、プログラムのステップ(ライン)数、あるいは、システム全体のファンクションポイント数を基に算出されます。
また、試験密度・誤り検出率については、目標とすべき値のほか、目標値に対する許容範囲値も定めます。許容範囲値は、目標値に対し30％程とするのが通例ですが、システムの難易度や重要度に応じて決定してください。
ゾーン評価では、横軸に試験密度目標値と試験密度許容範囲値という2つの値、縦軸に誤り検出率目標値と誤り検出率許容範囲値という2つの値が刻まれます。
そしてプログラムごとに、試験密度が「目標値未満か」「目標値と許容範囲値の間か」「許容範囲値超過か」と、 誤り検出率が「目標値未満か」「目標値と許容範囲値の間か」「許容範囲値超過か」を判断して位置決めをします。
どこに位置づけられたかを見て、そのプログラムの品質を判定する、というのがゾーン評価の方法です。
判定例として
試験密度が目標値未満なのに
誤り検出率が許容範囲値超過 |
品質悪 |
試験項目が少ないのに誤りがとても多い |
試験密度が許容範囲値超過なのに
誤り検出率が目標値未満 |
品質優 |
たくさん試験をしているのに誤りが少ない |
★ゾーン評価のより詳しい説明は、
[システム品質]サイト<品質評価>ページを参照ください。
品質の評価
システムの品質状況を確認する方法として、「パレート図」「重大誤り発生傾向グラフ」「ゾーン評価」などを用いて客観視することを「品質の見える化」といいます。
見える化ツールとしては、他にも「ゴンペルツ(誤り検出収束予測)曲線」といって誤りの発生状況から収束時期を見極めるツールもあります。
客観的な品質を測るモノサシを使うことにより、ウィークポイントが浮かび上がらせることができるため、実効的な品質向上策を実施することが可能となります。
関連記事
テストエンジニア
テスト計画
テスト作業のモチベーション
テスト自動化
統計検定（３級一週間合格記）
統計教育連携ネットワーク(JINSE)
統計検定：データサイエンス
