バグのないコードは目標として間違っています。より良い目標を示します。

なぜ「バグのないコード」は目標として間違っているのか

どのシステムにも、まだ誰も踏んでいない欠陥が残っています。そして分かりやすい欠陥が取り除かれるほど、次の1件を見つけるコストは急激に上がります。ある地点を越えると、欠陥を探すために追加で費やす1時間は、失敗を安く検知して修正できるようにするために使う1時間よりも価値が低くなります。

二つ目の問題は文化にあります。バグがないことを目標として掲げると、バグは対処すべき情報ではなく、釈明すべき失点になります。その結果、人はバグについて口をつぐむようになります。

機能する3つの目標

なぜ最初の一つが最も重要なのか

同じバグを二度と出さないチームは、その仕組み自体によって毎月確実に良くなっていきます。必要な習慣はただ一つ、何かを修正したらチェックを一つ残すことです。多くのチームはバグを直してチケットを閉じるだけで、その振る舞いを守る必要があったという記録を何も残しません。

測定の方法

リリース前に見つかった欠陥の割合と、失敗から修正までの時間を追ってください。どちらも実際に何かが良くなったときに動き、テストを増やすだけでは操作できません。この点が有用です。テストの件数もカバレッジ率も、望めばいくらでも上げられ、ほとんど何も教えてくれません。

それでもチームが追い続けてしまう理由

目標が間違っていると分かっていても、人はそこを狙うのをやめません。その理由は素朴さではなく構造に根ざしているため、理解しておく価値があります。

バグは目に見えますが、予防は目に見えません。顧客に届いてしまった欠陥には、チケットがあり、名前があり、担当者がいます。リリース前に捕捉された12件には何もありません。何も起きなかったからです。その結果、四半期の記録として目に見えるのは失敗の一覧になり、失敗の一覧に対する自然な反応は、それをもっと減らせと求めることになります。

対抗策は、予防も目に見えるようにすることです。リリース前に捕捉できた欠陥の数を、流出した数と並べて報告してください。前者のほうがたいてい大幅に多く、それを目にすると、議論は「なぜバグが出続けるのか」から「その比率は動いているのか」へと変わります。後者こそ、有用な答えのある問いです。

実際にはどうなるのか

すべてのバグにチェックを一つ付けます。チェックはリリース前ではなく、変更のたびに実行します。失敗は、修正する人が経緯をたどり直さなくても対処できる形で届きます。

ローカルにインストールしたくない方には、ダッシュボードが同じ範囲をカバーします。コマンドの全体像は、こちらにまとまっています： CLI リポジトリ。

仕組みよりもトリガーのほうが重要です。デプロイのイベントに向けておけば、誰かが判断しなくてもすべての変更がチェックされます。ダッシュボードからそれを行うのが GitHub App であり、ワークフローの内部から行うのが GitHub Actions のステップです。

TestSprite は3つの目標をどう支えるか

最も直接的に役立つのは「同じバグを繰り返さない」です。バグを再現したテストケースはプロジェクトに残り、変更のたびに実行されます。そのため、誰かがテストを書くことを覚えていなくても、修正がチェックを一つ残します。

「ユーザーより先に見つける」は実行の頻度の問題です。カバレッジは製品から生成され、プルリクエストの時点で実行されるため、検知が本番環境から、原因となった変更そのものへと戻ってきます。

「修正が安く済む」は、失敗レポートの質に左右されます。実行結果は、何を試し、アプリケーションがどう振る舞い、どこで両者が食い違ったのかという形で返ってきます。そのため、修正を担当する人は、近ごろではコーディングエージェントであることも増えていますが、経緯を組み立て直すのではなく証拠から作業を始められます。