学術誌Empirical Software Engineering(リンク)にて最初に発表された論文は、次のように報告している。「TDDは様々な分野で適用可能のようだ。また、開発チームの生産性を大きく低下させることなく、開発するソフトウェアの欠陥密度を大幅に削減できる。」この調査では、MicrosoftおよびIBMの4つのプロジェクトが比較されており、TDDを使用したプロジェクトとそれに類似するTDDを使用しないプロジェクトを取り上げている。
この論文(リンク)は、Nachiappan Nagappan氏(リンク)（microsoft）、E. Michael Maximilien氏(リンク)（IBM）、Thirumalesh Bhat氏（Microsoft）およびLaurie Williams氏(リンク)（North Carolina State University）により執筆され、学術誌Emperical Software Engineeringの第13巻、3号(リンク)で発表された。この論文(リンク) はEmpirical Software Engineering Group Microsoft Research(リンク)からも入手可能である。
論文には、IBMのケース・スタディが1つ、Microsoftのものが3つ記載されている。各ケース・スタディは、高レベルなマネージャのもと、同じ開発言語とテクノロジを使用し同一の製品に取り組む2つのチームを比較しており、一方のチームのみテスト駆動開発（TDD）を使用していた。開発サイクル中、自らが調査の一端を担うことになろうとは、気付くチームなどいなかった。IBMのケース・スタディでは、デバイス・ドライバを開発しているチームを追跡し、Microsoftのケースでは、Windows、MSNおよびVisual Studioに取り組んでいるチームを追跡した。
論文では、チームが使用したTDDのプラクティスを分刻みのワークフローおよびタスクレベルのワークフローとして記述している。
分刻みのワークフロー
- 少量の新規テストを記述する。
- テストを実行し、失敗するケースを確認する。
- テストの条件を満たすコードを実装する。
- 新規ユニット・テストケースを再実行し、今度は成功することを確認する。
タスクレベルのワークフロー
- 新しいコードおよびテストを既存のコードベースに統合する。
- すべてのテストケースを再実行し、新しいコードが他に影響を及ぼしていないか確認する。
- 実装またはテストコード、あるいはその両方のリファクタリングを行う。
- すべてのテストを再実行し、リファクタリング後のコードが他に影響を及ぼしていないか確認する。
4製品のリリース前の欠陥密度（コード1000行あたりの欠陥数を測定）は、TDDを使用しないプロジェクトと比較し40%から90%の間で減少した。チームの管理者は、主観的に見てTDDを使用するチームの初期開発時間に15%から35%の増加が認められると報告したが、チームは、これはメンテナンス・コストの削減により相殺されるとの見解で一致した。
これらの結果は、Maria Siniaalto氏が2006年に発行した論文(リンク)から明らかになったことと比較できる。この論文は、テスト駆動開発における13の異なる調査から得た結果の評価および要約を試みたものであり、調査は、産業、準工業、および学術を背景に行われた。著者はこの論文の結論で、次のように記している。
既存の調査結果に基づき、TDDは、とりわけ産業を背景に使用された場合、ソフトウェアの品質を向上させるようだと結論付けられる。準工業や学術を背景とした場合は、結果はそれほど明確ではないが、品質の低下は一つとして報告されなかった。TDDの生産性効果はそれほど顕著ではなく、また、結果は調査対象の背景に関わらず異なる。とはいえ、TDDは必ずしも開発者の生産性の低下やプロジェクトのリードタイムの延長をもたらすわけではないことを示している。一部のケースでは、TDDを使用し生産性の大幅な向上を果たしたものもあったが、13の調査ケース中、2つのケースにかぎり生産性の低下が報告された。ただし、両方の調査結果において品質は向上した。
TDDでどのような経験をしたか？品質の向上は認められたか？開発者の生産性、および開発期間にはどのような効果が見受けられたか？ぜひコメントを残し、個々の経験を共有していただきたい。
原文はこちらです：http://www.infoq.com/news/2009/03/TDD-Improves-Quality