テスト工数の見積もりの方法

概要

本記事は『ソフトウェア見積もりガイドブック 品質要件に応じた見積もりとは』
の3.3, 3.4セクションの要約です。
https://www.ipa.go.jp/archive/publish/qv6pgp0000000yho-att/000005132.pdf

テーマ

テストの妥当な見積もりのために考えるべき/やるべきことは何か?

テスト開始後もテストを見積もり直す

• 妥当な見積もりのために、テスト開始後もテストを見積もり直すことが重要です。

なぜ見積もり直す必要があるのか

• テスト進行中に品質目標の指標の予実分析の結果に基づき、テストを改善します。それに伴いテスト量が変わってしまうからです。
• 例えば、予実分析の結果、予定よりも品質が悪い場合、さらなる欠陥の発見のためにテストケースの追加などが発生しえます。すると、テスト量の再見積もりが必要となります。
• あるいは、コンポーネントやフェーズごとに欠陥の偏りが検知された場合、テストケースを追加する必要があります。例えば、コンポーネントごとにテスト不足の機能などを発見する。それにより追加テストを計画する。
• また、テスト前のプログラム品質の中間評価も重要です。品質が悪い場合、テストを中止して設計を見直すことで、テスト段階での棄却される作業量を減らせます。
  (※棄却作業 = 手戻りにより無駄になった作業)

再見積もり時の注意点

• テストの再見積もりの原因には、ベンダーに起因する場合とユーザーに起因する場合がある。そのため、見積もり前提条件などでユーザーとベンダーの間で責任範囲を明確にすべきです。例えば、ベンダーは納品物のバグの比率を80%以下にする、と責任を明確にしておきます。それが満たされずに再見積もりが発生した場合、ベンダーの責任に帰することになります

進行中のテストの品質管理方法も注意する

• テストの見積もりのインプットの1つに、品質目標を測定するための尺度と目標値があります。それは、テスト開始後の品質管理のためのインプットにもなります。そして、品質を測定する指標の精度は、見積もりに影響します。

• テスト進行中の品質と、本番稼働後の品質を定量的に測定し、相関関係を分析することで、プロセス改善点や品質指標の精度を高められた例があります。テスト中の指標は、テスト密度や検出欠陥密度です。本番稼働後の指標は欠陥密度でした。相関関係を分析し、テスト中の品質の尺度が本当に本番稼働後のバグの数に対応しているかを確認しました。不十分であれば改善することで、品質目標達成のための尺度を正確にできます。それにより、その尺度上の合格基準を満たすために必要なテストの工数の正確さも高まることが期待されます。

テスト完了基準

• テストの完了基準によってテストが見積もり通りに終わらない例があります。テスト完了基準は、定量的なテスト網羅性だけでなく、欠陥の修正がどれだけ完了しているか、欠陥の内容などの定性的な基準も必要である。一方、判断基準が不十分だと、品質のデータも収集できず、完了を判断できなくなるリスクがある。
• 欠陥の収束度はコンポーネントごとに見るべき。システムのグロスの信頼度成長曲線を見ることは危険です。グロスでは異常なしでも、特定コンポーネントに欠陥が偏っている可能性があるためです。
• ソフトウェアテストでの欠陥の検出と修正のコスト < 欠陥ありで本番稼働した際の障害による損失コスト である間にのみ、テストを行うべきです

テスト戦略はテスト見積もりに影響する

• テスト見積もりの精度を向上させるには、見積もりの時点でテスト戦略を定め、開発の前提条件として見積もりのインプットとして用いることが必要。

テスト戦略の立て方

テストと関連タスクとの棲み分けを認識する

• テストは、品質保証活動の中の一つである。
• 品質保証活動は、予防、検知、修正に大別される。テストは、その中の検知活動の1つに過ぎない。ゆえに、テストと他の品質保証のための活動の関係を意識することが重要である。例えば、テストは他の欠陥の検知手段であるレビューなどと関連している。
• ※予防とは、ドキュメントの標準化によるミスの防止。技法の使用による設計レベルのミスを防止する。修正活動とは、検知された欠陥を解消すること。

テスト技法の選択

• 一つのシステム内でも、採用するテスト技法次第でテストケース数が異なる。
• さらに、決定したテスト技法のもとで品質指標の目標値を定める。(例：テスト密度、テスト網羅率など)
• ただし、テスト対象システムの業務設計やシステム方式設計をテストする場合は、品質目標値に固守することなく、テスト量を見直す。

テストレベルの設計

• 単体テスト~受け入れテストの間でテスト対象の棲み分けをすることが必要。
• まず、それぞれのテストレベルごとの目標と、その目標が未達成である場合のリスクを考慮する。
  (※テストレベルとは、単体テスト、結合テスト...などのテストの区切りです。)
• そのリスクを踏まえ、テストレベルごとに最も重大な欠陥を早期かつ効率的に検出できる戦略を検討する。
• さらに、テストレベルごとの戦略を設定する際には、他のテストレベルとの関係性を考慮すべきである。受け入れテストなどの後半のテストの視点から単体テストなどの前半のテストの目標を定義することが重要。
  (たとえば、結合テストとシステムテストでテストケースが重複するのを避ける)
• システム全体に影響する重要機能は、テストの優先度を上げることを考慮する。
• テストプロセスの標準に対して、テスト対象システムの固有の性質に基づくテーラリング方針を策定する。その方針は見積もりの前提条件としても明文化しましょう。
• 欠陥はその混入したタイミングに最も近いタイミングで発見すべきです。というのも、修正コストが小さくなり、システムの品質をもとにプロジェクトの進め方を早期に調整できるからです。

テスト実装の方法を検討

• テスト実装とは、テストの実行手順書の作成や、データの準備などのタスクである。
• テストの実行の効率性を上げるための工夫を検討することが必要です。
  例えば、テストデータの重複を避ける、テスト環境の共有、楽な結果確認の方法を検討するなどだ。さらに、1つのデータでなるべく多くのテストケースを消化できるように工夫する。
• テスト手順書の範囲と記述の詳細さは、テストプロセスの標準の中で定義する。さらに、この定義は見積もりのタイミングで決まっておくべき。
• テスト環境を準備する
  テストデータやリグレッションテストの項目を作成し、メンテナンスする。そうしなければ、再テストやリグレッションテストの度に作業が発生するためである。
• テスト自動化ツールなどのテストツールの導入を検討する。

テストにおける役割分担を検討する

• ユーザーとベンダーの役割分担を検討しましょう。業務面の知識を必要とする作業はユーザーが行うと効果的です。例えば、テストデータのバリエーションの設定、操作の洗い出しです。一方、ベンダーは論理的にテストケースを設計することを担当するのが得意でしょう。
• テストケース作成に開発者以外を介入させるかの方針は、テスト戦略内で定義するのがよいです。この際、対象システムの特質などを考慮します。
• ユーザー側のテスト要員をテストに参画させる場合、テストの見積もりに影響するので注意しましょう。

テストプロセス改善の作業もテストのコストに含める

• テストプロセスをメタ的に測定し、プロセスを改善していく。