プロジェクトのテストに必要なテスターの数を見積もろうとしています。1 つの方法は、必要なスクリプトの数を決定することであり、要件の数と比較してスクリプトの数に経験則があるかどうか疑問に思っていました。2 - 3 と見積もっています。
しかし、それは私の最初の推測です。いくつかのベスト プラクティスがあれば、私はすべて耳にします。繰り返しますが、これは単体テストやシステム テスト用ではなく、ユーザー受け入れテスト用です。
あなたが得る最良の見積もりは、テストを行うテスターから得られます。テスターからのその種の見積もりの外では、開発時間と比較したテスト時間のある種のパーセンテージを考え出すことができるかもしれません.
100 時間の開発タスクがあったとします。設計に 20 時間、構築に 80 時間を費やします。テストに 15 時間、または開発時間の 15% かかるという結論に達することができるかもしれません。UAT テストの全体的な開発見積もりに 15% を適用すると、時間がかかるものもあれば、時間がかかるものもあることがわかります。
Shinyfish さん、公式が欲しいという衝動は理解しています...そして、狭い文脈の外では、一般的な公式は間違いであることが証明できると約束します。すべての要件に N 個のテストを関連付ける必要があると言う人を考えてみてください。ここで、いくつかのサンプル要件を検討してください。
どちらも可能な要件です。1 つ目は、比較的簡単で、賭け金がかなり低いものです。2 番目の方法には多くの潜在的な失敗点があり、多くの場合は成功するが、一見ランダムに見える少数のケースで失敗すると、誰かが死亡することになります。あなたの要求を数えてから何かを掛けるように言う人は誰でも、惑わされているか、ヘビ油を売っています.
同様に、UAT がコーディング時間の 1/N かかるということは、一部のビジネス コンテキストでは有用なヒューリスティック / かもしれませんが、N の値は、たとえばブログ ソフトウェアを作成するスタートアップと、Photoshop の次のバージョンを開発するスタートアップの間で大きく異なります。さらに言えば、UAT が意味するもの (およびユニットとシステムのテストがカバーするもの (カバーしないもの) ) は、同じ用語であなたにアドバイスする人々の意味とは劇的に異なる可能性があります。
テストにかかる時間を見積もるために使用できる経験則は次のとおりです。
まず、可能な範囲で、組織内の同様のプロジェクトを検討してください。
もちろん、比較する関連する以前のプロジェクトがない場合もあります。わからない場合は、見積もりの誤差範囲がはるかに大きくなることがわかります。私が代弁することはできませんが、私が一緒に働いた開発者 (テスター、コーダーなど) の 98.% は慢性的に過小評価しています。それがあなたに当てはまる場合は、それに応じて補償してみてください。おそらく最も重要なのは、見積もりがどれほど正確か (または正確でないか) を理解し、それに応じて利害関係者の期待を設定することです。確実性の幻想を提供することは、誰の役にも立たない。
頑張ってください！
次のことを考慮した上で、いくつかの異なる角度から考えて決定することをお勧めします。
1）エンベロープ計算の裏側...要件ごとに2.5のテストケース（ただし、Jeff Fryの主張は完全ではなく、必要になる場合もあれば、少なくなる場合もあります）
2）1 / N分の時間の答えをすばやく計算します...この一般的なタイプのプロジェクトで、前回、全体的な開発時間および/または全体的なテスト時間の何パーセントを使用しましたか？仕事をうまくやるのに十分でしたか？
3）1時間かけて、Hexawiseなどのテスト設計ツールにパラメーターと値を入力し、単純な2方向（またはペアワイズ）のテスト条件のセットを作成します。そうすることで、通常、最小数のテストが提供されます。これを超えると、通常はカットしたくありません。テストデザインツールを使用することの追加の利点は、規定の要件＃1：「GoogleChromeブラウザを使用するとサイトが正常に見える」および規定の要件＃2：「ユーザーはクレジットカードを変更できること」を確認するだけではないことです。トランザクションの終了時に支払いに使用している」がテストされますが、/ Unstated /要件（誰も含まないと思われる）「GoogleChromeを使用しているユーザーがクレジットカードを変更できることを確認してください」もテストされます同じように。Expediaは明らかにこのアプローチに従わなかったが、私は逸脱する... （関連する補足事項：ペアワイズテスト設計方法またはHexawiseのようなツールを試したことがなく、半自動テストケースの生成を支援したことがない場合は、使用を開始するとテスト効率が大幅に向上することを期待できます。 ;考えられるすべてのペアを達成するために必要なテストは、考えられるよりも少なくなります。適切な例：このタイプの完全なペアワイズカバレッジを達成するために必要なテストは、必要な720億のテストと比較して、わずか35のテストです。 Googleマップの「ルート案内」機能のテストでの包括的なテスト用）。要件のほとんどは、テスト設計ツールに簡単に適合します。一部はしません。使用を開始すると、テスト効率が大幅に向上することを期待する必要があります。考えられるすべてのペアを達成するために必要なテストは、考えられるよりも少なくなります。適切な例：Googleマップの「ルート案内」機能のテストでの包括的なテストに必要な720億のテストと比較して、このタイプの完全なペアワイズカバレッジを達成するために必要なテストは35のみです。要件のほとんどは、テスト設計ツールに簡単に適合します。一部はしません。使用を開始すると、テスト効率が大幅に向上することを期待する必要があります。考えられるすべてのペアを達成するために必要なテストは、考えられるよりも少なくなります。適切な例：Googleマップの「ルート案内」機能のテストでの包括的なテストに必要な720億のテストと比較して、このタイプの完全なペアワイズカバレッジを達成するために必要なテストは35のみです。要件のほとんどは、テスト設計ツールに簡単に適合します。一部はしません。Googleマップの「ルート案内」機能のテストでの包括的なテストに必要な720億のテストと比較して、このタイプの完全なペアワイズカバレッジを達成するために必要なテストは35のみです。要件のほとんどは、テスト設計ツールに簡単に適合します。一部はしません。Googleマップの「ルート案内」機能のテストでの包括的なテストに必要な720億のテストと比較して、このタイプの完全なペアワイズカバレッジを達成するために必要なテストは35のみです。要件のほとんどは、テスト設計ツールに簡単に適合します。一部はしません。
4）3つの見積もりの平均を取り、同様のプロジェクトが大幅に過小評価されている場合は、それに20％を追加します。
ジャスティン
開示：私はHexawiseの創設者であり、www.hexawise.com / users/newでテストデザインツールの無料バージョンを提供しています。