A First Look at the Self-Admitted Technical Debt in Test Code: Taxonomy and Detection

ソフトウェアが真に完成することはありません。プログラムがリリースされた後も、開発者はエラーを修正し、新機能を追加し、変化するニーズに適応するために、絶えずそのプログラムに戻らなければなりません。この継続的な作業はメンテナンスと呼ばれ、多くの場合、ソフトウェアの初期作成そのものよりも多くの労力を必要とします。この作業を管理可能なものにするため、プログラマーは時として、特定のセクションが乱雑であることや、一時的なものであること、あるいは完全には正しくないことを認めるメモをコードの中に残すことがあります。「これはハック（場当たり的な修正）だ」とか「後でこれを直せ」といったコメントを書くこともあります。ソフトウェアエンジニアリングの世界では、これらの正直な告白は「自己申告された技術的負債（self-admitted technical debt）」として知られています。それは、開発者が「これが最善の方法ではないことは分かっているが、今はとにかく終わらせる必要があったのだ」と言っているようなものです。研究者たちは、プログラムを実行するメインのコード内にあるこれらのメモについては長年研究してきましたが、そのプログラムをテストするために使用されるコード内のメモについては、ほとんど無視してきました。これは重大な見落としです。なぜなら、テスト自体が欠陥だらけであったり、不適切に書かれていたりする場合、ソフトウェアシステム全体が信頼できないものになってしまうからです。

マニトバ大学の研究チームは、この隠れた負債の層を理解するために着手しました。彼らは、複雑なアプリケーションを構築するために広く使用されている言語であるJavaで書かれた特定の種類のソフトウェアに焦点を当てました。明確な全体像を得るために、彼らは1,000の異なるオープンソースプロジェクトから集められた100万件以上のコメントという膨大なコレクションを収集しました。この膨大なプールの中から、彼らは5万件のコメントをランダムに選び、手作業で調査しました。この手作業によるレビューは非常に骨の折れる作業であり、各メモを読み、それが真の不備の告白なのか、それとも単なる標準的な説明なのかを判断する必要がありました。関連性のないコメントや、データを偏らせる可能性のある単一のプロジェクトに由来するコメントをフィルタリングした後、彼らはテストコードにおける技術的負債の真の例として615件のコメントを特定しました。

研究者たちは、テストコードに見られるこれらの負債の性質が、メインのアプリケーションコードで見られるものとは大きく異なることを発見しました。彼らはこれら615件の事例を11の明確なカテゴリーに分類しました。中には、設計の不備やドキュメントの欠如といった、よく知られたものもありました。しかし、4つのカテゴリーは、テストの世界に特有の全く新しいものでした。これらには、「限定的なテスト（limited tests）」、つまり開発者が、そのテストは問題のごく一部、あるいは代表性の低い断片しかチェックしていないと認めているもの、「スキップされたテスト（skip tests）」、つまり現在の環境では実行できないためにテストが明示的にオフにされているもの、「保留中（on-hold）」、つまり外部のツールやサービスが利用可能になるのを待っているテスト、そして「不確実性（uncertainty）」、つまり開発者がそのテストが正しいかどうかさえ確信が持てない状態、が含まれていました。この分類学は、テストコードが、ソフトウェアの構築そのものよりも、ソフトウェアの挙動を検証するという特定の課題に関連した、独自の負担を抱えていることを明らかにしました。

これらの負債がどのような姿をしているかをマッピングした後、チームはより実践的な第2の問いを投げかけました。「コンピュータはこれらを自動的に見つけられるのか？」彼らは、通常のソースコード内でこれらのメモを検出するために設計された7つの既存ツールをテストしました。また、オープンソースのモデルと、主要なテクノロジー企業による強力なプロプライエタリ（独占的）モデルの両方を含む、一連の人工知能モデルもテストしました。結果は驚くべきものでした。特定のキーワードである「TODO」や「FIXME」を探すことに依存している既存のツールは、伝統的な手法の中では最も優れた性能を示しましたが、それでも実際の負債の3分の1以上を見逃していました。それらは、何かを見つけた場合には正確でしたが、多くの真の問題を見つけることには失敗しました。

人工知能モデルは、異なる意味でさらに悪い結果となりました。オープンソースのモデルは、非常に明らかなキーワードが含まれていない限り、負債を認識できず、全く見つけられないことが多々ありました。何かを見つけたとしても、頻繁に間違いを犯していました。より高度であるとされるプロプライエタリのモデルは、正反対の問題を示しました。それらはほぼすべての負債を見つけ出しましたが、同時に何百もの無害なコメントを問題としてフラグ立てしてしまいました。彼らは問題を特定しようと熱心になりすぎるあまり、日常的な説明を失敗の告白と勘違いしてしまったのです。結局のところ、従来のツールも、最も高度なAIシステムも、テストコードにおけるこれらの負債を確実に検出することはできませんでした。

この研究は、開発者がテストコードについて問題を記述する方法は、メインのコードについて記述する方法とは根本的に異なるという結論を下しています。テストファイル内のメモは、「無効化（disabled）」や「スキップ（skipped）」といった、テストプロセスに特有の言葉を使用することが多く、標準的なツールやAIモデルはこれらを負債の兆候として認識しません。研究者たちは、現在の手法はまだこの複雑さに対応できる段階にないことを明らかにしました。彼らは、将来の研究者がより優れた検出ツールを構築できるよう、新しいデータセットと詳細な負債タイプのマップを作成しました。それまでは、テストコードにおけるこれらの隠れた欠陥を見つけ出し、修正する作業は、依然として人間の注意を必要とする仕事であり続けるでしょう。