*はbiac氏のご指摘により「TDD採用により増加した工数」から修正した。 欠陥密度はリリースが近いフェーズでのテストで検出された欠陥にもとづいているそうだ。 また、次のような知見が紹介されている。 途中でTDDをやめたり、途中からTDDをはじめてもうまくいかない。プロジェクトの開始時からやるべき(既存のソフトウェアの次バージョンから始める場合には言及がない) テストコードの実行速度に気を配り、速く実行できるようにする。それぞれのテストコードの実行は短くても結合すると膨大な時間になってしまう場合がある。 テストケース数、テストコードの行数、コードの行数、カバレッジ、発見されたバグと修正されたバグの数、を計測し、傾向を把握する。 開発開始、終了時には開発者の意向に耳を傾ける場を作る。今後も継続してTDDしたいかどうか。 どのプロジェクトもTDDを採用されなかったと想定した場合と比較して、工数
![テスト駆動開発(TDD)の事例 - IBMとMS 計4プロジェクトを紹介した論文 -:森崎修司の「どうやってはかるの?」:オルタナティブ・ブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/7f2a4ced7f91e578679d11d5fcc8f34c5d080289/height=288;version=1;width=512/https%3A%2F%2Fblogs.itmedia.co.jp%2Fmt-static%2Fsupport%2Fassets_c%2Fuserpics%2Fuserpic-83-100x100.png)