品質管理ノート（２００７年０６月０１日）＿定量的ソフトウェアテスト完了判断基準

• １、ソフトウェアのテストに明快なおわりはない。
• よく言われること
  テストでバグがあることは、証明できる。
  テストでバグがないことは、証明できない。
• テストを続けていれば、バグは出ていくるもの
• 経済的な理由から、どこかで何かをきっかけに、テストの継続をあきらめあければならない。
  テストの『完了』を適切に判断するには、どう考えるべきか？
  定量的尺度を使ってテスト完了判断を行うには何が必要か？

２、検討するテストフェーズ

何れの開発モデルも、テストは最下流に位置する。
要求開発、要件定義→設計→実装→テスト→顧客での検収、利用
━━━━━━上流━━━━━━━━━━下流━━━━━━━⇒
＜検討対象＞
『Verfication & Vallidation』の”Verfication”をメインに据えて、テストの完了判断を定量的に行うための考え方、前提条件を探る

３、『テストを完了した』とはどういうことか？
そのテストで目的としていたものを達成していると言える状態。

４、テストの４つの目的

• ソフトウェアに潜むバグを検出し、修正
• 求められる要件を満足していることを確認
• バグの発生状況から、まだ潜むバグの存在を推測し品質の成熟度を判断
• バグの作込み要因と、より上流の検証フェーズの流出要因を分析して、開発プロセスの問題を特定、対策

５、完了判断基準とは

• そのテストの目的を達成しているか、判定する材料。
• テストの目的をゴールに据えて、メトリクスを設計、検討するためのＧＱＭパラダイムに当てはめる。

６、GQMパラダイムとは

• Basili教授らによって提案されたソフトウェア測定及び評価のための総合的な枠組み
• ＧＱＭを階層構造で表すことにより、測定及び評価目的を明確化
• 測定の目標（Ｇｏａｌ）を明確化
• ↓
• その目標の達成方法又は評価方法を質問（Ｑｕｅｓｔｉｏｎ）の形式で記述
• ↓
• その質問に定量的に答えるための測定量（Ｍｅｔｒｉｃ）を定義

７、ソフトウェアテストのＧｏａｌとＱｕｅｓｔｉｏｎ

＜Ｇ１＞ソフトウェアに潜むバグを検出し、修正

• Ｇ１Ｑ１：妥当な質と量のテスト項目を設定
• Ｇ１Ｑ２：設定したテスト項目を実行
• Ｇ１Ｑ３：検出したバグを修正
• Ｇ１Ｑ４：検出したバグを正しく修正していることを確認

＜Ｇ２＞要件お満足していることを確認

• Ｇ２Ｑ１：要件を網羅するテスト項目を設定
• Ｇ２Ｑ２：プログラムの全機能を動作させるテスト項目を実行

＜Ｇ３＞バグ発生状況から品質成熟度を判断

• Ｇ３Ｑ１：予め想定したバグ数だけ、バグを検出できている
• Ｇ３Ｑ２：信頼度成長曲線が収束している

＜Ｇ４＞開発プロセスの問題を特定、対策

• Ｇ４Ｑ１：バグの発生状況を、開発プロセスにフィードバックしている
• テスト目的ブレイクダウン⇒必要なメトリクスを設計⇒完了判断基準構築

Ｇ１Ｑ１：妥当な質と量のテスト項目を設定

• テストの質をどう測るか？
  自分たちは何をテストしようとしているのか？
  網羅すべきテストのカテゴリを計画し、それに沿うってテスト設計できているか？（カテゴリ別テスト件数）
• テスト量は十分か？
  テスト対象ソフトウェアの規模に見合う量か？（テスト件数とプログラム規模との比率）
• テストの取捨選択
  意図したとおりにテストを設計し、実行することが困難な状況もある（テストにかけられる要員、時間）
  合理的にテスト項目を間引く
• カテゴリ別テスト件数
• テスト件数とプログラム規模と比率
• 実施しないテストカテゴリの明確か、リスク対応策

G1Q2：測定したテスト項目を実行

• 実際に実行したテスト項目数
  予め計画、設計したテスト項目が、テスト環境や時間等の制約で全て実施できないこともある
  実質的にテスト設計の段階で間引くこと同義
  テストを実施しなかったことに対するリスクを検討
• 設定したテスト項目数
• 実際に実施たたテスト項目数の比率
• 実施したテスト項目数と、プログラム規模との比率
• 実施しなかったテストの明確化、そのリスク、対応策

 G1Q３：検出したバグを修正

• 発見したバグは全て修正することが原則
  バグの修正にはデグレードの危険が常につきまとう
  テスト終盤のバグ修正には格段の注意が必要
  バグの重要度によっては、修正しない選択肢もある
• バグの重要度
  重要度の定義は、一種の価値観の表れ
  重要度の定義の合意、判定の仕組み
• 考え方の根底
  検出したバグを全て修正するという、いわば１００点満点を基準にするのではなく、”合格点”を合理的に設定
• 修正しないとしても、バグの原因解明は必須
  不具合の現象が軽微であっても、原因はクリティカルなものかもしれない
•