テスト進行中における品質管理と再テスト見積り

既に3.2節(1)で説明しています品質目標値は、ソフトウェアテスト見積りのインプット条件と なるとともに、テスト進行中における品質管理（予実管理）のインプットにもなります。

品質目標値の予実分析結果により、追加テストケースなど、テスト量の再見積りが必要になる 場合があります。その再テスト見積りにはベンダに起因する欠陥とユーザに起因する欠陥とが存 在しますので、ユーザとベンダ相互に見積り前提条件などで責任範囲を明確にしておく必要があ ります。

事例２９は、テスト進行中におけるテスト密度、検出欠陥密度と本番稼動後の欠陥密度とを予 実管理し相関関係を分析することで、品質指標を精錬させ、テスト見積り精度向上を目指した事 例です。

事例３０の二つの事例［①、②］は、テスト進行中での品質目標値の予実管理と定性的な欠陥 状況分析を組み合わせた品質管理を紹介しています。テストの早い段階で品質管理を徹底した結 果、品質目標値の再設定（テスト密度の再設定によるテストケースの追加）およびテストプロセ スの見直しによるソフトウェア品質を確保した成功事例です。一方、事例３１の二つの事例［①、

②］は、一つ目は品質目標値の不明確さと相俟ってテスト進行中での予実管理の不徹底による失 敗事例、二つ目は信頼度成長曲線管理（事例ではグロス累計欠陥管理を適用）に依存し、特定の 劣悪なソフトウェアコンポーネントの品質状況を見逃したことによる失敗事例です。ソフトウェ アの品質は、特定のソフトウェアコンポーネントの品質が極端に劣化した場合、システム全体の 品質へと影響範囲が拡大してしまう危険性がありますので、ソフトウェアコンポーネント単位の きめ細かい品質指標を管理する必要があります。

55 事例２９（成功事例）：

課題となっている状況・状態

統合テストおよびシステムテストのテスト密度・検出欠陥密度の実績と、本番稼動後の欠陥密 度との相関関係を分析することで、テスト見積りの精度を向上している。

見積りの成功/失敗の度合い

傾向として、統合テストおよびシステムテストの検出欠陥密度が平均値より高いと、本番稼動 後の欠陥密度も高くなる。

●平均的なシステムテストの検出欠陥密度および本番稼動後の欠陥密度 検出欠陥密度（2 件/10ＫＳ）、本番稼動後の欠陥密度（0.2 件/10ＫＳ）

●品質劣化したシステムテストの検出欠陥密度および本番稼動後の欠陥密度 検出欠陥密度（12 件/10ＫＳ）、本番稼動後の欠陥密度（2 件/10ＫＳ）

教訓・メッセージ

設計・実装工程（基本設計～コーディング）での検出欠陥密度（レビューなど）、テスト工程 でのテスト密度および検出欠陥密度（確認テスト）、さらに本番稼動後の欠陥密度との相関分 析を行うことにより、プロセス改善点を発見できるとともに品質指標の精度を高められる。

事例３０（成功事例）：

課題となっている状況・状態

① 単体テストの完了時に、欠陥の傾向として偏りがあった。

・欠陥の偏り

画面表示形式、項目出力不正、表示不正

・検出不足

エラー処理の欠陥が少ない

現象別・原因別の品質マップを作成することによる欠陥の傾向に応じて品質目標値を再 設定して、是正処置(追加テスト)を実施した。

単体テストの後に是正処置(追加テスト)を実施したので、組み合わせテスト開始日は遅 延したが、組み合わせテスト完了日は目標を達成できた。

② プログラム品質の中間評価により方向性を決める。

プログラム品質の中間評価で、設計不良が多くあったので、一旦、テストを中止して設 計を見直した。

プログラム品質の中間評価により、テスト段階での手戻りを削減できる。

見積りの成功/失敗の度合い

① 単体テストの後に是正処置(追加テスト)を実施したので、組み合わせテスト開始日は遅延 したが、組み合わせテスト完了日は目標を達成できた。

② プログラム品質の中間評価により、テスト段階での手戻りを削減できた。

① テスト密度(ケース数／ソフト規模)：見積比 1.2 倍 検出欠陥密度(欠陥数／ソフト規模)：見積比 0.9 倍

② プロジェクトコスト：見積比 0.9 倍 教訓・メッセージ

① 品質目標値はテスト見積りとテスト進行中における品質管理（予実管理）のインプットに なる。この例では、品質マップを作成し欠陥偏在分析を行うことにより、品質目標値の再 評価（再設定）を行い、さらに是正処置として再テスト量を見積り（追加テスト）、品質 を担保している。

② テスト戦略において、設計不良のテスト量は、設計工程での残存欠陥密度（レビューなど で検出しきれない残存欠陥数）を予測して見積もる。しかし、テスト工程において設計不 良が予測値より多く検出された場合は、設計工程の見直しを早期に行うことが必要であ る。

57

事例３１（失敗事例）：

課題となっている状況・状態

① 複数のサブシステムからなるシステムにおいて、欠陥の収束状況をシステム全体の信頼度 成長曲線にて評価していたが、突然、欠陥が検出されるようになり、手戻りが発生した。

実態はサブシステム毎の収束状況が一律でなく、ある特定の劣悪なサブシステムに全体が 引きずられた結果となった。

② 品質目標値との乖離がある場合の対処について、テスト計画時点で明確でなく、判断材料 となるべく資料も十分に採取・管理されていなかった。そういう状況下、欠陥が収束せず、

テストが完了できなかった。

結果、追加テストを実施し、テストコスト増となった。

見積りの成功/失敗の度合い

① 欠陥の収束状況を見誤ってしまい、手戻りによるテストコスト増が発生した。

② 情報が不十分なため、テスト完了判断ができなくなり、さらに追加テスト発生によりテス ト工数が増加した。

① テストコスト：見積比 1.2 倍

② テスト密度(ケース数／ソフト規模)：見積比 1.3 倍 テストコスト：見積比 1.2 倍

検出欠陥密度(欠陥数／ソフト規模)：見積比 0.8 倍 教訓・メッセージ

① 信頼度成長曲線を用いて、システム全体のグロス（コンポーネント単位などではなく）の 管理だけで欠陥の収束度を管理するのは危険である。また、ソフトウェアテストの特質と して、特定のソフトウェアコンポーネント（ある機能を有するソフトウェア群）の品質が 劣悪であると、全体のテスト効率低下となる傾向にある。テスト見積りではこのような生 産性変動要因に関わるリスクをヘッジする配慮も必要である。

② テスト戦略（計画）としてのテスト完了基準は、ユーザとベンダとの相互同意が前提である。テスト 完了基準は定量的なテスト網羅性（残存欠陥密度）だけではなく、欠陥の修正状況および検出 した欠陥の発生傾向などの定性的な基準策定を考慮することが必要である。また、テスト進行中 や完了時点の品質目標値の評価・分析は、テスト見積り精度の向上を目指すためにも必要であ る。