テストの見積もりの手順

概要

本記事は『ソフトウェア見積もりガイドブック 品質要件に応じた見積もりとは』
の4章の部分的な要約です
(この要約は、諸事情により設計部分の欠陥、非機能要件のテストのセクションなどを含んでいません。)

テストの見積もりは、テスト量とテストの生産性を決めることが重要です。
ですので、それぞれの決め方を紹介します。

テスト量はどのように決定するか？

• まず、テスト量には制約があります。それは、テスト量は単純に組み合わせを網羅すると天文学的数字になる一方、コストやスケジュールは限られているからです。したがって、テスト量はテストコストと残存した欠陥がソフトウェアの品質リスクを許容範囲内に抑えるというトレードオフの中で定めます。
• テスト量は、品質要件から品質指標を定め、その目標値を満たす形で決定されます。
  

より詳細で広範なフローは以下の通りです。

• 見積もり時に必要だが得難い情報があります。それは、ユーザーが期待するリリース段階での残存欠陥密度、つまりリリース時点でソフトウェアにどれだけバグが残っているかです。しかし、見積もり時に残存欠陥密度を知ることはできません(これはリリース後に障害が起きた時にわかる)。
  そのため、残存欠陥密度の代わりの指標を用います。それはテスト網羅率などです。この代替指標のもとで目標値を定め、ユーザーと合意しましょう。

• ただし、テスト網羅率は全機能に一律に値を設定すべきではありません。そうでなく、重大な機能は手厚くするなどの調整をしましょう。(例えば、障害により社会的影響の大きい機能は手厚くする)

テスト網羅率の設定方法

• 網羅率の定義は、ホワイトボックステストとブラックボックステストで異なります。それゆえ、ソフトウェアテスト量を残存欠陥密度とテスト網羅率から見積もる場合は、ホワイトボックステストとブラックボックステストで別々に算出する。
• ブラックボックステストのテスト網羅率の定義。一例は、(実際にテストするテスト項目の数/ありうるテスト項目の数)*100です。ここで、テスト項目の粒度は、ドキュメント内でテストえ確認すべき内容を文章表現したレベルとします。
• この前提のもとで、テスト項目の抽出方法を考察します。
  • 要件定義からの抽出する方法
    機能要件、品質要件からテスト項目を作ります。
    ここで、入力項目のとりうる値の範囲、出力結果のバリエーションを明確にします。 設計書からの抽出。機能仕様や状態遷移図からテスト項目を抽出する。
  • 操作マニュアル類から抽出する
  • 過去の障害に基づくテストを追加する
  • クリティカルなシステムの機能を担保するためのテスト項目を追加する

テストケース数の削減方法

• 同値クラステスト、境界値分析、ペアワイズ法、ドメイン分析テストなどのテスト技法を使う
• ホワイトボックス分析を併用する。ブラックボックス的観点からだと多数のバリエーションが必要となるテスト項目について、ホワイトボックス的分析の結果を加味して削減する。(例：不連続なコード値の妥当性チェック→コードのチェックはテーブル化されている)

その他のテスト網羅性尺度

例えば、
テスト密度 = テストケース数/開発規模　開発規模は、プログラムの行数やファンクションポイント。

※改良開発の見積もり固有の注意点

注意点は2つあります

• 変更箇所の他のモジュールとの結合度です。モジュール間のインタフェースの方式によって、モジュール間結合が異なり、調査作業とテスト量に影響します。結合度が高いほど、結合先のモジュールもテストした方が良いでしょう。
• 既存システム内の改良した箇所の分散度合いです。分散度合いが高いほど、巻き込みテスト量(リグレッションテストの量)が増えます。

テストの生産性に影響する変動要因を織り込む

※改良開発に固有の変動要因

• 既存システムの構造を理解しやすいか
• ドキュメントの準備状況
• システムの構造が分かりやすいか(例：モジュール化ができているか)
• データ構造が分かりやすいか(例：正規化されているか)
• 変更箇所の分散度
• 既存システムの残存欠陥数
• 改良開発の巻き込み度合い(デグレードしうる機能の範囲)
• テスト環境やテストケースを再利用できるか
• 運用環境からの制限 運用環境と関連することによるテストの実施時間帯や可能なリソースの使用量、アクセス権に影響を受ける。

欠陥修正にかかわる工数を織り込む

• 欠陥を修正する際は、作りこんだ工程にさかのぼり、修正をする。 そのため、工程ごとにかかる修正時間の総和が欠陥修正にかかる工数になる。
  修正範囲のイメージは以下の図を参照。
  

• 欠陥修正による再テスト工数を算出する。
  次の式で算出できる。
  Σ修正された欠陥の数×再テストに要する時間

ただし、欠陥修正による影響範囲が広範囲であるほど、再テスト工数は増加する。