ソフトウェアテストにおけるさまざまな種類の推定技術
ソフトウェアテストの推定は、制御された環境でプロセスを開始および終了するために必要なおおよその時間枠を決定するために使用される不可欠な管理操作です。
どのプロジェクト計画においても、制限時間を過ぎず、予算を設定し、利用可能なリソースを設定しないことが重要です。 ここで最も有用なタスクの1つは、テストに費やされる努力に照らしてリソースをチェックすることです。
UTORのエンジニアは、ソフトウェアテスト中に異なるタイプの推定技術を活用することがよくあります。 これらの方法は私達の顧客によって有効ように確認されました。 したがって、私たちはそれらの上に行き、あなたがそれらを最高に実装する方法を知らされるように、彼らの具体的な長所と短所を明らかにします。
ソフトウェアテストの見積もりとは何ですか？
ソフトウェアテスト推定は、ソフトウェア上で完全なテストを実行するために必要な期間とアクションを測定し、管理するプロセスです。
時間と労力は、小規模な割り当てのために計算するのがかなり簡単です。 しかし、大規模なプロジェクトのために。 間違いがなされないように有効な作戦は所定の位置になければならない。 過小評価されたり過大評価されたりすると、そのようなプロジェクトのテストリソースが不十分になるか、完全に誤用されます。
チームはソフトウェアテストリソースをどのように見積もるのですか？
テストが始まる前に、すべてが依存し、テスターとクライアントの間でアイロンをかけなければならない二つの非常に重要な不確実性があります。 これらは次のとおりです;
- 完全な手順の合計推定期間は何ですか？
- お金と資源の面で見積もられた手続きコストの合計は何ですか？
時間、リソース、コスト、および人間のスキルは、通常、テストの推定中に決定されます。
時間
チームの努力の有効性は、通常、期限内または期限前に設定された時間枠内で提供する能力によって判断されます。
手元のプロジェクトの各セクションの標準的な必要な期間を確認した後、プロジェクトマネージャーは各プロジェクトをスケジュールするための手段を開発します。
彼はすべてが時間通りに配信されることを保証します。 このため、時間推定は、顧客の間で直立評判を構築し、忠実なクライアントのかなりの数を持つ上で不可欠な要因の一つです。
リソース
プロジェクトに着手する前に、利用可能なリソース、含まれるべきリソース、すぐに利用できない場合は推奨される代替物を確認することが必須 これを確認しないと、締め切り前にプロジェクトが終了しない可能性が最も高いです。
コスト
テストプロセスの準備中は、すべての面（財務および非財務の両方）で推定予算を完全に考慮する必要があります。
総コストは、可能な支出に注意し、プロジェクトがクライアントの規定された予算内にとどまることを確認するために考慮する必要があります。
言及されたフィールドはすべて関連しており、それ自体に相互依存しています。 それがかかる期間は、利用可能なツールと与えられた予算にもかかっています。
時間の経過とともに、ソフトウェアテスト推定に関わる手順は、同じ理由で時間とともに進んだ様々な方法論とツールを使用して、異なるプロセスで行
これらの手法の統合と作業により、平均化手順もはるかに簡単になりました。
ソフトウェアテスト推定技術の種類
一般的には多くの推定技術と平均化技術がありますが、この記事の多くのうち、いくつかの人気のあるもの
Program evaluation and review technique(PERT)
この手法では、タスクを3つのサブカテゴリに分けて、完了にかかる時間をよりよく確認します。
楽観的なシナリオ-O;この場合、プロジェ これは、QAチームの個々のメンバーが、圧力、予測不可能な出来事のターン、または行われた仕事を再訪し、まだ素晴らしい仕事を提供する必要がなく、時間を維持し、
最も可能性の高いシナリオ-M;ここでは、すべてのものが考慮されます;おなじみの仕事のシナリオを念頭に置いて、負と肯定的な可能性を念頭に置いて、項目はそれがどのように起こる可能性が最も高いかを推定されます。
悲観的なシナリオ-P;これは、可能性のある最も否定的なシナリオを考慮しています。 平均化は、テスト全体のすべての単一の段階で対処すべき否定的な結果が確実に存在するという前提に基づいてヒンジされます。
PERTの長所
- この手法を使用すると、チームはすべての可能性のある死亡者と報酬をすべての面でチェックする推定で作業することになります。
- チームは現実に近い評価を思いつくことができます。
- 組織は、考えられるシナリオをそれぞれ計算し、必要に応じてそれを抑制するために適切に準備するときに、ビルドテストの可能な結果を準備します。
PERTの短所
- 大きなテストプロジェクトに直面した場合、この形式の見積もりを使用すると、受けるのにはるかに多くの時間が消費されます。
- 不正確な計算が発生する可能性が高い。
- ここで使用される値は決して一定ではなく、結局のところ推定に過ぎないため、多くのエラーが発生する可能性があります。
User Case Point(UCP)
誰かまたは何かが問題のアプリケーションを使用して通信するたびに、エンティティはアクターとして識別されます。 当該エンティティは、主に、プロセスの能力に影響を与える調整不可能なユースケースの重みで文書化されています。
その間のコミュニケーションは、さまざまなシーケンスと定義された目標を通じて、QAチームの株主から個人へのすべての関与を保護します。
10人以上の異なるエージェントがプロジェクトの専門性の複雑さに影響を与え、約8人が環境的に複雑な被害を受けます。 これはGustav Karnerの調査結果と一致しています。
この推定方法は、プロセス、専門性、およびその他の要因に影響を与える、いわゆるアクター、ユーザーケースウェイト、およびポイントから複数のバリアントを計算することに依存します。
まず、このプロセスを開始するには、それぞれの複雑さをクロスチェックし、プロセスに影響を与えなければなりません。 その後、さらに平均化は、計算のためにそれらの式を適用することによって行われます。
プロジェクトの規模を確認した後、関係者はプロセスが完了するまでに必要な時間を決定します。 これを防止する2つの重要な方法は次のとおりです。;
Karnerの方法を使用し、各テストケースを20人のスタッフ時間を消費すると考えています。
いずれにしても、プロジェクト完了のための会社の記録時間を使用して、統計的平均を計算し、現在のプロジェクトの期間を推測します。
UCP=調整不可能なUCP x技術的な複雑さ係数x環境に影響を与える係数。
UCPの長所
- 事前に作業し、事前に計画する必要がある場合は、この推定方法は初期段階で行われ、予算サイズの剪定と承認に役立ちます。
- いくつかの特別な管理ツールの助けを借りて、見積もりの自動計算が可能であり、評価チームのための多くの時間を節約し、仕事を容易にします。
:
- プロジェクト要件がユーザーのケースポイントに与えられていない場合、この手法を使用することは不可能になり、QAチームは別の方法を調達する必要が
- UCPが与えられ、それらが十分に正確または明示的でない場合、この方法はケースポイントを与えるだけでなく、明確なケースポイントを与えることに依存するため、実際から遠く離れた推定値で否定的に終わる可能性が最も高い。
ワークブレークダウン構造(WBS)
ここでは、値を推定する手法は、一次プロセスを異なるサブカテゴリに分割することによって行われます。 各ステージの平均持続時間の予測計算は、徐々に多くの単純なものの大まかな作業から始まり、その後、難易度と正確さのレベルの両方で卒業します。
最初のプロセスの後、到達した可能な限り高い値を選択し、それらを加算して最終的な値を取得し、各タスクに必要な労力と時間を推定します。
WBSの長所
- この方法の明らかな利点は、労力をより小さなビットに分割しながら、毎分と必要な詳細を見つけやすくすることです。 これは、作業が行われていることを意味します
- 結論は同じ目的のために集計され、追跡が容易であるため、常に徹底して透明です。
:
- この性質は、通常、心をこすり、チームメンバーと利害関係者が外部の経験からタップする必要があります。
- 仕様やクライアントのニーズの変更は時代遅れになり、チームがそれを調べて完全に再評価する必要があります。
Delphiメソッド
Delphiメソッドは、世界中のテストチームの間で非常に人気があります。 自発的なpartakersからのデータは、いくつかの照合され、密接に検討され、特定の順序ではなく、合意された結論に到達します。
検査の各段階は、新しいまたは改善されたデータフィードバックをもたらし、最終的な調査結果の洗練に大いに値する自信を持って追加するだけです。
通常、チームは10人以下の個人で構成され、プロジェクトに着手しようとしているプロジェクトの重要な特徴について話し合い、プロジェクトの可能性のある期間について意見を述べるために会合します。
その後、チームは再び会合を開き、今回は初デートからの意見が共有される。 これはメンバーにプロジェクトのアプローチの別の角度を与える。 ただし、ビューはサジェスタにタグ付けされません。
チームメンバーがこの段階を経ているとき、彼らは別の全会一致の議論を持ち、意見の照合は新しい知覚の角度を考慮に入れます。
これは誰もが同じページに同意するまで続きます。 Delphiメソッドを実行する通常の方法ですが、このフォームはそのニーズと機能に合わせて微調整できます。
DELPHIの長所
- ここではユニークな数式や機器は必要ないので、どのチームにとっても最も簡単に受けることができます。
- 会議やアイデア共有のプロセスでは多くの専門的な視点が考慮されるため、推定は正確さにかなり近いものです。
DELPHIの短所
- それを受けるのは簡単ですが、多くの場合、生産的な時間がかかることがあります。
- 会議の最初のバッチの後に一つの包括的な見積もりを考え出し、意見を共有するのは難しいので、通常はいくつかかかります。
- そんなに時間をかけても、結果は再利用できません。 したがって、すべてのプロジェクトを実行するために、プロセスは新しい要件で新たに開始されます。
要約すると、
このブログ記事では、ソフトウェアテストにおける四つのタイプの推定技術と、それらが合理的なテスト予算を計画する上でどのように影響を与えているかをレビューしました。
見積もりが成功した後、あなたのプロジェクトをQA企業にアウトソーシングするための正しいアプローチを確かに言うことができますか？
ここでは、QAアウトソーシングのための最良のアプローチを選択する方法についての記事です。
あなたが実装しているこれらのテスト推定戦術のどれを教えてください、そしてあなたの洞察は何でしたか？