コードレビューやテストの優先順位付けに統計モデルが役立つか実際に試してみた論文
プログラムの規模が大きくなるとソースコードレビューやシステムテストをどこからはじめてよいか優先順位が付けにくくなります。優先順位は様々です。たとえば、欠陥を見逃した場合にリスクが大きくなるところからはじめる、多くのユーザが使う基本機能の正常動作からはじめる、依存関係が多く様々な部分から参照される共通モジュールからはじめる、今後も長期にわたって保守、拡張する部分からはじめるといった方針が考えられます。もちろん、できた部分から順番にという順位付けもあるでしょう。
優先順位のつけ方の一つとして、ソースコードの特徴から不具合がありそうなクラス、モジュール、メソッド、関数を予測する技法としてFault-proneモジュール予測という技法があります。過去の不具合のデータとソースコードの特徴を表わす数値をモデルに与え、不具合が起こりやすいソースコードの特徴を学習させます。数値は関数、メソッド、クラスといった一定のかたまりごとに、規模、分岐の数、依存している関数、メソッド、クラスの数といったソースコードメトリクスを計測します。ソースコードメトリクスは自動計測できるものを使い、目視しなくても得られるようにしておきます。その学習モデルに今開発しているソースコードのソースコードメトリクスを与え、もっとも不具合がありそうな関数、メソッド、クラスを予測します。本ブログの過去エントリ（Fault-proneモジュール予測）でも簡単にふれています。
統計モデルにもとづいていますので「これくらい分岐が多くて、外部への参照が多ければ不具合が含まれる」「これくらいの規模以上になると不具合が含まれる可能性が高まる」といった情報を複合的に学習して不具合を予測します。複雑になったり規模が大きくなると見通しが悪くなって不具合を含みやすくなります。また、ソースコード自体の特徴ではありませんが更新回数が多いクラスやメソッドは不具合を含みやすくなる、といった研究結果が得られています．本ブログの過去エントリ（バグ修正のための変更の40%が新たなバグを混入するという研究結果 - Googleのバグ予測方法との共通点）でも紹介しています。
ただし、このような特徴の組合せが必ずしも不具合に直結しているわけではありません。さらに予測精度を高めるためには別の着眼点で評価された情報が必要になります。
そこで、統計モデルで不具合が含まれる可能性が高いと予測されたクラスやモジュールを目視で評価することにより、不具合の予測精度を高めようという技法を我々の研究グループのメンバである笠井氏が提案し、商用のソースコードを用いて実際に予測精度が高まか評価しています。目視と統計モデルの組合せにより精度が高まる結果が得られています。こちらで論文を公開しています。目視は、質問事項となる着眼点を事前に定義して実施します。