開発時間のパーセンテージとしてのテスト努力の見積もり

Question

誰かが、開発に必要な労力のパーセンテージとして、テストに必要な労力を見積もるために経験則を使用していますか？もしあなたが何パーセント使っていたら？

Answer 1

テストの見積もりには、テストの範囲を特定する必要があります。ユニットテスト、機能、UAT、インターフェイス、セキュリティ、パフォーマンスストレス、ボリュームについて話していますか？

あなたが滝のプロジェクトをしているなら、かなり一定のオーバーヘッドタスクがあるでしょう。計画文書、スケジュール、レポートの作成に時間を費やす。

機能テストフェーズ（私は "システムテスター"ですので、私の主な参照点です）を含めることを忘れないでください！テストケースでは、実行するのに必要な要件/仕様/ユーザーストーリーから少なくとも多くの努力を払う必要があります。さらに、欠陥の再検査/再検査のためにある程度の時間を含める必要があります。大規模なチームの場合は、スケジュール管理、レポート作成、会議といったテスト管理を考慮する必要があります。

一般的に私の見積もりは、デベロッパー努力の割合ではなく、提供されている機能の複雑さに基づいています。しかし、これには、少なくとも高水準の命令セットへのアクセスが必要です。何年ものテストを行うことで、特定の複雑さのテストには、準備や実行に数時間かかることがあります。一部のテストでは、データ設定に余分な労力が必要になる場合がありますいくつかのテストでは、外部システムとの交渉や、必要な労力をはるかに超える期間があります。

最終的には、プロジェクト全体の中でそれを確認する必要があります。あなたの見積もりがBAまたは開発の見積もりを大幅に上回る場合は、基礎となる仮定に間違いがあるかもしれません。

私はこれが古いトピックだと知っていますが、それは私が現時点で再考していることであり、プロジェクトマネージャーにとって多年にわたる関心事です。

Answer 2

Googleテストブログdiscussed this problem recently：

だから、素朴な答えは、筆記試験は10％の税を運ぶということです。しかし、我々は何かを得るために税金を支払う。

（スニップ）

これらの利点は、今日だけでなく、明日実際の値に変換します。私はテストを書いています。なぜなら、10％の追加コストを相殺する以上の利益を得るからです。たとえ私が長期的な利益を含まなくても、今日のテストから得た価値はそれだけの価値があります。私はテストでコードを開発する方が早いです。どれくらい、それはコードの複雑さにかかっています。あなたが構築しようとしているものがより複雑であればあるほど、より多くのifs/loops/dependenciesがテストの利点です。

Answer 3

安全性の重要な分野では、私は10行のコードを単体テストするための一日のようなことを聞​​いてきました。

私はまた、開発のための努力の50％（単体テストだけでなく）テストの50％を観察しました。

Answer 4

自動ユニット/統合テストまたは手動テストについてお話ししていますか？

私の経験則（測定に基づく）は開発時間に40-50％追加されています。つまり、ユースケースの開発に10日間かかる場合（QAと深刻なバグ修正が発生する前） 4〜5日 - これは開発の前と途中で起こるのが最善である。

Answer 5

テスト時間は、開発時よりもフィーチャスコープと密接に関連している可能性があります。私はまた、テスト時間が開発チームのスキルと相関している（多分議論の余地がある）と主張しています。

6から9ヶ月の開発努力のために、テストするソフトウェアに精通している実際のテスター（開発チームではない）が実行したテスト時間は2週間です。 、2週間には立ち上げ時間は含まれていません）。これは〜5人の開発者を持つプロジェクトのためのものです。

Answer 6

私がテストに余裕を感じるのは、初めて使用するテスト技術に慣れていない場合です（たとえば、初めてSeleniumテストを使用するなど）。次に、ツールのスピードアップとテストインフラストラクチャーの導入のために、おそらく10〜20％を占めています。

その他のテストは、開発の本質的な部分であり、余分な見積もりを保証するものではありません。実際、のコードの見積もりをのテストなしで増やすことはおそらくあります。

編集：私は通常、最初にテストコードを書いています。もし私が事実の後に来て、物事を遅くする既存のコードのためのテストを書く必要があれば。私は、テスト初の開発では、非常に探索的な（読み取り：スローアウェイ）コーディングを除いて、私をすべて遅らせることはできません。

Answer 7

テストでは、滝やアジャイルテストの開発を意味する可能性があります。アジャイルな環境では、開発者はテストの開発と維持に費やす時間の50％を費やすべきです。

ただし、再ファクタリングと手動確認の時間が来る場合は、50％の追加料金がに保存されます。時間がかかります。

Answer 8

昨日の天気による審査員。前回はどのくらいかかりましたか？トレンドが長くなったり短くなったりしていますか？それぞれの店は違う。

ほとんどのアジャイルショップでは、TDDのために必要な時間が大幅に短縮され、欠陥が大幅に少なくなり、解決に時間がかかります。それでも、ほとんどのアジャイル・ショップには、テスト/ QCに費やす時間があります。

これがこのアプリケーションの最初のテスト実行であれば、答えは「見る」とそれに続く試みです。それは、あなたが質問に答え得ることができる方法迅速に依存 - それがどのようにテスト可能な、 - どのように多くの機能/機能 - 発見されているどのように多くの欠陥、 - 問題が解決されているどのように迅速に、 - 何回コードサイクル - バグでテストが何回ブロックされているかを示します。 伝える方法はありません。あなたはそれを50％または175％以上と呼び、間違ってはいけません。大まかな推測をしてPiで乗算してみませんか？あなたが作ることができる他の答えよりもそれほど悪くはありません。

現在の所要時間と速度が向上しているか遅いか、そしてカバレッジが増減しているかどうかを（はにする必要があります）お知らせください。これらの3つの情報で、あなたはかなりうまく推測できるはずです。

Answer 9

2006年10月のGartnerでは、テストでは通常、システム統合プロジェクトでの作業の10％から35％が消費されると述べています。私はそれが滝の方法に当てはまると仮定します。これはかなり広い範囲ですが、標準製品へのカスタム化の量と統合されるシステムの数には多くの依存関係があります。

Answer 10

私の経験から、分析に費やされるのは25％です。設計、開発、単体テストの50％テストのために残りの25％。ほとんどのプロジェクトは、プロジェクトの性質、リソースの知識、入力の質、&の成果などによって、この経験則の+/- 10％の差異に収まるでしょう。これらのパーセンテージ内または上のオーバーヘッドは10-15％の範囲内です。