ソフトウェアテストにおけるテスト見積もり手法
⚡ スマートサマリー
ソフトウェアテストの見積もり手法は、テストにかかる時間と費用を概算するものです。タスクの細分化、担当者の割り当て、工数の見積もり、関係者との検証という4つのステップを経て、曖昧なスケジュールを経営陣が承認できる、説得力のある計画へと変換します。

ソフトウェアテストの見積りとは何ですか?
ソフトウェアテストの見積もり テストの見積もりは、テスト作業にかかる時間と費用を概算する管理活動です。信頼できるテスト見積もりを作成することは、 テスト管理 なぜなら、それはスケジュール、予算、およびリソース配分に関する意思決定を左右するからです。
テスト推定が重要な理由
クライアントはテスト契約を締結する前に必ず2つの質問をします。
小規模プロジェクトの場合、これらの質問には簡単に答えられます。大規模なプロジェクト、例えばテストの場合、 Guru99 Bankのウェブサイト ― 回答を擁護するには、体系的な手法が必要です。
何を見積もるか?
- <ご参考> 業務遂行に必要な人材、設備、施設、資金、その他あらゆるもの。
- 時間: あらゆるプロジェクトにおいて最も貴重なリソースは、リリースの期限である。
- 人間的スキル: チームの知識と経験。経験豊富なテスターは、経験の浅いチームよりも早く作業を終える。
- 費用: プロジェクト予算 ― 計画されたテストを実施するために必要な金額。
見積もり方法
一般的なソフトウェアテストの見積もり手法は以下のとおりです。
- 作業分解構造(WBS)。
- 3点推定。
- ワイドバンド・デルファイ。
- 機能点分析またはテストポイント分析。
- ユースケースポイント方式。
- パーセンテージ分布。
- アドホックな方法。
以下の4段階のプロセスは、いくつかの手法を組み合わせて妥当な見積もりを導き出します。この例では、 Guru99 銀行のケーススタディ。
ステップ1)プロジェクト全体をサブタスクに分割する
作業分解図 複雑なプロジェクトをモジュール、サブモジュール、そして最終的には最小単位のタスクに分割する手法。漠然としたプロジェクト全体に対して見積もりを行うよりも、末端レベルで見積もりを行う方がはるかに信頼性が高い。
技術を適用して Guru99バンクプロジェクトを5つの小さなタスクに分割する:
各タスクは、見積もりを行うのに十分な詳細度になるまで、さらにサブタスクに分割されます。
| 仕事 | サブタスク |
|---|---|
| ソフトウェア要件仕様を分析する | 要件仕様を調査する。 |
| ウェブサイトについてさらに詳しく知るために、開発者やその他の関係者にインタビューを行う。 | |
| テスト仕様書を作成する | テストシナリオを設計する。 |
| テストケースを作成する。 | |
| Revテストケースを確認し、修正する。 | |
| テストケースを実行する | テスト環境を構築する。 |
| テストケースを実行します。 | |
| Revテスト実行結果を表示します。 | |
| 欠陥を報告する | 作ります 欠陥 レポート。 |
| 不具合を報告してください。 |
ステップ2)各タスクをチームメンバーに割り当てる
各サブタスクを最も適切な担当者に割り当ててください。
| 仕事 | オーナー |
|---|---|
| ソフトウェア要件仕様を分析する | チームメンバー全員 |
| テスト仕様書を作成する | テスター/テストアナリスト |
| テスト環境を構築する | 試験管理者 |
| テストケースを実行する | テスター、テスト管理者 |
| 欠陥を報告する | テスター |
ステップ3)各タスクの作業量見積もり
この段階では、2つの相補的な手法が効果的です。
- ファンクションポイント法
- 3点推定。
方法1) ファンクションポイント法
テストマネージャーは、各タスクの規模、期間、およびコストを見積もります。
ステップA)タスクの規模を見積もる
「テスト仕様書を作成する」というタスクを例にとってみましょう。その規模は、テスト対象システムの機能規模に依存します。機能が多いほど、システムは複雑になります。機能ポイントは通常、複雑、中程度、単純の3つのグループに分類されます。
テストマネージャーは、複雑さに基づいて各機能ポイントに重みを割り当てます。
| グループ | 重み付け |
|---|---|
| 複雑な | 5 |
| 技法 | 3 |
| 簡単な拡張で | 1 |
その Guru99 Bankのウェブサイトは12の機能ポイントに分かれています。それぞれの複雑さを以下にまとめます。
| # | モジュール | 該当する役割 | 詳細説明 | 重み付け |
|---|---|---|---|---|
| 1 | バランスのお問い合わせ | 顧客担当マネージャー | お客様: 自分の口座の残高のみを表示します。 マネージャー: 監視対象となっているすべての顧客の残高を表示します。 |
3 |
| 2 | 口座振替え | 顧客担当マネージャー | お客様: 自分の口座から任意の宛先へ資金を送金する。 マネージャー: あらゆる送金元からあらゆる送金先へ資金を送金できます。 |
5 |
| 3 | ミニステートメント | 顧客担当マネージャー | アカウントの直近5件の取引履歴。 お客様: 自分のアカウントのみを表示する。 マネージャー: 任意のアカウントを表示する。 |
3 |
| 4 | カスタマイズされたステートメント | 顧客担当マネージャー | 日付または金額で絞り込んだ取引。 お客様: 自分のアカウントのみ。 マネージャー: どのアカウントでも構いません。 |
5 |
| 5 | パスワードの変更 | 顧客担当マネージャー | お客様: 自分のパスワードを変更してください。 マネージャー: 自分のパスワードを変更してください(顧客のパスワードは変更しないでください)。 |
1 |
| 6 | 新規のお客様 | マネージャー | 顧客情報(住所、メールアドレス、電話番号)を追加および編集します。 | 3 |
| 7 | 新しいアカウント | マネージャー | 普通預金口座と当座預金口座。顧客はそれぞれ複数の口座を保有できます。マネージャーは既存顧客向けに新規口座を追加します。 | 5 |
| 8 | アカウントの編集 | マネージャー | 既存のアカウントの詳細を編集します。 | 1 |
| 9 | アカウントを削除する | マネージャー | 顧客の既存アカウントを削除します。 | 1 |
| 10 | 顧客の削除 | マネージャー | アクティブなアカウントがなくなった場合にのみ、顧客を削除してください。 | 1 |
| 11 | 入金 | マネージャー | 支店のどの口座にも現金を入金できます。 | 3 |
| 12 | 撤退 | マネージャー | 支店でどの口座からでも現金を引き出すことができます。 | 3 |
ステップB)タスクの所要時間を見積もる
複雑さを設定したら、各グループのテストに必要な時間を推定します。
- 総努力: ウェブサイトのあらゆる機能をテストするために、あらゆる努力を尽くしました。
- 合計機能ポイント: ウェブサイトの全モジュール。
- ファンクションポイントあたりの見積もり: 1ポイントあたりの平均努力量。チームの生産性によって異なる。
チームのファンクションポイントあたりの見積もりは 5時間/ポイント総努力は Guru99銀行の例は次のとおりです。
| グループ | 重み付け | 機能ポイント | トータル |
|---|---|---|---|
| 複雑な | 5 | 3 | 15 |
| 技法 | 3 | 5 | 15 |
| 簡単な拡張で | 1 | 4 | 4 |
| 機能合計ポイント | 34 | ||
| 1ポイントあたりの見積もり | 5 | ||
| 総推定作業時間(人時) | 170 | ||
「テスト仕様の作成」を完了するための総作業量は約 170人時間必要な労力が分かれば、リソースを割り当てて期間とコストを決定できます。
ステップC)タスクのコストを見積もる
このステップでは、クライアントの2つ目の質問「費用はいくらですか?」に答えます。チームの平均料金を次のように仮定します。 $ 5 /時間上記の作業には170時間かかるため、コストは 170 × $5 = $850すべてのWBSタスクに同じ計算方法を適用して、プロジェクト予算を算出します。
見積もりの精度が高ければ高いほど、プロジェクトの予算管理がしやすくなり、投入したすべての資金が確実に利益を生み出すようになります。
方法2)3点推定
3点見積もりは、テストマネージャーがタスクごとに3つの値を提供する構造化された手法です。 楽観的, 最も可能性が高い, 悲観的 努力 ― 過去の経験または最善の推測に基づく。
「テスト仕様を作成する」の場合、考えられる3つの値は以下のとおりです。
- 最良のケース: 経験豊富な強力なチームで、120人時(約15日間)を要します。
- 最も可能性が高い: 標準的なチームとリソースで、170人時(約21日間)かかる。
- 最悪の場合: 経験の浅いチームでの作業と追加の手戻り作業を含めて、200人時(約25日間)の作業時間。
PERT方式の公式を用いて加重平均を計算します。
値 E は 加重平均 —「テスト仕様書の作成」にかかる概算費用。
自信を表現するために E標準偏差を計算します。
Guru99 銀行の例では、見積もりは次のようになります。 166.6 ± 13.33 人時 — 153.33~179.99人時の範囲。
ステップ 4) 推定を検証する
WBSからすべてのタスクの見積もりを集計し、計画を経営陣(CEO、プロジェクトマネージャー、主要関係者)に提出してレビューと承認を得る。
見積りの内容を論理的に説明し、前提条件、選択した手法、そして組み込んだ予備費について理解してもらえるようにしてください。
テスト見積もりのベストプラクティス
バッファ時間を追加する
計画は現実と向き合うと崩れやすいものです。チームメンバーの離脱、テストの予想超過、依存関係のずれなど、様々な事態が起こり得ます。あらゆる見積もりに適切な余裕を持たせることで、スケジュールに多少の予期せぬ事態にも対応できるようになります。
リソースの可用性を計画する
計画休暇、研修、オンコール勤務のローテーションを考慮に入れること。人員配置を考慮しない見積もりは、机上では見栄えが良くても、実際の運用段階では破綻する。
過去の経験を参考にする
類似プロジェクトの過去のデータは非常に貴重です。昨年、同様のウェブサイトをテストした経験があれば、その実績、発生した問題、そして危機を救った緩衝材から学びましょう。
見積もりはそのままにしておくが、後で見直すことも忘れずに。
推定値はtracts; これらはあくまで推測です。 Rev既知の節目で定期的に訪問し、要件が大幅に変更された場合、または新たな情報によって状況が変わった場合にのみ調整を行う。変更事項については、顧客と透明性をもって協議する。
ソフトウェアテスト見積りテンプレート
ソフトウェアテスト見積もりExcelファイル(.xlsx形式)をダウンロードしてください。
その他の推定手法
WBS、ファンクションポイント、3点見積もりに加えて、他にもいくつかの手法が広く用いられています。
- 広帯域デルファイ: 専門家パネルによる反復的な合意推定。
- ユースケースポイント法: 必要な労力は、ユースケースの数と複雑さによって決まる。
- 割合分布: プロジェクト全体の作業量の一定割合をテストに割り当てる。
- アドホック方式: 過去のデータが不足している場合、専門家の判断が重要となる。
ボトムアップ推定とトップダウン推定の比較
見積もりに関する実践的な見解は、さらに二つの相補的な戦略に分けられる。
- ボトムアップ推定: WBSの最下位レベルのタスクに基づいて算出されます。複数の関係者、経験豊富なスタッフ、貢献者がそれぞれの数値を合算して正確な合計値を算出します。作業内容が十分に理解されている場合に最適です。
- トップダウン推定: プロジェクトを規模と複雑さで分類し、類似した形状の完了済みプロジェクトと比較します。また、平均工数も使用します。 テストケース そして、予測される症例数に応じて規模が調整されます。プロジェクトの初期段階で詳細情報が少ない場合に役立ちます。
ほとんどのチームは、トップダウン方式で主要な数値を算出し、ボトムアップ方式で信頼性を高めるというように、この2つの手法を組み合わせ、予算が許す場合には、その結果に高度なモデルを重ね合わせる。














