バグ発見は有害か？
Bug Finding Considered Harmful? (alperenkeles.com)
要約
この記事は、ソフトウェア開発におけるバグ発見の価値と限界について考察しています。特に、AI時代におけるテスト研究者と開発者の関係性の変化や、発見されたバグをすべて修正することの現実的な是非について議論しています。著者は、開発と並行して行う「in vivo」テストの重要性を強調し、発見されたバグの報告と修正においては、より選択的なアプローチが必要であると結論付けています。
全文翻訳
これは、私が1週間問い続けている質問です。皮肉を理解する人なら、その間、私は新しいプロパティベーステスト（PBT）ツールを開発していました。ご存知のように、質問形式のタイトルは通常、答えがいいえであることを意味しますが、この分野で6年間働いてきて、この質問をする立場になるとは思ってもいませんでした。そのため、議論する価値があると思いました。しかし、少し立ち戻ってみましょう。
プロパティベーステスト（PBT）は、ソフトウェアテストの「高度な」手法です。古典的なテストのように特定の動作をテストする代わりに、伝統的にプロパティと呼ばれる「ブループリント」を定義します。プロパティとは、テスト対象のシステムに関する一般的な事実です。例えば、「このプログラムをANY入力で実行してもクラッシュしない」「ANY 2つの数値の加算は可換である」「私の物理シミュレーションは常に運動量を保存する」などです。これらのプロパティは、状態または入力からブール値への関数を記述することで比較的簡単に表現できます。そして、これらの関数の入力によって定義された入力空間をランダムにサンプリングすることでテストします。
テスト研究者の仕事は、バグを見つけ、その根本原因を特定し、最終的には保守担当者がバグを修正するのを助けることです。もちろん、これらは本質的に私たちの働き方であり、価値提案ではありません。私の意見では、テスト研究の価値提案は、信頼性の高いソフトウェアシステムを構築するのを助けることです。PBTは、ファジング、決定論的シミュレーションテスト、形式検証などのアプローチの1つにすぎません。これらはすべて、異なる状況やドメインで異なるトレードオフを持ちながら、同じ目的を果たします。
テスト研究における重要な緊張関係は、テスターと保守担当者の分離です。テスターは常に外部からシステムにアプローチし、保守担当者とは別の存在です。テスターは保守担当者ほどシステムを理解していませんし、理解するインセンティブも能力もありません。私は、この緊張関係がAI時代において臨界点に達していると信じており、私たちがどこに立っているのかを理解することに関心があります。
門番の野蛮人：バグレポートは有害か？
先月、私は明らかに500件以上のバグレポートを提出しました。正直に言って、私はそれを誇りに思っています。テスト研究者にとって、十分にテストされたシステムで斬新なバグを見つけることは夢です。それは、アスリートが世界記録を更新するようなものです。少なくとも、はるかにオタク的で、はるかに印象の薄いバージョンです。バグを報告する際には、非常に丁寧にするよう努めました。エージェントにすべてを任せるのではなく、可能な限り自分でトリアージしましたが、もし何十億人もの人々がこれらのケースに遭遇していないのであれば、おそらくそれらはそもそもそれほど重要ではなかったのではないかという感覚を拭い去ることができませんでした。
私がPostgres19の遅延に部分的に責任を負っている可能性があるという事実は非常に恐ろしいです。しかし、「ファージャー疲労」という概念は実際には新しいものではありません。Z3プロバーはファージャーの人気のターゲットでしたが、当時、いくつかの激しい議論を引き起こしました。SQLiteの保守担当者は、わずか20分でいくつかのバグを修正するという驚異的なスピードで作業していますが、彼らが驚くほど疲弊していることは間違いないでしょう。
バグ発見を支持する最も強力な議論はセキュリティです。私たちがバグを見つけなければ、攻撃者が見つけ、それらを使って悪いことをするでしょう。これは古典的なファジングに特に有効です。しかし、特に私が関わっている、システムの機能的な正当性プロパティをテストする最近の作業では、価値提案がシフトすると考えています。
誤解しないでください。バグはバグです。私が提出したすべてのバグレポートの中で、その動作が実際にバグなのかどうかを保守担当者と議論したのは一度だけでした。問題はより実践的です。実用的なユーザーがその問題のために劣化を経験することが決してないとしても、ソフトウェアのすべてのバグを修正する価値はあるのでしょうか？
さらに言えば、誰も経験したことのない10年前のバグを修正するために、ユーザーが実際に使用する新しい機能を構築する代わりに、貴重な保守担当者の時間を費やす価値はあるのでしょうか？
私が到達した結論は、既存システムで古いバグを見つけるという私の努力を台無しにするものですが、テストは開発と連携できる場合に最も価値があるということです。後から行われるテストは、セキュリティ脆弱性やサイレント障害には価値があるかもしれません。そして、テスト中にどのような種類のバグに遭遇するかは実際にわかりません。したがって、疑わしい場合はテストする必要があります。しかし、報告するバグは選択すべきです。さらに言えば、修正するバグを選択すべきです。すべてのバグを単純に修正しなければならないというイデオロギー的な立場は、現時点では私には実行可能ではないように思えます。
私は、バグの特定とバグの解決の非対称性を通じてこの結論に至りました。私が500件以上のバグを手動で確認できた理由は、バグが非常に検証可能だからです。短いスニペットがあれば、スニペット、期待される動作、実際の動作を確認し、非常に高い確信度で保守担当者にレポートを提出できます。これらの単純なスニペットの修正は、1行から数百行に及ぶ可能性がありますが、特定のバグに対しては多くの可能な修正があります。ソフトウェアには有限または無限のバグがあるのかどうかは時々議論されますが、それは間違った質問だと思います。私は、特定のソフトウェアのすべてのバグを修正するための有限の修正セットが存在すると信じていますが、私たちが実際に適用する修正がそれらである可能性は低いと考えています。したがって、現在検査しているテストケースの近傍のみを修正するという、すべてのバグに対して「最も単純な」修正を適用する貪欲なアプローチを採用した場合、私たちは実際には無限のバグ修正を行う必要がある世界に住んでいるかもしれません。したがって、修正は慎重に作成され、将来を見据えたものでなければならず、本質的にはバグ自体よりも検証がはるかに困難です。
[画像: xkcd 1739: Fixing Problems]
この非対称性の文脈において、バグ発見はバグ修正を圧倒し続けると私は主張します。したがって、ソフトウェアを構築し続けることができるように、この非対称性を考慮するのは私たち次第です。形式検証の文脈でさえ、述べられたプロパティを無効にするすべてのバグを技術的に列挙できる場合でも、システムに対してテストするプロパティをますます多く見つけることになるでしょう。私にとって、正当性は終わりのない卓越性の追求のように思えます。
私はこれらの議論を、システムを強化する方法として、事後に行われるテストであるin vitroテストの文脈で行っています。一方で、in vivoテストはこれまで以上に有用であると信じています。なぜなら、有用性、表現力、パフォーマンスを犠牲にする必要がない限り、当然、正しいシステムを構築したいからです。特に検証能力が向上するにつれて、その能力を活用して開発を遅くするのではなくスピードアップすることは、私たちの標準になる可能性があり、おそらくそうすべきです。