バグ修正のための変更の40%が新たなバグを混入するという研究結果 - Googleのバグ予測方法との共通点
Googleで実施されているというバグ予測の方法がブログで公開され（こちら）、ツールも利用できるようです（こちら）。Publickeyの記事での紹介で端的に紹介されていますので、時間がない方にお勧めします。ソースコードの変更（コミット）履歴から高い頻度でバグ修正されているコードは今後もバグが出る可能性が高いというものです。
類似の研究結果がたくさん報告されているので、この分野の研究者の1人として紹介したいと思いエントリを書きました。興味のある方には本エントリ末尾に示すこの分野の論文も読んでいただきたいです。
一例として2000年にICSMで発表された以下の論文を紹介します。
Mockus A, Votta LG. Identifying reasons for software changes using historic databases. International Conference on Software Maintenance (ICSM’00), pp. 120–130.
ICSMはInternational Conference on Software Maintenanceの略で、ソフトウェア保守開発を対象とした国際会議です。（今年（2011年）の9月に私たちの研究グループからも保守開発におけるコードレビューに関する論文が同会議で採録され発表しています）
研究対象は電話交換機のサブシステムを構成するソフトウェアで、200万行のコード、33,000件の変更仕様を対象に調査し、次のような結果を得ています。1はGoogleのバグ予測の方法と通じるところが大きいと言えるでしょう。
1. バグ修正のための変更のうち40%が新たなバグを混入している（デグレード）
2. 500行以上の変更の約半分がバグ混入のきっかけとなっている。
3. 1行だけの変更のうちバグを混入してしまう変更は4%
4. バグ混入してしまう変更は、1行だけの追加の場合約2%、1行だけの変更の場合には約5%
ご自身が携わるプロジェクトやソフトウェアで全く同じ数値になることは少ないと思われますが、類似の傾向がある方は多いと思います。実際に調べなくても経験則から、これらの結果にピンとくる方もいらっしゃると思います。
Googleのように知見や経験則をもとに、過去のデータからパラメータチューニングしたり実際にそれを使うためのツールやプロセスを導入し、それを公開することは、知見や経験則を発見する以上に難しい場合もありますが、実現すればその効果は大きいでしょう。ご自身のソフトウェアやプロジェクトで知見や経験則をみつけるきっかけとして研究成果を読んでみませんか？
このような研究テーマはMSR(Mining Software Repositories)という分野に位置づけられ、現在、非常に活発に調査、分析されています。MSRの国際ワークショップ（IEEE International Workshop on Mining Software Repositories）で発表された論文のうち2004年から2007年の論文集は誰でも閲覧できます（2004、2005、2006、2007）。2008年から2011年の分は、発表された論文のタイトルをみることができます（2008, 2009, 2010, 2011）。私たちの研究グループからも2007年にBTS（バグ管理システム）の分析を報告した論文が採録され、発表しています。
たとえば、MSR2005ではGörg C. と Weißgerber P.による Error Detection by Refactoring Reconstruction という論文があり、派生クラスにまたがるリファクタリングを一貫して実施するための支援方法と支援方法で発見されたApache Tomcatの不完全なリファクタリングの例を紹介しています。論文では言及されておらず論理の飛躍があるのですが、ひょっとするとこの知見はテストコードなしではリファクタリングが難しいという感触を裏付けているかもしれません。
上で紹介した論文が発表されたICSMでも同じような研究成果が発表されていますので、ぜひ覗いてみてご自身のソフトウェアやプロジェクトにあてはまる知見を探してみてください。