#バグ

ソフトウェアやサービスの不具合は、そこにあるのに見えないことがあります。Dan Luuの「Bug blindness」は、まさにその“見えなさ”をめぐる話です。筆者は自分だけが細かいバグを見つけやすいのではないかと長く考えてきましたが、実際には多くの人が同じ問題にぶつかっていて、それに気づいていないだけなのではないか、と考えるようになった。この記事は、製品の品質をどう評価するか、そして「うまく動いている」という周囲の空気をどこまで信じてよいのかを考えさせます。 元記事の筆者は、週に何百から何千ものバグを自然に見つけてしまうと書いています。最初は、自分のコンピュータの使い方が特殊だからそう見えるのだろうと思っていたものの、長く観察するうちに、周囲の人たちは単に同じ不具合に出会っても気づいていないのではないか、と考えるようになったそうです。非プログラマーであれば、そのほうが世界の見え方としては自然かもしれないが、プログラマーにとっては品質の問題を見抜く力が役に立つ、と筆者は言います。実際、知人にバグを指摘し続けると、数週間ほどで相手も気づくようになることがあるとも述べています。 筆者は、企

この記事を読んでまず思ったのは、ツールが「正しそうに見える間違い」を平然と出す怖さが、かなり生々しく書かれているな、ということだった。しかも厄介なのは、単にバグを踏んだ話ではなく、調べた先の見え方そのものが誤解を誘う形になっていた点だと思う。 いちばん引っかかったのは、package rename が「存在しない package」と区別できないという話だ。version を見ているだけでは、まだ出ていないのか、名前が変わったのか分からない。言われてみれば当たり前なのに、実際にはその当たり前を見落としやすい。機械的な checker ほど、見つかった事実だけで断定してしまう危うさがあるんだなと思った。 もうひとつ印象に残ったのは、broken link の話だ。spec を参照しているつもりのリンクが、実は overview に飛ぶだけで、見た目には壊れていない。これはかなり嫌な失敗で、単に「リンクが切れている」よりタチが悪い。検証できる顔をしながら、実際には検証先が違う。こういうのは人間でも気づきにくいし、だからこそ test で縛るしかないのだろう。 ただ、ここで面白いのは「dete