2つ目のバグを見つけるためになにをすればいいか

バグを一つ見つけたら、たぶんあと30個は潜んでる、知っているんだ

バグに関して一番難しいのは、「正しくバグレポートを書くこと」ではないかと思う。

など……誤りを誤りと特定し、他の人に納得させるためには正確な情報と、それを表現する文章力が求められる。GitHubのissueのテンプレートの仕組みが年々整備されていくのをみても、いかに自由に書かせても正しく書けないか、よく分かる。

この辺りは最初の頃にシニアなエンジニアに散々直されて覚えていくものだと思う。

さて、次に難しいのは「2つ目のバグを見つけること」ではないか。見つけたバグは直すしかない。しかし、きっとマネージャーはそのバグレポートに対して、次の言葉を発するはずだ。

「他に類似のバグは無いの？調べた？」

そう、バグは一つ有れば、たいてい同じ原因で混入した類似のバグが、2つ目、3つ目とさらに潜んでいる可能性が高い。

そしてたいていバグは偏在しているので(当たり前だけど、バグは自然発生しないので、満遍なく分布するはずがない)、正しい観点に従って調査しないと探すのに無限の時間がかかってしまう。

ではどうやって二つ目のバグを見つけるか？その方法は極論すると3つではないか。

直接原因に着目する参照したドキュメントが間違っていた、仕様の解釈を誤っていた、レビューの指摘が間違ってた……間違いの原因が特定されれば、同じプロセスで作られた箇所にはどうようのバグが潜んでいる可能性が高い……そして、この手の原因は、作り込んだ本人であれば容易に思いつく

本人が思い付かないものはたいてい一貫性か、整合性の欠如だ。ただ、これらは既存の成果物だけを見てもなかなか抽出・特定ができず、検証のための成果物を作る必要がある。

一貫性に着目するバグの内容が、”同じでなければならない要素”が同じでない場合、やはり”同じでなければならない要素”を全部抜き出し、”同じになっているか”検証する。
整合性に着目する例えば状態遷移の考慮漏れなどは、そもそも設計の整合性が積み上げられてないことが原因なので、状態遷移図やデータパターン図を書き出して確認する

そして、最後にこれがやってくる。