テスト計画の見積もりとは
開発の遅れや予期せぬバグといった『想定外のトラブル』をあらかじめ計算に入れつつ、限られた期間内でどこまでチェックすれば安全と言えるかの落とし所を見極め、チーム全員が納得してゴールへ突き進むための『共通の物差し』を作ることがテスト計画見積もりです。また、開発のテストフェーズで最も大事な役割です。
代表的な三つの見積もり方法
プロジェクトの状況（時間があるのか、精確性を求められているのか）に合わせて使い分けて行う必要があります。
下記は代表三例となります。
【ボトムアップ（WBS）】
- 概要：タスクを細分化してそれぞれの工数を積み上げて計画を立てる方法
- メリット：精度は高くなる
- デメリット：作成時間がかなりかかる
- 決め打ちである程度決めてしまい、その上から係数をかけて出す方法
- メリット：迅速に計画を出すことが可能
- デメリット：計画のズレがほぼ確実に発生
- 最良、最悪、有力の３パターンから選ぶ方法
- メリット：比較することでリスクを回避しやすくなる
- デメリット：経験が必要
実践的な５つのやること
① 範囲（スコープ）の特定
まず「何をテストし、何をしないか」を明確にします。
対象ブラウザやOSの数
新規機能 ＆ 既存機能のボリューム
テスト環境の準備期間
② タスクの細分化 (WBSの作成の場合)
実行フェーズだけでなく、前後の準備を含めるのが大事です。
計画・設計: テスト計画書作成、ケース作成、レビュー
準備: テストデータ作成、環境構築
実行: システムテスト、オペレーションテスト
報告: バグ起票、修正確認、再テスト、完了報告書作成
③ 実行工数の算出
「テストケース数 × 1件あたりの平均消化時間」で計算します。
〈計算例〉
1,000ケース × 6分/ケース ＝ 100時間
※ 1人1日6時間稼働とすると、約17日間
④ バッファ（予備期間）の追加
テストには必ず「想定外」が起こるため、余裕を持たせます。
不具合対応: 修正待ち時間や、再テストの工数をあらかじめ20〜30%程度見込む
リソースリスク: メンバーの休暇や離脱への備え含む
⑤ スケジュール化（ガントチャート）
工数をカレンダーに落とし込みます。ここでは「クリティカルパス」（これを遅れると後続の作業に影響が出る予定）を意識して作成します。
見積もり精度を上げるポイント
「待ち時間」を考慮する: 開発側からのビルド待ちや、デバイステストのための実機調達時間は見落としがちです。
レビュー工数を削らない: 悪いテスト設計は、実行フェーズで大きな手戻りを生み、より工数がかかり計画から逸脱していきます。
過去実績を活用する: 自社の過去プロジェクトで「1ケースあたり何分かかったか」のデータがあれば、それが強力な根拠になります。