バグは見つけやすいところから見つけろ！？
「Bowwwwww!」
残業を終えて家路に向かう22時ころ、遠くから爆音が聞こえる。最近あまり出てこなかった暴走族が走っているようだ。やけに長い時間騒音が続いていた。うるさいなあ。
■多くの交通違反を見つけるには
翌日、自宅の近くの人通りの少ない道を歩いていると、坂の上から赤い車が走ってきてT字路をのろのろと右折した。
するとどこからか警官2人が現れてその車を止めた。どうやら一時停止しない車を取り締まっていたようだ。事故になるような速度ではなかったのに。でも規則は規則。規則を守らない方がいけないのだ。多くの違反者を検挙するには、ここでの取り締まりは効果的だ。
こういった細かいところも取り締まっているくらいだから、きっと昨夜の暴走族もしっかりと取り締まってくれたんだろうなあ。
■多くのバグを見つけるには
そういえば、昔あるシステムでテスト工程を担当していたときのことを思い出した。テストプログラムを流していると、たまにシステムがハングアップすることがあった。でも同じ条件で実行を繰り返しても再現しない。再現させることができないと不具合として報告するのは難しい。Windowsの調子がおかしかったのかな、というようなことで片付けてしまったこともあった。
一方、レアケースのバグは数多く報告した。そのシステムでは通常使わないであろう特殊なテストデータを入力して、絶妙なタイミングである操作を行うと、出力データの1bitが異常値になる、といったようなかなり意地悪なテストケースもある。実用でこんな使われ方をすることはまずないだろう。しかもその1bitが異常になったところでログが不正確になるだけで全体に大きな影響はない。でもバグはバグだ。
テスト担当者の仕事は多くのバグを見つけて報告すること。それが成果だ。成果を上げるためには意地悪なテストケースを多く作るのが効果的だ。たとえ実用で使われることのないようなケースだとしても。
■全体のことを考えて
でもシステム全体の品質を高めようと思っていたら、レアケースばかりでテストするよりも先にすることがあったはずだ。テスト担当者が自分の成果を上げることしか考えていないとこういうことが起こる。レアケースのバグをいくら潰しても、ときどきシステムダウンするようではどうしようもないのに。
組織が大きくなり仕事が細分化されると、全体のことを考えられなくなってしまうことがある。部分最適が集まっても全体としてはいいものにはならない。全体最適を意識して仕事をしよう。そんなことを思い直した。
水曜日に読んでもらうもりで夜中に途中まで書いていたのに、気づいたらパソコンの前で寝てまっていた。ちょっと飲みすぎたか(^^;！
abekkanでした。