私の経験から、分析には25％の努力が費やされています。設計、開発、単体テストの50％。テスト用に残り25％。ほとんどのプロジェクトは、プロジェクトの性質、リソースの知識、入力と出力の品質などに応じて、この経験則の+/- 10％の範囲内に収まります。これらの割合内で、または10〜15％の範囲内の上部のオーバーヘッド。
Googleテストブログ 最近この問題について説明しました ：
素朴な答えは、ライティングテストには10％の税金がかかるということです。しかし、私たちは何かを得るために税金を支払います。
（をちょきちょきと切る）
これらの利点は、今日だけでなく明日にも真の価値をもたらします。テストを作成します。これは、10％の追加コストを相殺する以上のメリットがあるためです。長期的なメリットを含めなくても、今日のテストから得られる価値は十分に価値があります。テストを使用してコードを開発する方が速いです。どのくらいか、それはコードの複雑さに依存します。構築しようとしているものが複雑であればあるほど（より多くのifs/loops/dependencies）、テストの利点は大きくなります。
テストを見積もる場合、テストの範囲を特定する必要があります。ユニットテスト、機能、UAT、インターフェイス、セキュリティ、パフォーマンスストレス、ボリュームについて話しているのでしょうか。
ウォーターフォールプロジェクトに参加している場合は、おそらく一定のオーバーヘッドタスクがいくつかあります。計画文書、スケジュール、およびレポートを準備する時間を確保してください。
機能テストフェーズ（私は "システムテスター"であるため、これが私の主要な参照ポイントです）計画を含めることを忘れないでください！多くの場合、テストケースは、要件/仕様/ユーザーストーリーから抽出するために実行するのと同じくらいの労力を必要とします。さらに、欠陥の発生/再テストのための時間を含める必要があります。大規模なチームでは、テスト管理（スケジューリング、レポート、会議）を考慮する必要があります。
一般的に、私の見積もりは、開発作業の割合ではなく、提供される機能の複雑さに基づいています。ただし、これには少なくとも高レベルの命令セットへのアクセスが必要です。何年ものテストを行うことで、特定の複雑さのテストが準備と実行にx時間の労力を要することを理解することができます。一部のテストでは、データのセットアップに余分な労力が必要になる場合があります。一部のテストには、外部システムとのネゴシエーションが含まれ、必要な労力をはるかに超える時間がかかる場合があります。
ただし、最終的には、プロジェクト全体のコンテキストでレビューする必要があります。 BAまたは開発の見積もりが十分に上回っている場合は、基礎となる仮定に何か問題がある可能性があります。
これは古いトピックですが、現時点で再検討しているものであり、プロジェクトマネージャーにとっては長年の関心事です。
数年前、安全が重要な分野で、10行のコードを単体テストするためのある日を聞いたことがあります。
また、開発に50％、テストに50％の努力を費やしました（単体テストだけでなく）。
自動化された単体/統合テストまたは手動テストについて話していますか？
前者の場合、（測定に基づく）私の経験則は開発時間に40-50％追加されます。つまり、ユースケースの開発に10日（QAと重大なバグ修正が発生する前）が必要な場合、良いテストの作成にはさらに4〜5日かかります-ただし、これは開発後ではなく、開発前および開発中に行うのが最適です。
テスト時間は、おそらく開発時間よりも機能範囲に密接に関連しています。また、テスト時間は開発チームのスキルと相関していると（おそらく議論の余地があるが）主張します。
6〜9か月の開発作業では、テスト対象のソフトウェアに精通している実際のテスター（開発チームではない）が実行する、最低2週間のテスト時間を要求します（つまり、2週間ランプアップ時間は含まれません）。これは、5人までの開発者がいるプロジェクト用です。
テストについて話すときは、ウォーターフォールまたはアジャイルテスト開発を意味します。アジャイル環境では、開発者はテストの開発と保守に時間の50％を費やす必要があります。
しかし、その50％の追加は、リファクタリングと手動検証の時間が来たときにsaveあなたの時間になります。
2006年10月のGartnerは、テストでは通常、システム統合プロジェクトの作業の10％〜35％を消費すると述べています。私はそれがウォーターフォール法に適用されると思います。これはかなり広い範囲ですが、標準製品のカスタマイズの量と統合するシステムの数には多くの依存関係があります。
テストのために余分な時間を考慮する唯一の時間は、使用するテストテクノロジに慣れていない場合（たとえば、初めてSeleniumテストを使用する場合）です。次に、ツールの速度を上げ、テストインフラストラクチャを導入するために、おそらく10〜20％を考慮します。
それ以外の場合、テストは開発の本質的な部分に過ぎず、追加の見積もりを保証するものではありません。実際、おそらくwithoutテストを実行したコードの推定値を増やします。
編集：私は通常、コードをテストファーストで書いていることに注意してください。事実の後に来て、既存のコードのテストを作成する必要がある場合、速度が低下します。非常に探索的な（読み捨て可能）コーディングを除いて、テストファーストの開発が私を遅らせることはありません。
昨日の天気で判断してください。前回はどれくらいかかりましたか？トレンドは長くなりますか、短くなりますか？ショップはそれぞれ異なります。
ほとんどのアジャイルショップは、TDDにより、必要な時間を大幅に短縮し、欠陥を大幅に減らし、迅速に解決することができます。それでも、ほとんどのアジャイルショップでは、テスト/ QCにある程度の時間を費やしています。
これがこのアプリケーションの最初のテスト実行である場合、答えは「letets see」に続いて試行です。質問への回答の速さ、テスト可能性、機能/機能の数、検出された欠陥の数、問題の解決の速さ、テストのコードサイクルの回数、および方法によって異なります多くの場合、テストはバグによってブロックされます。伝える方法はありません。あなたはそれを50％または175％以上と呼ぶことができ、間違っていません。大まかな推測をして、Piを掛けてみませんか？それはあなたが作ることができる他のどの答えよりもそれほど悪くはないでしょう。
（must）今かかっている時間と、速くなっているのか遅くなっているのか、カバレッジが増加しているか減少しているかを知る必要があります。これらの3ビットの情報を使用すると、非常によく推測できるはずです。