バグについて

考えてみた。

とりあえずバグには２種類のものがある。

• 単純バグ（仕様に「○○と表示」と書いてるのに××って表示されてるとか）
• 複雑バグ（一定条件でのみバグになるものとか）

単純バグが多いということは、ちゃんと作ってんのかよ、と思われる。
複雑バグは早く見つかるほどうれしい。複雑バグの報告書の文面でテスタの質が割とわかる。

バグは見つかったら直さないといけない。で、そのときに新たにバグ入れがないことが重要だ。というわけで、バグによる修正ボリュームは重要な指標になる。

バグが出た個所も重要だ。業務アプリの表面のバグなら直せば終わりだが、業務のメイン部とか共通部とかだと、他に影響がないかかなりびびることになる。

あんまり言いたくないが、バグが多い機能にはスキルの低いプログラマの存在が欠かせない。スキルの高いプログラマは自分のプログラムがバギーにならざるを得ないシチュエーションに追い込まれると、原因を騒ぎ立ててリリースしない（そうあるべきだ）。

バグが極端に少ない場合は必ず理由がある。スーパープログラマーがいたとか、テスト仕様書に厳密さが足りなかったりとか、テスタがいいかげんだったりする場合とかだ。

僕が管理していた開発チームがある一連のテスト項目で１件もバグを出さなかったことがある。テスタが「バグが１件も出なかったんで、やりかたが悪いんじゃないかと疑われて、別のテスタがやりなおすことになりました」とがっかりしていた。

でも、そのテスト項目は、実は開発中に僕がバグを発見して、開発チームに全機能に対して対策の水平展開をリクエストしていた機能だった。そして、システムテストレビューのとき、その項目をテストすべきだと主張したのも僕だった。なんか自作自演のようだが、開発チームが全部ちゃんと直してくれているかどうか検証しないといけないからね。

というわけで、バグがないのには理由がある。