テスト終了判断を的確に行うために必要不可欠なテスト結果の評価方法。
※文章量が多くなったので、分けた１つ。まとめは下記。
プログラミングルール
評価の必要性
テストでプログラムの全てを確認することは不可能。
テストが十分か否かの判断は、最終的にはプログラム全体にわたる品質の評価に依存。
テスト結果の評価は重要で、評価が的確か否かでテストの成果に大きな違いが出るため、結果を直感や経験ではなく入念に分析することが必要。
評価の観点
- 実施したテストの質・量は十分か
- テスト実施後のプログラム品質は十分か
評価結果のフィードバック
分析で得られた問題点に対するフィードバック措置(品質向上対策)は、現開発作業と次開発作業に関するものに分け、検討・立案することが重要。
テストの質の評価
テスト項目設定漏れの有無
本来テストすべき項目の欠落がないか
※要因の考慮漏れ、テスト項目の抽出技法の利用ミスなど
テスト内容の方よりの有無
テスト内容に偏りがないか。
※重複するテスト項目が多い、ある部分のテストが弱いなど
テスト方法の誤りの有無
テストの質の劣化はないか。
※テストの進め方や確認方法などの誤りなど
テストの量の評価
テスト量の妥当性
実施したテスト量は必要かつ十分な量か
テスト量の偏りの有無
テスト量に偏りはないか
※特定のコンポーネントに対するテスト量が多いなど
テスト結果からの評価は、次の順序で進める
- テストで得た基礎データを分析、質・量の不足に起因する問題点を抽出
- 問題点の発生下人を分析、フィードバック措置を立案
テスト結果からの問題点の抽出/分析
テスト工程で蓄積された基礎データ(バグ記録表、テスト実施記録など)と集計したデータを予め準備しておく。
- 検出バグ内容別件数一覧表(全体、モジュール/コンポーネント別)
- テスト項目消化状況と検出バグ件数の時系列推移(全体、コンポーネント別)
テスト項目の消化状況からみた予測
成功したプロジェクトにおけるテスト項目の『初期段階』『中期段階』『終期段階』に分けた期間での消化とバグの検出状況の一般的な関係から、対比しバグの累積状況を予測。
管理図による担当者別の品質管理
想定では誰がやっても同じ結果になるはずだが、実際は人によりテストの品質は変動する。
そこで管理図を作成することで品質管理を行う。
グラフの点が管理限界外(UCL：上限以上、LCL：下限以下)にある場合、その原因を追求。
u管理図
単位(キロ)ステップ当たりのバグ件数を担当者毎に表示。
p管理図
消化テスト項目数に対する検出バグ件数により、担当者ごとのプログラムに特異なバグが損じするかを検出するために用いる。
コメント