テスト戦略とソフトウェアテスト見積りに関わる事例

（１）品質指標・目標値とソフトウェアテスト見積り

テスト戦略として品質指標項目を決定し目標値を設定することは必要であり、ソフトウェアテ スト量を見積もるためのインプット条件となります。また、品質目標値にはレビューとテストの 両面で取り決めておく項目（検出欠陥密度、テスト網羅率など）もあり、テスト見積りを行うう えで注意が必要です。

尚、品質目標値には、一般的にテスト密度（ケース数/ソフト規模）、検出欠陥密度（レビュー、

テスト）、テスト網羅率、残存欠陥密度（レビュー、テスト）などがあります。

事例１１の二つの事例［①、②］は、標準的な品質目標値をそのまま使用して失敗した事例で す。保有する品質目標値の精度問題およびテスト対象システムの固有な特質や環境を見極めたう えで適用することが必要です。特に、テスト見積りと関係が深いテストの網羅性｢テスト網羅率｣

37

と残存欠陥密度（代替指標含め）は、テスト戦略において調査・分析評価し、テスト見積りの入 力条件としてユーザとベンダ相互に合意しておくことが重要です。

事例１２は、品質目標値（テスト密度）を類似業務システムから流用しテスト見積りの入力と していた失敗事例です。類似業務でもテスト環境などの違いから、そのまま適用するのは危険で す。

事例１３は、テスト計画の初期段階で設計方針を配慮して品質目標値（テスト密度）を評価し テスト量を見積もり、テストケースレビューにてテスト内容の精度を高めた成功事例です。

尚、テストの網羅性（テスト網羅率）と残存欠陥密度をどのようにして設定し、ソフトウェア テスト見積りを導き出すかは、第4章で説明します。

事例１１（失敗事例）：

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

① 基盤開発で、ユーザ提示のテスト密度(50 項目／ＫＳ)とテストケース抽出方法を前提に、

テスト見積りを行ったが、テスト量（テストケース数）の増加となった。

② テスト密度と検出欠陥密度による品質評価を定期的に行い、予定どおりのテストを消化し てきたが、次工程にて多くの障害が発生した。原因分析したところ、前工程でのテスト漏 れだと判明し、前工程のやり直しとなった。

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

① 抽出方法が細かかったためテストケース増加となったが、幸いにも１ケースあたりのテス ト実施時間が短時間で済んだため、コストへの影響は少なくて済んだ。

② 障害の原因解析や前工程テストのやり直しによりテスト工数が増加した。

テスト密度がテストプロセスの品質を表さないことにより、このメトリックスを評価す る意味がなかった。

① テスト密度(ケース数／ソフト規模)：見積比 2.0 倍 テストコスト：見積比 1.05 倍

② テストコスト：見積比 1.3 倍 教訓・メッセージ

標準的な品質目標値を、そのまま、テスト対象システムに適用することは極めて危険である。

品質目標値はテスト戦略において、対象システムの特質などを見極め（分析・評価）、その結 果をテスト見積りの入力情報にすることが必要である。

事例１２（失敗事例）：

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

新規顧客の受託開発において、類似業種システムの過去実績をベースにテストの見積りを行っ たが、いざテストを実施する際に、統合テストのテスト密度の認識相違が判明して、テストケ ースが増加した。

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

要員を増員してスケジュールは確保できたが、テストコストが増加した。

・統合テストのテスト密度(ケース数／ソフト規模)：見積比 1.2 倍

・統合テストコスト：見積比 1.2 倍 教訓・メッセージ

類似業種システムの過去実績（品質目標値）をテスト対象システムに適用評価をしないで採用 することは極めて危険である。品質目標値はテスト戦略において、対象システムの特質などを 見極め（分析・評価）、その結果を、テスト見積りの入力情報にすることが必要である。

事例１３（成功事例）：

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

業務共通設計、処理方式設計を考慮したチェックリスト（テストケース一覧）の作成計画がな かったので、画面遷移時のデータ引継ぎと項目間入力可否チェックなどが、チェックリストに 漏れていた。そのため、新たに業務共通設計、処理方式設計に合せたチェックリストを作成す ることにして、さらに、テスト計画の初期段階で、チェックリストをレビューすることにより、

事前にチェックリストでの品質を作り込むことができた。

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

テスト計画の初期段階で、チェックリストをレビューすることにより、事前にチェックリスト の品質を作りこむことができた。

39 プロジェクトコスト：見積比 0.95 倍

教訓・メッセージ

テスト戦略（計画）策定時の標準的な品質目標値の適用に固守することなく、テスト対象シス テムの業務設計や処理方式設計などを配慮したテスト設計において、テスト量（テストケース 数など）を再見積りすることも必要である。

（２）ソフトウェアコンポーネント毎の重要度とソフトウェアテスト見積り

ソフトウェアコンポーネント（業務機能を実装するプログラム群）毎の欠陥による障害の影響 度（リスク度合い）と修正に対する優先度の検討は、テスト戦略として重要な検討項目です。特 に、重要度に関しては、ソフトウェアコンポーネント毎のテスト量への重み付けを、明確にする ことが大切であり、テスト量の見積りをするうえで必要です。

事例１４は、サブシステム毎の重要度を優先付けせずに、標準的な品質目標値を一律に設定し たことによる失敗事例です。

事例１４（失敗事例）：

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

規模・特性の違うサブシステムに対し、一律、標準的な品質目標値を適用し、テスト計画を策 定した。その結果、テスト過多、テスト不十分な状況が発生し、テスト期間、工数が増加した。

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

特定のサブシステムにおいて、欠陥が収束せず、テスト期間を延長し、追加テストを実施した。

当該サブシステムは、システム全体の主要機能（重要機能）を有するため、全体の本番稼動時 期にも影響した。

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

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

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

標準的な品質目標値を、そのまま、テスト対象システムに適用することは極めて危険である。

品質目標値はテスト戦略において、対象システムの特質などを見極め（分析・評価）、その結 果をテスト見積りの入力情報にすることが必要である。特に、システム全体に影響する重要機 能は、テスト戦略（計画）でテスト優先度の重み付けを行い、テスト見積り（テスト密度の差 別化など）として考慮しておくことが重要である。

（３）ソフトウェアの非機能要件とテスト見積り

非機能要件は｢業務機能｣に関する要求定義より、仕様面で明文化されていない場合が多く見ら れます。このような非機能要件の曖昧さは、テスト漏れやテスト優先度を低く評価する方向に向 き、テスト量（テストケース数など）の見積りが過少になる傾向があります。

事例１５、事例１６、事例１７は、効率性（時間効率性）に関する事例です。事例１５はデー タの伸び率を見積りにおいて考慮し成功した事例で、一方、事例１６はデータの伸び率を考慮し ないで失敗した事例です。事例１７は、大量データ準備に時間とコストがかかるため、少量デー タで代替し失敗した事例です。業務への影響度が大きいソフトウェアコンポーネントの場合は、

テスト戦略においてテストデータ量の算定を十分に検討すべきです。事例のようにソフトウェア プログラミング工程での単純ミスが原因となる場合もあり、プログラムソースレビューの徹底も 意外と効果が上がります。

事例１５（成功事例）：

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

開発期間 2 年という大型改良開発案件で、本番後の想定データ処理件数が提示された。しかし、

開発期間中での状況変化（処理件数増加）を含め、既存ＤＢへのデータ件数増加を配慮したタ スク「現行処理性能判定」を提案し、認められた。当該タスクは機能追加・修正のない現行処 理を対象に行った。

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

機能追加や修正のない現行のＤＢ検索処理で大量データによる性能確認を行ったところパフ ォーマンスの悪い（不適切な検索キーを使用している）処理が発見できた。テストデータ量は 提示いただいた本番後の想定件数の 2 割掛けとした。

教訓・メッセージ

改良開発は既存母体システムの品質（ここでは性能面）によりテスト工数が影響される。既存 母体システムの品質に問題がある場合（過去の障害状況分析など）には、事前に、問題がある コンポーネント（ある機能を有するプログラム群）の事前検証をするなど、テスト見積りの変 動要因となる要素を排除しておくことが重要である。