（受け入れ）テスト駆動開発の相対的なコスト効率

ソフトウェア開発に対するより伝統的なアプローチとは対照的に、プロジェクトの要件と設計が自動化された受け入れテストと単体テストによって駆動される場合、ソフトウェアプロジェクトに対するリソース計画の全体的な影響を知りたいと思います。

あなたの経験では、「従来の」開発方法論とは対照的に、TDDの下でソフトウェアプロジェクトを完了するためのリソース要件に対する全体的な影響は何ですか？品質が向上し、テストが早期に行われるため不確実性の量が減少することは自明のように思えますが、事前にテストを行う必要があるため、開発者により多くの時間を費やす必要があります。バグを事前に排除することにより、開発の労力はどの程度増加しますか、実際に減少しますか？

顧客からどれだけの労力が必要ですか？特に前もって大きなデザインに慣れている場合は、プロジェクトとの関係を変える必要がありますか？顧客全体の所要時間は増加しますか、それとも実際に減少しますか？

TDDプロジェクトの開始時の反復TDDプロセスでは、ソフトウェア開発計画がないため、時間の見積もりが非常に曖昧になると思います。たとえば、プロジェクトに20％のポイントがあり、ある程度安定した時間とお金の見積もりを最終的に顧客に提供できるほど信頼性が高まりますか？

注：ここでは主観的な意見や理論を探しているわけではありませんので、推測しないでください。TDDでの実際の経験をもっと探しています。

最初に述べる必要があるのは、TDDがソフトウェアの品質を必ずしも向上させるわけではないということです（ユーザーの観点から）。それは特効薬ではありません。それは万能薬ではありません。バグの数を減らすことは、TDDを行う理由ではありません。

TDDの主な目的は、コードが改善されることです。具体的には、TDDを使用すると、変更しやすいコードが生成されます。

TDDを使用するかどうかは、プロジェクトの目標に大きく依存します。これは短期的なコンサルティングプロジェクトになりますか？本稼働後にプロジェクトをサポートする必要がありますか？些細なプロジェクトですか？これらの場合、追加されたオーバーヘッドは価値がないかもしれません。

ただし、プロジェクトに関わる時間とリソースが直線的に増加するにつれて、TDDの価値提案が指数関数的に増加することは私の経験です。

優れた単体テストには、次の利点があります。

1. 単体テストは、意図しない副作用について開発者に警告します。
2. 単体テストを使用すると、古い成熟したシステムで新しい機能を迅速に開発できます。
3. 単体テストにより、新しい開発者はコードをより速く、より正確に理解できます。

TDDの副作用はバグが少ないかもしれませんが、残念なことに、ほとんどのバグ（特に最も厄介なバグ）は通常、要件が明確でないか貧弱であるか、必ずしもユニットテストの最初のラウンドでカバーされないことが私の経験です。

要約すると：

バージョン1での開発は遅くなる可能性があります。バージョン2-10での開発は高速になります。

「テスト駆動開発に関するソフトウェアの作成」の章があり、論文を引用しています。ここで説明します。

ケーススタディは、TDDを採用したマイクロソフトの3つの開発チームとIBMの1つの開発チームで実施されました。ケーススタディの結果は、TDDプラクティスを使用しなかった同様のプロジェクトと比較して、4つの製品のリリース前の欠陥密度が40〜90％減少したことを示しています。主観的に、チームはTDDを採用した後、初期開発時間が15〜35％増加しました。

これらの結果があなたのケースに一般化できるかどうかは、もちろん、TDDの支持者が主張することは明白であり、TDDの中傷者は主張することは真実ではありません。

提供する研究論文や統計情報はありませんが、過去に低から平均の単体テストのカバレッジがあり、エンドツーエンドのテストがなく、徐々にチーム/組織で働いていた経験を紹介します。バーを現在の場所に移動し、ATDDを追加します（ただし、皮肉なことに、 従来のTDDはない）アプローチ。

具体的には、プロジェクトのタイムラインを使用して、同じ組織内の他のチーム/製品で引き続きプレイアウトする方法です。

• 最大4週間の分析と実装
• 2週間の回帰テスト、バグ修正、安定化、リリース準備
• 既知の欠陥を修正する1〜2週間
• 2〜3週間のコードのクリーンアップとポストプロダクションの問題/サポート（不明な欠陥/計画外の停止）

これはばかげたオーバーヘッドのように見えますが、実際には非常に一般的であり、多くの組織ではQAが欠落している、または効果がないことがしばしば隠されています。優秀なテスターと集中的なテストの文化があるため、これらの問題は数か月/年にわたってゆっくりとプレイすることを許可されるのではなく、早期に発見され、前もって修正されます（ほとんどの場合）。メンテナンスオーバーヘッドの55〜65％は、デバッグに費やされる時間の80％の一般に受け入れられている標準よりも低くなっています。これは、ユニットテストと機能横断チーム（QAを含む）があるため、合理的と思われます

私たちのチームの最新製品の最初のリリース中に、受け入れテストの改良を開始しましたが、それらは完全にうまくいかず、まだ多くの手動テストに頼らなければなりませんでした。このリリースは他のプロジェクトよりもやや痛みが少なく、IMOは偶然の受け入れテストが原因であり、また一部は他のプロジェクトと比較して非常に高いユニットテストのカバレッジが理由です。それでも、リグレッション/安定化に約2週間、ポストプロダクションの問題に2週間を費やしました。

対照的に、最初のリリース以降のすべてのリリースには、早期の受け入れ基準と受け入れテストがあり、現在の反復は次のようになっています。

• 8日間の分析と実装
• 2日間の安定化
• ポストプロダクションサポートとクリーンアップの0〜2日

つまり、55〜65％のメンテナンスオーバーヘッドから20〜30％のメンテナンスオーバーヘッドに進みました。同じチーム、同じ製品、主な違いは、受け入れテストの進歩的な改善と合理化です。

それらを維持するコストは、スプリントごとに、QAアナリストが3〜5日、開発者が1〜2日です。私たちのチームには4人の開発者と2人のQAアナリストがいるので（UX、プロジェクト管理などは含みません）、60のうち最大7人日です。これは、実装のために15％の実装オーバーヘッドに切り上げます安全な側。

各リリース期間の15％を費やして自動受け入れテストを開発し、その過程で各リリースの70％を削減して、回帰テストを行い、運用前および運用後のバグを修正します。

2番目のタイムラインが最初のタイムラインよりもはるかに正確で、はるかに短いことにお気づきかもしれません。これは、事前の受け入れ基準と受け入れテストによって可能になったものです。これは、「完了の定義」を大幅に簡素化し、リリースの安定性にはるかに自信を持つことができるためです。他のチームは（これまで）隔週のリリーススケジュールで成功していません。ただし、かなり些細なメンテナンスリリース（バグ修正のみなど）を行っている場合を除きます。

もう1つの興味深い副作用は、リリーススケジュールをビジネスニーズに適合させることができたことです。あるときは、別のリリースに合わせて約3週間に延長する必要があり、テストや安定化に余分な時間を費やすことなく、より多くの機能を提供しながらそれを行うことができました。また、休日やリソースの競合のため、約1週間に短縮する必要がありました。開発作業を少なくしなければなりませんでしたが、予想通り、新しい欠陥を導入することなく、テストと安定化にかかる時間を短縮できました。

私の経験では、受け入れテストは、特にプロジェクトまたはスプリントの非常に早い段階で行われ、プロダクトオーナーによって書かれた受け入れ基準で十分に維持されている場合、あなたができる最善の投資の1つです。他の人が正しく作成の詳細に焦点を当てていると指摘、伝統的なTDDとは異なり、テスト可能なよりも、コードを、無欠陥コード- ATDDは本当に助けキャッチ欠陥を行いたくさん速いです。毎日完全なリグレッションテストを行うテスターの軍隊を組織化するのと同じですが、はるかに安価です。

ATDDは、RUPまたは（タフな）ウォーターフォールスタイルで行われる3か月以上の長期プロジェクトで役立ちますか？私はju審員がまだそれについて出ていると思う。私の経験では、長期プロジェクトの最大かつandいリスクは、非現実的な期限と要件の変化です。非現実的な期限により、テストのショートカットを含むショートカットが作成され、要件を大幅に変更すると多数のテストが無効になり、テストの書き換えが必要になり、実装のオーバーヘッドが増大する可能性があります。

ATDDは、アジャイルモデル、または公式にはアジャイルではないが非常に頻繁なリリーススケジュールを持つチームにとって、素晴らしい成果をもたらすと確信しています。長期プロジェクトでこれを試したことはありません。主に、この種のプロジェクトでそれを試そうとする組織に参加したことも聞いたこともないので、ここに標準免責事項を挿入します。YMMVなど。

PS私たちのケースでは、「顧客」からの特別な努力は必要ありませんが、受け入れ基準を実際に書く専任の専任のプロダクトオーナーがいます。あなたが「コンサルティングウェア」ビジネスに携わっているなら、エンドユーザーに有用な受け入れ基準を書かせるのははるかに難しいかもしれません。プロダクトオーナー/プロダクトマネージャーはATDDを実行するために非常に重要な要素のようです。もう一度自分の経験からしか話せませんが、その役割を果たせる誰かがいなければATDDが成功していると聞いたことはありません。

リソース要件

あなたの経験では、「従来の」開発方法論とは対照的に、TDDの下でソフトウェアプロジェクトを完了するためのリソース要件に対する全体的な影響は何ですか？

私の経験では、事前の明確な受入基準を定義することと、テストに書き込むことの両方により、事前テストを要求するコストはすぐに軽減されます。事前テストのコストが軽減されるだけでなく、全体的な開発が一般的にスピードアップすることもわかりました。これらの速度の改善は、不十分なプロジェクト定義、または要件の変更によって一掃される可能性があります。ただし、深刻な影響を与えることなく、こうした種類の変更に十分に対応できます。ATDDは、次の場合に自動化されたテストスイートを通じて正しいシステムの動作を検証する際の開発者の労力も大幅に削減します。

• 大規模なリファクタリング
• プラットフォーム/パッケージのアップグレード
• プラットフォームの移行
• ツールチェーンのアップグレード

これは、関連するプロセスと実践に精通したチームを想定しています。

顧客の関与

顧客からどれだけの労力が必要ですか？

彼らは継続的にもっと関与しなければなりません。先行投資の大幅な削減を見てきましたが、さらに大きな需要が続いています。私は測定していませんが、顧客にとってより大きな時間投資であることはかなり確信しています。

ただし、ソフトウェアがゆっくりと形作られるのを見ているデモを5回ほど行った後、顧客との関係が大幅に改善されることがわかりました。関係者がプロセスと関係する期待に誰もが慣れる関係が発展するにつれて、顧客からの時間のコミットメントはやや減少します。

プロジェクト見積もり

TDDプロジェクトの開始時の反復TDDプロセスでは、ソフトウェア開発計画がないため、時間の見積もりが非常に曖昧になると思います。

それは通常、質問がどれほど適切に定義されているか、そして技術リードがプロジェクトを（カードの見積もりを含めて）除外できるかどうかという問題だとわかりました。プロジェクトが適切にカード化されていて、妥当な速度平均と標準偏差があると仮定すると、適切な推定値を取得するのは簡単であることがわかりました。明らかに、プロジェクトが大きくなるほど不確実性が大きくなります。だからこそ、私は通常、大規模なプロジェクトを後から継続することを約束する小さなプロジェクトに分割します。顧客との関係を確立したら、これは非常に簡単です。

例えば：

私のチームの「スプリント」は1週間で、平均と標準があります。過去14週間の偏差。プロジェクトが120ポイントの場合、平均25と標準があります。6の偏差は、プロジェクトの完了を推定することです：

Project Total / (Mean Velocity - (2 * Std. Deviation) = 95% Time Estimate
120           / (25            - (2 * 6             ) = 9.2 weeks

2標準を使用します。95％の信頼性推定の偏差の経験則。実際には、通常、最初の標準でプロジェクトを完了します。偏差ですが、平均を超えています。これは通常、改良、変更などが原因です。

前もってテストを要求することは、達成するのにより多くの開発者時間を必要とするように思われます。バグを事前に排除することにより、開発の労力はどの程度増加しますか、実際に減少しますか？

これは実際には正しくありません。開発者が単体テストを作成している場合（およびそうする必要がある場合）、時間はほぼ同じか、より良いはずです。あなたのコードは完全にテストされ、要件を満たすためにコードだけを書かなければならないので、私はより良いと言いました。

開発者の問題は、ソフトウェアを可能な限り汎用にするために必要でないものでさえも実装する傾向があることです。

顧客からどれだけの労力が必要ですか？特に前もって大きなデザインに慣れている場合は、プロジェクトとの関係を変える必要がありますか？顧客全体の所要時間は増加しますか、それとも実際に減少しますか？

それは問題ではありません。要件を実行する人は、できる限りそれを実行する必要があります。

アジャイルな開発方法を実行する場合、それは大きなデザインを事前に意味するものではありません。ただし、要件、アーキテクチャ、および設計が適切に行われると、コードの品質が向上し、ソフトウェアの完成までの時間が短縮されます。

したがって、もし彼らがBDUFをしたいなら、彼らにそれをさせてください。開発者としてのあなたの人生が楽になります。