推定手法-テスト

テストの取り組みは、明確な時間枠に基づいていません。テストの完了に関係なく、事前に決定されたタイムラインが設定されるまで、取り組みは継続されます。

これは主に、従来、 test effort estimation の一部です development estimation。Wideband Delphi、Three-point Evaluation、PERT、WBSなどのWBSを使用する推定手法の場合にのみ、テストアクティビティの推定値を取得できます。

ファンクションポイント（FP）として見積もりを取得した場合は、CaperJonesに従って次のようになります。

Number of Test Cases = (Number of Function Points) × 1.2

テストケースの数が決まったら、組織のデータベースから生産性データを取得して、テストに必要な作業に取り掛かることができます。

開発努力法の割合

必要なテスト作業は、開発作業の直接的な割合または割合です。開発作業は、コード行（LOC）またはファンクションポイント（FP）を使用して見積もることができます。次に、テストの労力の割合が組織データベースから取得されます。そのようにして得られたパーセンテージは、テストの作業量の見積もりに到達するために使用されます。

テストプロジェクトの見積もり

現在、いくつかの組織がクライアントに独立した検証および妥当性確認サービスを提供しています。これは、プロジェクト活動が完全にテスト活動になることを意味します。

テストプロジェクトを見積もるには、ソフトウェアテストライフサイクルのさまざまなプロジェクトでの経験が必要です。テストプロジェクトを見積もるときは、次のことを考慮してください。

チームスキル
領域知識
アプリケーションの複雑さ
歴史的なデータ
プロジェクトのバグサイクル
リソースの可用性
生産性の変動
システム環境とダウンタイム

推定手法のテスト

以下のテスト推定手法は正確であることが証明されており、広く使用されています。

PERTソフトウェアテスト推定手法
UCPメソッド
WBS
広帯域デルファイ技術
ファンクションポイント/テストポイント分析
パーセンテージ分布
経験に基づくテスト推定手法

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

PERTソフトウェアテスト推定手法は、各テストタスクをサブタスクに分割し、各サブタスクで3種類の推定を行う統計手法に基づいています。

この手法で使用される式は次のとおりです。

Test Estimate = (O + (4 × M) + E)/6

どこ、

O =楽観的な見積もり（何も問題がなく、すべての条件が最適である最良のシナリオ）。

M =最も可能性の高い見積もり（最も可能性の高い期間であり、問題がある可能性がありますが、ほとんどのことがうまくいきます）。

L =悲観的な見積もり（すべてがうまくいかない最悪のシナリオ）。

手法の標準偏差は次のように計算されます-

Standard Deviation (SD) = (E − O)/6

ユースケースポイント法

UCPメソッドは、未調整のアクターの重みと未調整のユースケースの重みを計算してソフトウェアテストの見積もりを決定するユースケースに基づいています。

ユースケースは、関連するアプリケーションと対話するさまざまなユーザー、システム、またはその他の利害関係者を指定するドキュメントです。彼らは「俳優」と名付けられています。相互作用は、シナリオと呼ばれるさまざまな動作またはフローを通じて、すべての利害関係者の利益を保護するいくつかの定義された目標を達成します。

Step 1−番号を数えます。俳優の。アクターには、ポジティブ、ネガティブ、例外が含まれます。

Step 2 −未調整のアクターの重みを次のように計算します

Unadjusted Actor Weights = Total no. of Actors

Step 3 −ユースケースの数を数えます。

Step 4 −未調整のユースケースの重みを次のように計算します

Unadjusted Use-Case Weights = Total no. of Use-Cases

Step 5 −未調整のユースケースポイントを次のように計算します

Unadjusted Use-Case Points = (Unadjusted Actor Weights + Unadjusted Use-Case Weights)

Step 6−技術的/環境的要因（TEF）を決定します。利用できない場合は、0.50とします。

Step 7 −調整されたユースケースポイントを次のように計算します

Adjusted Use-Case Point = Unadjusted Use-Case Points × [0.65 + (0.01 × TEF]

Step 8 −総労力を次のように計算します

Total Effort = Adjusted Use-Case Point × 2

作業分解図

Step 1 −テストプロジェクトを細かく分割してWBSを作成します。

Step 2 −モジュールをサブモジュールに分割します。

Step 3 サブモジュールをさらに機能に分割します。

Step 4 −機能をサブ機能に分割します。

Step 5 −すべてのテスト要件を確認して、それらがWBSに追加されていることを確認します。

Step 6 −チームが完了する必要のあるタスクの数を把握します。

Step 7 −各タスクの労力を見積もります。

Step 8 −各タスクの期間を見積もります。

ワイドバンドデルファイテクニック

ワイドバンドデルファイ方式では、WBSは、タスクを再推定するために3〜7人のメンバーで構成されるチームに配布されます。最終的な見積もりは、チームのコンセンサスに基づいて要約された見積もりの結果です。

この方法は、統計式ではなく、経験について詳しく説明します。この方法は、チームがテストの労力を見積もりながら問題のさまざまな側面を視覚化するコンセンサスに到達するためのグループ反復を強調するために、BarryBoehmによって普及しました。

ファンクションポイント/テストポイント分析

FPは、ユーザーの視点からソフトウェアアプリケーションの機能を示し、ソフトウェアプロジェクトのサイズを見積もる手法として使用されます。

テストでは、見積もりは要件仕様書、または以前に作成されたアプリケーションのプロトタイプに基づいています。プロジェクトのFPを計算するには、いくつかの主要なコンポーネントが必要です。彼らは-

Unadjusted Data Function Points − i）内部ファイル、ii）外部インターフェース
Unadjusted Transaction Function Points − i）ユーザー入力、ii）ユーザー出力、iii）ユーザーからの問い合わせ
Capers Jones basic formula −

テストケースの数=（ファンクションポイントの数）×1.2
Total Actual Effort (TAE) −

（テストケース数）×（開発努力率/ 100）

パーセンテージ分布

この手法では、ソフトウェア開発ライフサイクル（SDLC）のすべてのフェーズに％単位の作業が割り当てられます。これは、同様のプロジェクトの過去のデータに基づくことができます。例-

段階	努力の％
プロジェクト管理	7％
要件	9％
設計	16％
コーディング	26％
テスト（すべてのテストフェーズ）	27％
ドキュメンテーション	9％
インストールとトレーニング	6％

次に、テストの労力の割合（すべてのテストフェーズ）がすべてのテストフェーズにさらに分散されます-

すべてのテストフェーズ	努力の％
コンポーネントテスト	16
独立したテスト	84
Total	100

独立したテスト	努力の％
統合テスト	24
システムテスト	52
受け入れ試験	24
Total	100

システムテスト	努力の％
機能システムテスト	65
非機能的なシステムテスト	35
Total	100

テスト計画と設計アーキテクチャ	50％
レビューフェーズ	50％

経験に基づくテスト推定手法

この手法は、類推と専門家に基づいています。この手法は、以前のプロジェクトで同様のアプリケーションをすでにテストし、それらのプロジェクトからメトリックを収集したことを前提としています。また、以前のテストからメトリックを収集しました。アプリケーション（およびテスト）をよく知っている対象分野の専門家から入力を受け取り、収集したメトリックを使用して、テスト作業に到達します。