ソフトウェアテスト推定技術(テスト努力推定完全ガイド)

プロジェクトを成功させるためには、テストの推定と適切な実行は、開発サイクルと同じくらい重要です。 見積もりに固執することは、クライアントとの良好な評判を構築するために非常に重要です。

経験は、”ソフトウェアテストの取り組み”を推定する上で大きな役割を果たしています。 様々なプロジェクトに取り組むことは、テストサイクルの正確な推定を準備するのに役立ちます。

明らかに、テストタスクに盲目的に日数を置くことはできません。 テスト推定は、現実的かつ正確でなければなりません。

このチュートリアルでは、非常に簡単な方法で正確なテスト推定を準備するのに非常に役立ついくつかの重要なポインタが含まれます。

テスト推定プロセス

“推定は、入力データが不完全、不確実、または不安定であっても、何らかの目的のために使用可能な値である推定値、または近似を見つけるプロセスである。”

私たちは皆、専門家としての生活の中でさまざまな仕事、義務、期限に遭遇しますが、現在は問題の解決策を見つけるための二つのアプローチがあります。

最初のアプローチは、問題が到着した後にのみ手元にある問題の解決策を見つけようとする反応的なアプローチです。

積極的なアプローチと呼ばれる第二のアプローチでは、まず過去の経験で問題が到着する前に準備し、過去の経験で問題が到着したときに解決策を見つしたがって、

推定は、問題に対する積極的なアプローチを取るときに適用される技術と考えることができます。

したがって、推定を使用して、定義されたタスクを完了するために必要な時間とコストに関するどのくらいの労力を予測することができます。 テストチームが手元にある問題の推定を行うことができれば、手元にある問題に最適な解決策を考え出すことが容易になります。

推定の実践は、より形式的には、作業の可能性のあるコストの近似計算として定義することができます。

また、read=>Selenium Automation Projectのテスト推定に影響を与える7つの要因

基本的な前提条件

以下は、テスト推定プロセスの基本的な前提条件です。

#1) 過去の経験での作業から収集された洞察：手元にある現在の努力に似た課題を提起した過去のプロジェクトを思い出して、時間を費やすことは常に

#2)利用可能な文書または成果物: テスト管理リポジトリツールは、要件と明確化ドキュメントを格納するため、これらのタイプのシナリオで便利です。 これらの文書は、プロジェクトの範囲を明確に定義するためにテストチームが参照することができます。

#3)仕事の種類についての仮定:過去の実務経験は、プロジェクトについての前提を作るのに役立ちます。 これは、経験豊富な専門家を雇うことが最も重要です。 テストのマネージャーは望ましい結果を提供するためにこれらの人々の頭脳を選ぶことができる。

#4)潜在的なリスクと脅威の計算: テストチームはまた、潜在的なリスクと脅威、そして将来のチームのために嘘をつく可能性のある落とし穴を視覚化する必要があります。

#5)文書がベースライン化されているかどうかの判断:テストチームはまた、要件がベースライン化されているかどうかを判断する必要があります。 文書がベースライン化されていない場合は、変更の頻度を決定することが重要です。

#6)すべての責任と依存関係は明確でなければならない:組織は、推定プロセスを実行するすべての人の役割と責任を明確に定義する必要があります。

#7)推定記録の文書化と追跡:推定プロセスに関連するすべての情報を文書化する必要があります。

#8)テスト推定プロセス中に実行されるアクティビティ:

• 見積もりを実行するチームを編成します。
• プロジェクトをプロジェクトフェーズとその後の構成活動に分解する。
• これまでのプロジェクトと専門的な経験に基づいて推定を計算します。
• 可能性のある脅威に優先順位を付け、それらのリスクを軽減するためのアプローチを考え出します。
• 作品の関連部分をレビューし、文書化する。
• 関連する利害関係者に作品を提出してください。

最も顕著なテスト推定技術

テスト推定のための最も重要な技術のいくつかは次のとおりです:

• テストポイント推定
• 作業フェーズベース推定
• ユースケースポイント推定

これらの手法をどのように、どこで使用するのですか:

#1) テストポイント推定は、ソフトウェアテストのスペクトル全体で広く使用されている、シンプルでわかりやすい推定手法です。 反復フェーズと単純さは、この特定の手法の最も重要な特徴です。

#2)作業フェーズベース推定とは、特定のフェーズ（通常はフェーズの中で最も短く、最も単純なもの）で推測推定を行い、テストチームが徐々に他のフェーズを初期推定に追

#3)ユースケースポイント推定技術は、未調整のアクター重みと未調整のユースケース重みを使用してソフトウェアテスト推定を決定するユースケースの推定です。

テストポイント推定技術の詳細

テストポイント推定技術は、以下の手順に従って行われます:

(これらの重みのいくつかは、コードの複雑さに基づくプログラミング言語の重み、アプリケーションの種類に基づくアプリケーションの重み、およびソフ)

未処理のテストポイントにCWFを乗算して、テストポイントのサイズでテストサイズを取得します。

生産性係数は、テストエンジニアが1つのテストポイントのテストを完了するまでの時間を示します。

人の時間でのテスト努力は、テストポイントのサイズに生産性係数を乗算することによって計算されます。

テストポイント推定手法の計算のために、以下の変数を考慮します。

• テスト要件の複雑さ

• 他の要件とのインターフェイス

• 検証ポイントの合計数

• ベースラインテストデータ

次に、各データ変数の重みベクトルを考慮し、次の方法で編成する必要があります。

調整係数=(複雑さの重みと因子の重みの積)/30

テストケース設計の調整テストポイント=合計テストポイントX(1+テス

合計テストポイント(正規化)x(1+テストケース設計/実行の調整係数)=テストケース設計/実行の調整されたテストポイント

総努力の 人時間（PH）=正規化されたテストポイントの数/生産性（人時間あたりの正規化されたテストポイントで）

テスト推定例

上記の定式化を別の実用に適用してみましょう。

5つのテストシナリオをテストするテスト要件になったとします。

さて、テストシナリオ1には5つのテスト期待結果があり、テストシナリオ2には6つのテスト期待結果があり、テストシナリオ3には2つのテスト期待結果のみがあり、テストシナリオ4には9つのテスト期待結果があり、テストシナリオ5には9つのテスト期待結果があるとしましょう。

テストシナリオは、これらの三つのクラスに存在する期待される結果の総数に基づいて、三つのクラス、すなわち複雑、単純、中moderateに分類されます。

複雑なクラスは7つ以上の期待される結果を持ちますが、単純なクラスは5つ未満の期待される結果で構成され、中程度のシナリオは4から7つの期待される結果で構成されます。

このように、テストシナリオ1とテストシナリオ2を中程度のシナリオ、シナリオ5とシナリオ6を複雑なシナリオ、テストシナリオ3を単純なシナリオに分類します。

ここで、これらすべてのシナリオにテストポイントを適用します。 複雑なクラスには5つのテストポイント、中程度のクラスには3つ、単純なシナリオには2つのテストポイントを適用しました。

想定されるテストポイントに、これらすべてのテストシナリオで予想される結果の合計数を掛けます。 したがって、次の近似値になります。

シナリオ1：3テストポイント*5テスト予想結果=調整済みテストポイント=25
シナリオ2：3テストポイント*6テス: 2テストポイント*2テスト予想結果=調整済みテストポイント=4
シナリオ4:5テストポイント*9テスト予想結果=調整済みテストポイント=45
シナリオ5:5テストポイント*9テスト予想結果=調整済みテストポイント=45

だから、調整済みテストポイントごとに5人の時間を申請する必要があることを考慮すると、次のおおよその結果が得られます。

テストシナリオ1:25調整テストポイント*5人時間=125人時間
テストシナリオ2:30調整テストポイント*5人時間=150人時間
テストシナリオ3: 4調整されたテストポイント*5人の時間=20人の時間
テストシナリオ4:45調整されたテストポイント*5人の時間=225人の時間
テストシナリオ5:45調整されたテストポイント*5人の時間=225人の時間

だから、合計おおよその人時間は745人の時間

ユースケースポイント推定方法

ユースケースポイント方法は、ユースケースまたは要件に基づいて全体的なテスト推定作業を計算するユースケース。

以下は、ユースケースポイント推定方法の詳細なプロセスです:

同じ例は、特定の要件では、それぞれ5つのユースケース、ユースケース1、ユースケース2、…、ユースケース5があるということです。 ここで、ユースケース1は6人のアクターで構成され、ユースケース2は15人のアクターで構成され、ユースケース3、4、5、3、4、5のアクターで構成されていると考えてみましょう。

アクタの総数が5未満のユースケースは負、アクタの総数が5以上10以下のユースケースは正、アクタが10以上のユースケースは例外とみなします。

例外的なユースケースには2点、正のユースケースには1点、負のユースケースには-1点を割り当てることにしました。

したがって、上記の仮定に基づいて、ユースケース1と5を正、ユースケース2を例外、ユースケース3、4を負に分類します。

したがって、未処理のアクターの重み=ユースケース1=(アクターの総数)5*1(割り当てられたポイント)=5. 同様に

ユースケース2=15*2=30。

残りのユースケースでプロセスを繰り返すと、未処理のアクター weights=33

未処理のユースケースweight=total noを受け取ります。 使用例=5

未処理の使用例ポイント=未調整のアクターウェイト+未調整の使用例ウェイト= 33 + 5 = 38

処理されたユースケースポイント=38*=26。7または28人の時間約

作業相破壊技術

作業相破壊技術は、以下の手順で説明できます。

• 全体の作業を段階的に分解します。
• 最も単純な位相から開始し、それに近似推定値を割り当てます。
• 次に、このフェーズが完了すると開始できる次の可能なフェーズを特定します。
• この位相に適用できる近似値の可能なセットを導出し、導出されたすべての近似値の中から最大値を選択します。
• 既存の値に現在の位相努力推定値を加算することにより、近似推定値を合計します。
• 最初のステップで特定されたすべてのフェーズが終了するまで、ステップ3から5に進みます。
• 最終的なおおよその推定値を最終的なものとして受け入れます。

要件には5つの必要なフェーズがあるとします。 最初のフェーズ1では、必要な総労力が35人時間であると仮定し、次のフェーズ2を開始し、それぞれ35、45、55、および65の4つの比較仮定があります。

ここでは最大値である65人時間を考慮します。 フェーズ3、4、5では、我々は推定値を思い付く(12 , 33, 43 , 54) , (15 , 10 , 7 , 8) それぞれ（2、16、5、13）。 上記の原則を適用することによって、私たちはそれぞれ185人の時間で終わります。

私は情報を入れています–どのように私は私の経験から学んだ任意のテストタスクのためのテストの努力を推定するために、。

9テスト時間を正確に推定する方法に関する一般的なヒント

ソフトウェアテスト推定に影響を与える要因、および正確に推定する一般的なヒント:

#1) いくつかのバッファ時間を考えてみてください：推定にはいくつかのバッファが含まれている必要があります。 しかし、現実的ではないバッファを追加しないでください。 推定にバッファを持つことで、発生する可能性のある遅延に対処することができます。 緩衝を持っていることはまた最高のテスト適用範囲の保障を助ける。

#2)バグサイクルを考慮する：テスト推定にはバグサイクルも含まれています。 実際のテスト周期は推定より多くの日を取るかもしれません。

これを回避するには、テストサイクルがビルドの安定性に依存するという事実を考慮する必要があります。 ビルドが安定していない場合、開発者はそれを修正するためにより多くの時間を必要とする可能性があり、明らかに、テストサイクルは自動的に延

#3)推定期間のすべてのリソースの可用性: テストの推定では、今後数週間または数ヶ月以内にチームメンバーによって計画されたすべての葉（通常は長い葉）を考慮する必要があります。 これにより、推定が現実的であることが保証されます。

推定は、テストサイクルのためのいくつかの固定数のリソースを考慮する必要があります。 リソースの数が減少した場合は、推定を再訪問し、それに応じて更新する必要があります。

#4)並列テストはできますか？ 出力を比較できるように、同じ製品の以前のバージョンがありますか？ はいの場合、これによりテスト作業が少し簡単になります。 製品のバージョンに基づいて推定を考える必要があります。

#5)推定は間違っている可能性があるので、コミットする前に初期段階で頻繁に推定を再訪問する：初期段階では、テスト推定を頻繁に再訪問し、必要に応じて修正を行う必要がある。 要件に大きな変更がない限り、一度凍結した見積もりを拡張すべきではありません。

#6)あなたの過去の経験を考えて判断を下す！ 過去のプロジェクトからの経験は時間の見積もりを準備している間重大な役割を担う。 私たちは、過去のプロジェクトで直面したすべての困難や問題を回避しようとすることができます。 私たちは、以前の見積もりがどのようにあったか、彼らが時間通りに製品を提供するためにどのくらい助けたかを分析することができます。

#7)プロジェクトの範囲を考慮する：プロジェクトの最終目標とすべての最終成果物のリストが何であるかを知る。 小規模プロジェクトと大規模プロジェクトで考慮すべき要因は大きく異なります。 大規模なプロジェクトには、通常、テストベッドの設定、テストデータの生成、テストスクリプトなどが含まれます。

したがって、推定はこれらすべての要因に基づいている必要があります。 小規模なプロジェクトの場合、通常、テストサイクルにはテストケースの作成、実行、回帰が含まれます。

#8)負荷テストを実行するつもりですか？ パフォーマンステストにかなりの時間を費やす必要がある場合は、それに応じて推定します。 負荷テストを伴うプロジェクトの推定は、別の方法で考慮する必要があります。

#9)あなたのチームを知っていますか？ チームで作業する個人の長所と短所がわかっている場合は、テストタスクをより正確に見積もることができます。 推定しながら、すべてのリソースが同じ生産性レベルをもたらすわけではないという事実を考慮する必要があります。

一部の人は他の人と比較してより速く実行できます。 これは大きな要因ではありませんが、成果物の総遅延に加算されます。

結論

ソフトウェアテスト推定は、経験豊富な専門家の関与だけでなく、テストケースポイントやユースケースポイントメソッドのような業界全体のベス

必要なプロセスをカスタマイズするためのオープンマインドを採用することも重要です。 これらのプロセスの実装が成功すると、テストプロセスの全体的な改善につながります。

これは著者”N.Sandhya Rani”によるゲスト記事です。