ソフトウェアテストの見積り手法
トーマス・ハミルトン
ソフトウェアテストの見積りとは何ですか?
テスト見積もりは、テストの見積もりを近似する管理活動です。 どのぐらいの間 タスクが完了するまでに時間がかかります。 テストの労力の見積もりもその XNUMX つです。 主要な 重要 テスト管理のタスク。
なぜテスト見積りなのか?
潜在的なテスト契約について話し合う際に、クライアントから予想される XNUMX つの質問は次のとおりです。
小規模なプロジェクトの場合、これらの質問に答えるのは比較的簡単です。 しかし、このような大きなプロジェクトの場合、 テスト Guru99 Bank のウェブサイト、これらの質問に答えるには、よく考えなければなりません。
何を見積もるか?
- ＜ご参考＞ リソースが必要となるのは、 実施する あらゆるプロジェクトのタスク。 それらは、人、設備、施設、資金、またはプロジェクト活動の完了に必要なその他の定義可能なあらゆるものです。
- 時間: 時間はプロジェクトにおいて最も貴重なリソースです。 すべてのプロジェクトには納品までの期限があります。
- ヒューマンスキル: ヒューマンスキルとは、 知識 と 体験 チームメンバーの。 それらはあなたの見積もりに影響します。 たとえば、メンバーのテスト スキルが低いチームは、テスト スキルが高いチームよりもプロジェクトを完了するまでに時間がかかります。
- 費用： コストはプロジェクトです 予算。 一般的に言えば、それは、 どの位 お金 プロジェクトを完了するには時間がかかります。
どのように見積もるか?
ソフトウェアテスト見積り手法一覧
- 作業分解図
- ソフトウェアテストの3点見積り手法
- 広帯域デルファイ技術
- ファンクションポイント/テストポイント分析
- 使用 – ケースポイント法
- 割合の分布
- アドホックな方法
見積もりを出すための4つのステップは次のとおりです。
これらのテクニックを組み合わせて、Guru99 Bank のケーススタディの見積もりを見つける方法を学びます。
ステップ 1) プロジェクト タスク全体をサブタスクに分割する
タスクとは、誰かに与えられた仕事のことです。 これを行うには、 作業分解図 技術。
この手法では、複雑なプロジェクトをモジュールに分割します。モジュールはサブモジュールに分割されます。各サブモジュールはさらに機能に分割されます。つまり、プロジェクトタスク全体を 最小 タスク。
作業分解構造を使用して、Guru99 Bank プロジェクトを 5 つの小さなタスクに分割します。
その後、各タスクを次の項目に分割できます。 サブタスク。 このアクティビティの目的は、タスクを作成することです。 詳細な as 可能.
| 仕事 | サブタスク |
|---|---|
| ソフトウェア要件仕様の分析 | ソフト要求仕様の調査 |
| 開発者およびその他の関係者にインタビューして、Web サイトについて詳しく知る | |
| テスト仕様を作成する | テストシナリオの設計 |
| テストケースを作成する | |
| Revテストケースの確認と修正 | |
| テストケースを実行する | テスト環境を構築する |
| テストケースを実行する | |
| Revテスト実行結果を表示 | |
| 欠陥を報告する | |
| 作ります 欠陥 レポート | |
| 欠陥を報告する |
ステップ 2) 各タスクをチームメンバーに割り当てます
このステップでは、各タスクが 適切な プロジェクトチームのメンバー。 次のようにタスクを割り当てることができます
| 仕事 | 加盟国 |
|---|---|
| ソフトウェア要件仕様の分析 | メンバー全員 |
| テスト仕様書を作成する | テスター/テストアナリスト |
| テスト環境を構築する | 試験管理者 |
| テストケースを実行する | テスター、テスト管理者 |
| 欠陥を報告する | テスター |
ステップ 3) タスクの工数の見積もり
タスクの労力を見積もるために適用できる手法が 2 つあります
- 機能点法
- 三点推定
方法1) ファンクションポイント法
この方法では、テスト マネージャーがタスクのサイズ、期間、コストを見積もります。
ステップ A) タスクのサイズを見積もる
In ステップ 1、WBS メソッドを使用して、プロジェクト全体のタスクを小さなタスクに分割しました。 次に、それらのタスクのサイズを推定します。 特定のタスクで練習しましょう」テスト仕様書を作成する
このタスクのサイズは、テスト対象のシステムの機能サイズによって異なります。 機能的なサイズは、 量 ユーザーに関連する機能の。 もっと 数 機能が充実すればするほど、 複雑な システムはです。
実際の見積もりタスクの作業を開始する前に、機能ポイントは次の XNUMX つのグループに分類されます。 複雑な, ミディアムシンプル 次のように：
ソフトウェア機能の複雑さに基づいて、テストマネージャは十分な 体重 各機能ポイントに。 例えば
| グループ | 重み |
|---|---|
| 複雑な | 5 |
| M | 3 |
| 簡単な拡張で | 1 |
より明確にするために、簡単な演習の例を見てみましょう。
Guru99 Bank のウェブサイトのソフトウェア仕様をご覧ください。 こちらソフトウェア エンジニアはすでにソフトウェア モジュールについて詳しく説明していますが、 複雑さ 各モジュールの重み付けを行うことで、Web サイトの機能を評価しますか?
機能ポイントが複雑になればなるほど、テストの手間も増えます。ウェブサイトは 12つの機能 ポイントを決定することができます。 複雑さ 各機能のポイントは次のとおりです。
| いいえ。 | モジュール名 | 該当する役割 | 詳細説明 | 重み |
|---|---|---|---|---|
| 1. | バランスのお問い合わせ | マネージャー
Customer |
お客様： 顧客は複数の銀行口座を持つことができます。 彼は自分の口座の残高のみを表示できます
マネージャー： マネージャーは、自分の監督下にあるすべての顧客の残高を確認できます |
3 |
| 2. | 口座振替え | マネージャー
Customer |
お客様： 顧客は「自分の」口座から任意の宛先口座に資金を送金できます。
マネージャー： マネージャーは、任意の送金元銀行口座から送金先口座に資金を送金できます。 |
5 |
| 3. | ミニステートメント | マネージャー
Customer |
ミニ明細書には、アカウントの最後の 5 つの取引が表示されます
お客様： 顧客は自分の「自分の」口座のみのミニ明細を見ることができます マネージャー： マネージャーは任意のアカウントのミニステートメントを確認できます |
3 |
| 4. | カスタマイズされたステートメント | マネージャー
Customer |
カスタマイズされた明細書を使用すると、日付や取引額に基づいてアカウント内の取引をフィルタリングして表示できます。
お客様： 顧客は「自分の」アカウントのみのカスタマイズされた明細を確認できます マネージャー： マネージャーは、任意のアカウントのカスタマイズされたステートメントを確認できます |
5 |
| 5. | パスワードの変更 | マネージャー
Customer |
お客様： お客様は自分のアカウントのパスワードのみを変更できます。
マネージャー： 管理者は自分のアカウントのパスワードのみを変更できます。 彼は顧客のパスワードを変更できません |
1 |
| 6. | 新規のお客様 | マネージャー | マネージャー： マネージャーは新しい顧客を追加できます。
マネージャー： マネージャーは顧客の住所、電子メール、電話番号などの詳細を編集できます。 |
3 |
| 7. | 新しいアカウント | マネージャー | 現在、システムは 2 種類のアカウントを提供しています
顧客は複数の普通預金口座 (XNUMX つは自分の名前、もう XNUMX つは共同名など) を持つことができます。 彼は、所有するさまざまな会社に対して複数の当座預金口座を持つことができます。 あるいは、複数の当座預金口座と普通預金口座を持つこともできます。 マネージャー： マネージャーは既存の顧客に新しいアカウントを追加できます。 |
5 |
| 8. | アカウントの編集 | マネージャー | マネージャー： マネージャーは既存のアカウントの詳細を追加したり編集したりできます | 1 |
| 9. | アカウントを削除する | マネージャー | マネージャー： マネージャーは顧客のアカウントを追加、削除できます。 | 1 |
| 10. | 顧客の削除 | マネージャー | 顧客は、アクティブな当座口座または普通預金口座を持っていない場合にのみ削除できます。
マネージャー： マネージャーは顧客を削除できます。 |
1 |
| 11. | 入金 | マネージャー | マネージャー： マネージャーはどの口座にもお金を入金できます。 通常、銀行支店に現金を預けるときに行われます。 | 3 |
| 12. | 撤退 | マネージャー | マネージャー： マネージャーはどの口座からでもお金を引き出すことができます。 通常、銀行支店で現金を引き出すときに行われます。 | 3 |
ステップ B) タスクの所要時間を見積もる
分類した上で、 複雑さ 関数点のうち、 デュレーション それらをテストするために。 期間の意味 どの位 タスクを完了するには時間が必要です。
- 総労力: ウェブサイトのすべての機能を完全にテストする取り組み
- 合計機能ポイント: ウェブサイトの総モジュール数
- 関数ポイントごとに定義された推定値: XNUMX つの機能ポイントを完了するまでの平均労力。 この値は、 生産性 このタスクを担当するメンバー。
プロジェクト チームが関数ポイントごとに次のように定義したと推定したとします。 5時間/ポイント。 Web サイト Guru99 Bank のすべての機能をテストするための総作業量は、次のように見積もることができます。
| 重み | ファンクションポイントの数 | トータル | |
|---|---|---|---|
| 複雑な | 5 | 3 | 15 |
| M | 3 | 5 | 15 |
| 簡単な拡張で | 1 | 4 | 4 |
| 機能合計ポイント | 34 | ||
| ポイントごとの推定定義 | 5 | ||
| 推定総工数 (人) Hours) | 170 | ||
したがって、Guru99 Bankの「テスト仕様の作成」タスクを完了するための総労力は約170人時間です。
必要な労力を理解したら、リソースを割り当ててタスクにかかる時間 (期間) を決定し、人件費と人件費以外のコストを見積もることができます。
上の例は、チーム内のメンバーの重要性も示しています。 あなたが持っている場合 有能な 経験豊かな メンバーは、割り当てられたタスクを 小さい そうすれば、プロジェクトは期限かそれより早く終了します。
ステップ C) タスクのコストを見積もる
このステップは、お客様の最後の質問に答えるのに役立ちます。それはどれくらいしますか？"
チームの平均時給が 5 ドルだとします。「テスト仕様の作成」タスクに必要な時間は 170 時間です。したがって、タスクのコストは 5*170 = 850 ドルです。これで、WBS で他のアクティビティの予算を計算し、プロジェクト全体の予算を算出できます。
プロジェクト マネージャーは、 ほとんどの返品 あなたの会社の投資のために。 もっと 正確な プロジェクト費用の見積もりは、 優れた プロジェクトの予算を管理できるようになります。
方法2) XNUMX点推定
XNUMX 点推定は、タスクの推定に使用できる手法の XNUMX つです。 XNUMX 点見積りはシンプルなので、見積りを希望するプロジェクト マネージャーにとって非常に便利なツールです。
三点推定では、 三 値は、以下に基づいてタスクごとに最初に生成されます。 以前の経験 or 最善の推測 次のように
タスクを見積もるとき、テスト マネージャーは、上で指定した XNUMX つの値を提供する必要があります。 特定された XNUMX つの値により、環境で何が起こるかを推定します。 最適な状態、何ですか 最も可能性が高い、または私たちがそれだと思うもの 最悪の場合 シナリオ。
次の例で上記の3つの値をどのように使用するかを見てみましょう。
課題に関しては「テスト仕様書を作成する」という質問に対して、テストの労力を見積もることはできますか? しなければならないことを覚えておいてください すべてをカバーする Guru99 Bank Web サイトのモジュール (以下で実行) ファンクションポイントメソッド
次のように見積もることができます
- 当学校区の 最良の場合 このタスクを完了するには 120 工数（約 15 日）。この場合、才能のあるチームがいるので、最短時間でタスクを完了できます。
- 当学校区の 最も可能性が高い このタスクを完了するケースは 170 工数（約21日）。これは通常のケースであり、タスクを完了するのに十分なリソースと能力があります。
- 当学校区の 最悪の場合 このタスクを完了するには 200 工数（約 25 日）。チーム メンバーに経験がないため、さらに多くの作業を実行する必要があります。
次に、以下のように各パラメータに値を割り当てます
タスクを完了するための労力は次のように計算できます。 二重三角分布 次のような式-
上の式で、パラメータ E は次のようになります。 加重平均。 「テスト仕様書を作成する」というタスクの見積りです。
しかし、上司はあなたに尋ねるかもしれません
上記の推定では、次の値を決定するだけです。 可能 〜ではなく 一定 値について知っておく必要があります。 確率 推定が正しいことを意味します。 他の式を使用することもできます。
上の式では、SD 平均標準偏差、この値から、 確率 推定が正しいことを意味します。
これで、「テスト仕様の作成」タスクの見積もりを完了できます。
Guru99 Bank Web サイトの「テスト仕様の作成」タスクを完了するには、次のものが必要です。 166.6±13.33 工数(153.33～179.99工数)
ステップ 4) 推定を検証する
WBS に記載されているすべてのタスクの集計見積を作成したら、それを担当者に転送する必要があります。 管理委員会、誰が レビュー 承認する ボーマンは
経営委員会のメンバーは、CEO、プロジェクトマネージャー、その他の関係者で構成されます。
管理委員会はあなたの見積り計画を検討し、あなたと話し合います。 あなたは彼らにあなたの見積もりを説明してもよいでしょう 論理的に 適度に あなたの見積もり計画を承認してもらうためです。
テスト見積もりのベスト プラクティス
このトピックでは、テストの精度を推定する方法に関する一般的なヒントを紹介します。
バッファ時間を追加します。
プロジェクトでは、有能なチーム メンバーが突然仕事を辞めたり、テストの完了に予想よりも時間がかかったりするなど、予測できないことが数多く発生する可能性があります。そのため、見積もりにはある程度の余裕を持たせる必要があります。見積もりに余裕を持たせることで、発生する可能性のある遅延に対処できます。
見積もりにおけるアカウントのリソース計画
チーム内の何人かのメンバーが長期休暇を取る場合はどうすればよいでしょうか? プロジェクトが遅れる可能性があります。 見積もりにおけるリソース計画は重要な役割を果たします。 リソースの利用可能性は、見積もりが現実的であることを確認するのに役立ちます。 ここでは、チームメンバーの葉、通常は長い葉を考慮する必要があります。
過去の経験を参考にしてください
時間の見積もりを作成する際には、過去のプロジェクトでの経験が重要な役割を果たします。 プロジェクトによっては類似するものもあるため、過去の見積りを再利用することも可能です。 たとえば、Web サイトのテストなどのプロジェクトを行っていた場合、その経験から学び、過去のプロジェクトで直面したすべての困難や問題を回避するように努めることができます。
自分の見積もりに固執する
上がる可能性もあるので見積りはあくまで見積りです 間違ったプロジェクトの初期段階では、頻繁に テストの見積もりを再確認し、修正を加える 必要に応じて。 要件に大きな変更がない限り、または再見積もりについて顧客と交渉する必要がある場合を除き、修正後に見積もりを延長すべきではありません。
ソフトウェアテスト見積りテンプレート
ソフトウェアテスト見積Excel(.xlsx)をダウンロード
その他のテクニック
ワイドバンド Delphi テクニック、ユースケース ポイント法、パーセンテージ分布、アドホック法は、ソフトウェア エンジニアリングにおけるその他の推定手法です。
ソフトウェアテストの見積もりテクニックのビデオ
ビデオトランスクリプト
- エクササイズをしましょう - 航空券予約申し込み の作業分解構造を準備する
- さまざまなテスト タスク – ログイン機能のチェック、新規注文機能のチェック、FAX 機能のチェック、その他同様の機能のチェック、およびこれらの機能のテストに必要な労力の見積もり
- たとえば、ログイン機能は2時間でテストできます。同様に、すべてのタスクとそれに伴う労力のリストを用意してください。トレーニングチュートリアルを一時停止して、演習を完了してください。必要な労力について、十分な推測ができたと思います。
- これはテスト見積もりのボトムアップ戦略です。 この手法は、作業分解階層の最下位レベルにあるタスクに基づいて、期間、依存関係、およびリソースを見積もるため、ボトムアップと呼ばれます。
- ボトムアップ戦略では、見積もりは XNUMX 人ではなく、すべての関係者、個人の貢献者、専門家、経験豊富なスタッフ メンバーが集合して行われます。 アイデアは、チーム メンバーの協力的な知恵を活用して、正確なテスト推定値を導き出すことです。
- さて、あなたは航空券予約システムに関してかなりの経験を持っています。 この経験を活用して、完全な作業に必要な労力を見積もってください。 機能テスト ウェブサイトの。 – http://newtours.demoaut.com/
- このサイトは Web ベースであるという点を除けば、機能的にはフライト予約アプリケーションと同じです。 チュートリアルを一時停止して、今すぐ演習を行ってください
- あなたの経験に基づいて、Web サイトのテストに必要な労力を適切に見積もっていただければ幸いです
- これは経験に基づいたトップダウンアプローチです。
- もう 1 つの手法は、プロジェクトをその規模と複雑さに基づいて分類し、特定の規模と複雑さのプロジェクトが過去にどれくらいの期間を要したかを確認することです。
- もう XNUMX つのアプローチは、XNUMX 人当たりの平均作業量を決定することです。 テストケース 過去に同様のプロジェクトを実施し、その後現在のプロジェクトの推定テスト ケースを使用して総工数を算出する
- より洗練された推定モデルには、複雑な数学モデルが含まれます。実際には、ほとんどのプロジェクトでは、推定にトップダウン アプローチが使用されています。
- テストの見積もりは、タイミングのプレッシャー、人的要因、テスト チームの地理的分布などの多くの要因の影響を受ける可能性があります。
