テスト駆動開発の事例（MS, IBM）の研究論文

本エントリは、オルタナティブブログのこのエントリを少し改変、再掲したものです。

N. Nagappan, M. E. Maximilien, T. Bhat and L. Williams: Realizing quality improvement through test driven development: results and experiences of four industrial teams, Journal of Empirical Software Engineering, vol. 13, pp. 289-302 (2008)

読んだ論文は次のとおり。Journal of Empirical Software Engineeringは論文誌としては、採択基準が厳しい部類に入る。


MS ResearchのWebから全文がPDFで読める。TDD Boot campを紹介するエントリでも本論文を紹介されているので、参考にしていただきたい。

示されている定量データのうち私が気にかかったのは以下のとおり。

定量データ（メトリクス）IBM DriverMS WindowsMS MSNMS Visual Studio
ソースコードサイズ(KLOC)41.06.026.0155.2
テストコードサイズ(KLOC)28.54.023.260.3
TDDを採用していない類似プロジェクトでの欠陥密度を1としたときの欠陥密度0.610.380.240.09
TDD採用により増加したコード実装時間（管理者の見積りによる）15〜20%25〜35%15%25〜20%

欠陥密度はリリースが近いフェーズでのテストで検出された欠陥にもとづいているそうだ。

また、次のような知見が紹介されている。

  • 途中でTDDをやめたり、途中からTDDをはじめてもうまくいかない。プロジェクトの開始時からやるべき（既存のソフトウェアの次バージョンから始める場合には言及がない）
  • テストコードの実行速度に気を配り、速く実行できるようにする。それぞれのテストコードの実行は短くても結合すると膨大な時間になってしまう場合がある。
  • テストケース数、テストコードの行数、コードの行数、カバレッジ、発見されたバグと修正されたバグの数、を計測し、傾向を把握する。
  • 開発開始、終了時には開発者の意向に耳を傾ける場を作る。今後も継続してTDDしたいかどうか。

どのプロジェクトもTDDを採用されなかったと想定した場合と比較して、工数が2割増しと見積られている。また、不具合密度が9〜61%まで低減したことも述べられている。工数は見積りであり、不具合密度は同一のソフトウェアを比較したわけではないので、議論の余地はある）。

論文で紹介されているテストコードの比率を考えると、テストコードのメンテナンスのコストもそれなりに必要になりそうだ。

上述のようなデータが公開されていることは、これからTDDを、と考える方には貴重なものとなり得るだろう。テスト駆動開発のメリットは拡張性、保守性、可読性を（デグレードのことをあまり気にせず）高められることにもある。このあたりを評価できるようになると、TDDが適している開発、そうでない開発がもっと明確になり、自身のプロジェクトで採用するかどうか判断しやすくなるだろう。それはそんなに遠くない未来ではないように感じている。