ソフトウェアテストの見積もり

ＶモデルからＷモデルへの変遷なども踏まえ、改めてテスト関連作業について、実施する時期 と作業の内容を明確にする。従来は、テスト実施工程に行う作業をテスト（のスコープ）と捉え、

テストの作業量・工数を議論することが多かった。Ｗモデルでは、実施する作業内容には大きな 変化はないが、時期の前倒し、作業者の変化を始め、テスト戦略、計画などの重要性がより強調 されるようになった。そこで、実施工程毎の時間軸における実績を活用した見積もりだけではな く、テストという切り口で実績を把握し、テスト作業の見積もりの精度向上に繋げている。

表 2.1 は、テスト関連作業の実施時期を開発作業との対応で表している。縦方向は時間軸を示 し、< >はテスト関連作業、・ はテスト関連作業の中の詳細作業項目を示している。

表 2.1 テスト関連作業

テスト戦略 システムテスト 統合テスト 単体テスト 要件定義 <テスト

戦略策定> <テスト計画策定>(前半) 論理設計

物理設計

<テスト設計>

・要求事項の洗い出し

・確認事項への展開

・確認事項の整理 <テスト計画策定>(前半)

・テスト項目への変換

・テスト項目レビュー

<統合テストの結合順序>

<テスト設計>

・設計事項の洗い出し

・確認事項への展開

・確認事項の整理

・テスト項目への変換

・テスト項目レビュー プログラム

開発

・テスト項目の移動（両テストで同期して実施）

<テスト計画策定>

<テスト設計>

・テスト項目作成

・テスト項目レビュ ー

<単体テスト準備>

・テスト環境整備 削除: 繋げたい

<テスト計画策定>(後半) <テスト計画策定>(後半) <単体テスト実施>

・テスト実施

・実行結果のチェッ ク

<テスト結果レビュ ー>

・テスト報告策定

・レビュー 統合・

システム テスト

<システムテスト準備>

・テスト環境整備

<システムテスト実施>

・テスト実施

・実行結果のチェック

<テスト結果レビュー>

・テスト報告策定

・レビュー

<統合テスト準備>

・テスト環境整備

<統合テスト実施>

・テスト実施

・実行結果のチェック

<テスト結果レビュー>

・テスト報告策定

・レビュー

ここでは、特に重要視されてきた“テスト戦略”と“テスト計画”について、解説する。

まず、各テスト（システムテスト、統合テスト、単体テスト）の考え方、達成すべきゴール（テ スト終了条件）、障害管理の方法、テスト支援ツールの適用有無など基本方針をテスト戦略として 定める。

そのテスト戦略に沿って、以下のような項目を検討し、テスト計画書としてまとめる。

①テストの対象範囲と対象外範囲、②テスト環境と準備事項、③テスト結果記録方法とレビュ ー方法、④テスト開始に必要な事項と条件、⑤テスト終了基準、⑥テストの準備、設計、実施、

結果レビューなど作業のスケジュール、⑦体制と役割

なお、ここで特筆すべきことは、テスト計画を前半（テスト設計の前）と後半（テスト設計の 後）の 2 段階に分けて策定していることである。前半では、テストの概要、及びテスト設計作業 を含めたテストに必要な作業と概略スケジュールを明確にし、後半はテスト項目が確定した段階 で行い、テスト項目と詳細な実施スケジュールを策定してテスト計画を完成させる。

2.3.2 テストの量

「どこでテストを終われるか？」は、どのプロジェクトでも必ず直面する課題である。

テストの量を左右するテストの網羅性とテスト終了基準について言及する。

（１）テストの網羅性

103

ソフトウェアは複雑で多様な機能の側面を持ち、それぞれの側面からソフトウェアを見た場合 異なった姿に見えることがある。そこで、テスト項目の策定にあたっては、担当者個人のスキル に依存する部分を極力減らし、テストの網羅性を確保するため、以下のような各側面より、テス トすべき事項を考えることが有効である。

①時間効率、②資源効率、③耐久性、④大容量、⑤互換性、⑥整合性、⑦環境、⑧セキュリテイ、

⑨障害、⑩入力データ、⑪構文、⑫操作、⑬状態遷移、⑭言語、⑮導入、⑯保守、⑰文書、⑱機 能、⑲インターフェースほか

（２）代表的なテスト終了基準

①収束を使ったテスト終了判定

・テスト工程で障害が収束すれば、本番環境で障害が出にくいということが経験的に分かってい る。

・通常は障害の収束の判定に「信頼度成長曲線」を使用する。

②「カバレッジ」による十分性チェック

一般的な基準では、「分岐網羅（Ｃ1 カバレッジ）」を 100％達成する。

③「レビュー」による十分性チェック

考えうる仕様パターンを網羅したか（ブラックボックステスト）をレビューでチェックする。

④「品質メトリックス」による十分性チェック

・品質メトリックスとして、テスト密度と障害検出率を使用する。

－テスト密度 ＝ テスト項目数(件) / 開発規模(KLOC) －障害検出率 ＝ 障害件数(件) / 開発規模(KLOC)

・以下の事項を考慮して、「プロジェクト品質目標（品質メトリックス値）」を決定する。

(a)組織の品質目標：「品質メトリックス値目標ガイド」

(b)顧客要件とプロジェクトの特性を反映した品質特性

高信頼性要求（障害が人命にかかわる、障害が公表されると企業の評価に重大な影響など）

短期開発要求（品質を犠牲にしても短期開発を実現したい など）

コスト削減要求（開発コストを低下させたい など）

（c）開発担当組織の過去の実績

これまで開発した類似システムでの品質メトリックス実績値 外部委託する場合は協力会社の品質メトリックス実績値

2.3.3 テストの生産性改善

テストフェーズの生産性は、テスト関連作業の各局面での工夫により、改善することが可能で ある。

（１） テスト手順の最適化

テスト環境とテストデータの準備を効率的に実施できる順序を検討する。

・前工程の処理結果を次工程の入力として利用することで、データ準備工数を削減する。

・サブシステム内で完結する処理を固めてから、連携処理のテストに入る。

・テスト実施者の習熟効果を高めるため、同じ種類のテストパターンを集中的に実施する。

（２） テスト準備の効率化

テスト効率の高いテストケースを設計する。

・ロジックの網羅性が高いテストケースを設計して、総テスト件数を減少させる。

・テストケースを使い回せるように、正常系と異常系を分けて設計する。

・モジュールの制御構造をサンプリングで確認して、Ｃ１網羅率をカバーできるテストケー ス数の目安を把握しておき、テストケース数の妥当性を評価する。

・条件の組合せは、デシジョン・テーブルを使用してテストケースを設計する。

（３） テスト実施の効率化

①ある部分がエラーになると残りのテストケースが実施不可能となる状況を回避する。

・相互に依存しないテストケースを予め用意しておく。

・必ず実行されるクリティカルなロジックは、事前にレビューしたりミニ･テストを実施する。

・途中の処理で誤った結果が出力されても処理が続行できるようにするため、チェックポイ ント毎の正しい入力を予め用意しておく。

・目的とする結果が得られたか直ぐに判断できるようにする。

・期待する出力を事前に文書化しておくことで、検証者の判断を待たなくてもテスト実施者 がその場で結果を確認できるようにしておく。

・期待する結果が得られた場合と得られなかった場合の取得すべき証跡を明示しておく。

②テスト用のコードを予め組み込んでおき、実行時のオプションなどでテスト用コードのオン/

オフを制御し、本稼働時を含めて必要なタイミングで重要情報を取得できるようにしておく。

③リグレッションテストの効率化

各サブシステム毎に必ずテストすべきパターンを予め設定しておき、修正結果受入の都度実 施する。可能ならばツールを使用して当該作業を効率化する。

④ツールの有効活用

・カバレッジ・ツールによる網羅性チェック、メモリリーク／バッファオーバーフローなど チェック・ツールを適用すると、テスト効率の向上だけでなく、テストプロセスの信頼性 が向上する。

・負荷テスト、リグレッションテストなど繰り返し実施し、同一のタイミングを発生させる 必要があるテストでは、効率面だけでなく、テスト自体の品質向上という面でも有効であ る。

（４） 修正作業の効率化

・期待する結果が得られない場合、正しくないと想定される部分とその根拠（設計書の当該 部分）、及び、期待する結果を示すことで、修正者の作業効率を高める。

・修正後に確認すべき項目を標準化しチェックリスト化して、修正結果に証跡を添付する。

2.3.4 ソフトウェアテストの見積もり

2.3.1 項で洗い出した作業を、ドキュメント作成工数、テスト工数と管理工数として見積もる。

（１）ドキュメント作成工数

＜テスト戦略策定＞、＜テスト計画策定＞、＜統合テストの結合順序＞、＜テスト設計＞と

＜テスト結果レビュー＞のテスト報告策定作業について見積もる。

■成果物作成工数：テスト戦略書、テスト計画書、テスト仕様書、テスト報告書など作成工数

ドキュメント内 テスト見積り (ページ 101-105)