計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社

»

ここ(本ブログの過去エントリ)で、IBMとMSでのTDD(Test Driven Development)の適用評価事例を報告する論文を紹介した。TDDの適用評価は他にもあり、ここで紹介するのも、そのうちの1つ。

Boby George, a and Laurie Williams: A structured experiment of test-driven development, Journal of Information and Software Technology Vol. 46, No. 5, p. 337-342(2004)

論文では、24人の実務経験者を対象にテスト駆動開発をした場合としなかった場合(設計→実装→テスト)の比較をしている。報告されている主な知見は以下のとおり。

  • TDDを実施した場合に機能テスト(ブラックボックス)で不具合を検出するテーストケース数が削減された(不具合を検出したテストケースが18%減少)。
  • TDDを実施した場合に、コーディング(実装)の時間が16%増えた。
  • TDDを実施した場合、テストのカバレッジが大きくなった。

被験者を対象としたアンケートでは、以下を含む結果が得られた。

  • 96%の被験者がデバッグの工数を減らすと感じた。
  • 88%の被験者が要求が洗練されると感じた。
  • 92%の被験者がコードの品質を上げると感じた。
  • 50%の被験者が開発工数を減らすと感じた。

対象ソフトウェアは商用のものではなく、小規模のものだそうだ。グループを2つにわけ、TDD+ペアプログラミングのグループ、設計→実装→テストのグループとしている。

Comment(2)

コメント

> (不具合を検出したテストケースが18%減少)

Abstract では、"they passed 18% more functional black-box test cases." と言ってますね。18% 多くのテストケースをパスさせた、と。
実際の不具合数は、本文の Fig.1 にデータが載っていて、20のテストケースを実施して、TDD組の median が 2個弱、従来組は 4個強となってますから、median で見れば半減しています。

この論文でも、完成までのトータル工数 (つまり、コーディング開始から、テストケース20個に全部合格するまでのデバッグと再テストを含めた工数) を計測していないようなのが残念です。
なお、この論文では、TDD組も、対照の従来組も、どちらもペアプログラミングをしていますので、実際の現場でどうなるかを考えるには注意が必要です。

注意点等ありがとうございます。ためになりますね。
TDDの効果や適用結果を報告した論文はいっぱいあるようなので、ぜひbiacさんもご紹介ください。私もコメントしたいと思います。

紹介が増えていくといいですね。

コメントを投稿する