テスト工数の見積もり時に織り込むべき要因

本記事のゴール

テストの工数の見積もりの際に考慮する点をまとめる

留意する点

• テスト戦略の観点
• テスト工程全般の観点
• テストの役割分担の観点
• テストプロセスの観点
• 契約方法の観点

テスト戦略の観点

品質を測定するための指標を決定しよう

• 指標(メトリクス)を決定し、それぞれの目標値を設定することはテスト量を見積もるためのインプット条件である。品質目標のメトリクスの例は、テスト密度(ケース数/ソフト規模)、検出欠陥密度、テスト網羅率、残存欠陥密度などがある。さらに、テストのメトリクスは、品質目標値の精度の問題、テスト対象システムの固有な特質や、環境を踏まえて選択することが必要だ。標準的な方法を流用することは危険である。というのも、流用した結果、的外れなメトリクスを採用してしまうことがある。例えば、テスト密度がテストプロセスの品質を表現していなかったことで、そのメトリクスを評価しても無意味となることがある。
• 加えて、テストの網羅性、残存欠陥密度の目標値は、テスト見積もりの前提条件としてベンダーとユーザーの間で合意することが重要。
• 一方、テスト計画時の目標値に固執するのも良くない。テスト対象のシステムの業務設計や処理方式設計などを配慮してテストケースを作成する場合、テスト量を再見積もりすることも必要となる。
• ソフトウェアコンポーネント(業務機能を実装するプログラムのグループ)ごとの欠陥による影響度合いと修正の優先度の検討が重要。この重要度により、ソフトウェアコンポーネントごとのテスト量への重みづけを行うべき。重みづけとは、テスト密度に差をつけるなどである。

テスト工程全般の観点

ソフトウェアテスト全般のコストの見積もりにあたっての重要な課題は、テストの量とテストの生産性を設定することである。この生産性への変動要因の1つは、既存のシステムの品質状況。すなわち、既存システムに残存欠陥が高い機能がある場合、その欠陥を修正する作業も起きうるのだ。そのような作業をテスト工数に盛り込むという選択肢がありうる。さらに、母体となる現行システムに潜在的なバグがある場合もテスト工数を増加させる要因になりうる。例えば、原因不明の予期せぬ動作が多発しても現行システムへの調査が行えないとすると、調査の工数が増える。

ソフトウェアテスト見積りガイドブックより抜粋

テストの量に対する変動要因

特に新規でなく改良型の開発固有の要因が3つある。1つ目は既存システムの品質すなわち残存バグの量である。2つ目は改良による影響範囲が既存システムの中の局所に集中しているか、システム全体に分散しているかでテスト量は変化する。3つ目は、テスト工程ごとのリグレッションテストの範囲である。改良開発では、共通モジュールの影響範囲が不明確である場合もある。そのため、影響調査を怠ると障害につながる可能性が高い。これら3つを調査し、テストの量と生産性への影響を評価し、見積もり時の重みづけをする。

テスト生産性に対する変動要因

• テストのレベル
  • 一般的なバグの発見の規則性がある。テストの初期は欠陥が多く検出され、欠陥の解析と修正スピードは比較的早く生産性が高い。しかし、テスト後半になると、1件あたりのバグの検出と解析が難しくなる上、テスト内容が複雑になる傾向がある。単体テストレベルのバグは放置してシステムテスト段階になると、そのバグに由来する欠陥原因の解析工数が増加する。
• テスト対象のコンポーネントの複雑度
  • 複雑性に由来する難バグも生産性に影響する。難バグとは、欠陥原因の解析工数が増加すること、テスト量の割にバグの検出数が少なくなること。それゆえ、複雑性の高いコンポーネントのテストは、早めに行う方が良いだろう。バグを早期に発見し、修正するためである。

テスト分担の観点

• 外部接続が多い統合テストやシステムテストでは、ベンダとの契約方法の工夫や定量的なシステム品質状況の把握の手立てが必要。

• 他責(外部ベンダーなど)による追加作業が起きることは、テスト見積もりの前提条件とするべき。追加作業の例は、外部インタフェースの仕様が突然に変更されていることで、設計と実装工程の修正とテスト修正工数が増加するなどだ。

• テストデータをテスト標準として蓄積し、保守でのテストに流用する。それにより、業務データの理解にかかる時間の削減、リグレッションテスト用のデータ作成の工数を削減できる、テストデータを間違って選ぶ確率を減らせる。

テストプロセスの観点

テスト手順の工夫によるテスト生産性の向上

• テストケースを相互に依存しないように用意する。独立した処理を固めてから、連携処理のテストを実施した。
• テスト環境とテストデータの準備が効率的に実施できるようテスト順序を作成した。テストケースの重複を見極め、単一のデータで複数のテスト項目を消化できるようにする。
• データの処理手順を考慮して、テストケースの実施順序を決めることで、テスト実施の効率化を図れる。

安易なテスト手順書の省略によるテスト生産性の低下

• テストの手順書の範囲と記述の詳細さは、見積もり時点でテストのプロセス標準として決めておくことが必要である。
• リソース別管理によるテスト量の見積もりミス
• テスト進行中に判明した品質をもとにテストを見積もりなおす。例えば、想定よりもバグが多かった場合は見積もり直しが必要となる。
• テスト環境と本番環境の差異を体系的に整理し、障害のリスク対策を練る。ある事例では、差異を整理しないがゆえに障害が発生した。

本番環境には、テスト環境にないデータベース・オプションを導入（コスト抑制のため、テスト環境では未導入）していた。テスト環境では確認されなかった障害が本番環境で発生した。今回の障害の直接原因は、データベース・オプション使用環境において、オンライン実施時にのみ発生するデータベース・パッケージのバグであった。しかし、製品マニュアルには、注意事項の記載がなかった。また、作業実施日の 1 カ月前に「既知のバグ」として製品ベンダの技術情報データベースに掲載されていたが、見逃していた。

根本原因は、テスト環境と本番環境の差異が明確になっていなかったため、事前テストにおける環境差異の影響が十分に把握できていなかったことにある

契約方法の観点

見積もりにあたって契約方法の工夫をしよう。テスト量とテスト効率への変動要因はユーザーとベンダーの間で合意をとることが重要。他責(他ベンダーなど外部要因の責任)による再テストなどの追加タスクは、テストの見積もりの前提条件として、ユーザー、ベンダー、との間で合意すべき。

参考資料

ソフトウェアテスト見積りガイドブック

SEC BOOKS：ソフトウェア改良開発見積りガイドブック