バグが減らないときの手当て
テストが始まってしばらく経つのに、バグの件数が一向に減らない。直しても直しても新しいものが出てくる。
このとき、日程を延ばしても解決しないことがあります。減らないのには理由があり、理由によって打ち手が違うからです。まず、バグの「形」を見ます。
■ 週ごとの「新規」と「解決」を並べる
累積のバグ件数だけを見ていても、状況は分かりません。見るべきは、週ごとに新しく見つかった数と、解決した数です。
収束している形 新規が週ごとに減り、解決が追い越していく。このまま進めて問題ありません
収束していない形 新規が減らない。解決が追いつかない。このままでは終わりません
収束していない形が2〜3週続いたら、作業を続けるより先に、原因を切り分けます。
■ 原因は4つのどれか
① 作り込みの質が低い
単体テストが十分でないまま結合テストに入っていると、結合の場で単体レベルのバグが大量に出ます。
見分け方は、バグの中身です。「入力チェックが効いていない」「ゼロ件のときにエラーになる」といった基本的なものが多ければ、この型です。
打ち手は、その箇所の単体テストをやり直すことです。場合によっては、作り直したほうが早いという判断もあります。
② テスト設計が偏っている
正常系ばかり先にやっていて、異常系や境界値を後半で初めて試すと、後半で急に出ます。
打ち手は、残りのテストケースの観点を先に洗い出すことです。「これから何が出そうか」が分かれば、残件数の見通しが立ちます。
③ 仕様が揺れている
バグとして登録されているものを見ると、実は「仕様が決まっていなかった」ものが混ざっていることがあります。
これはテストの問題ではなく、要件の問題です。直しても、また別の解釈で出てきます。打ち手は、仕様の確定を先にやることです。
見分けるために、バグを「不具合」「仕様未確定」「改善要望」に分類します。分類すると、本当のバグ件数はかなり減ることがあります。
④ 環境やデータが原因
テスト環境の設定が本番と違う、投入データが現実的でない、といったケースです。これも本体の品質とは別の話です。
環境起因のものを分けて数えると、実際のバグ件数の傾向が見えてきます。
■ バグを分類して数え直す
「バグ200件」とだけ聞くと絶望的ですが、分けると見え方が変わります。
業務が止まる重大なもの ◯件
回避策があるもの ◯件
表示や文言の軽微なもの ◯件
仕様未確定によるもの ◯件
環境起因のもの ◯件
改善要望（今回の対象外） ◯件
この分類を関係者と共有すると、「何を直せば出せるのか」が議論できるようになります。全部直さないと出せない、という前提から抜けられます。
■ 直す順番を決める
件数が多いときは、順番が重要です。
業務が止まるものを最優先
同じ原因から来ているものをまとめて直す（1か所直すと10件消えることがあります）
軽微なものは、まとめて後半に回す
直さないと決めたものは、記録して承認を取る
とくに2つ目が効きます。バグを原因ごとにグルーピングすると、対応の効率が大きく変わります。
■ 報告のしかた
件数だけを報告すると、「まだそんなにあるのか」で終わります。次の形にします。
週ごとの新規と解決の推移（グラフ1枚）
重要度別の残件数
収束の見込み時期と、その根拠
収束していないなら、原因の切り分け結果と打ち手
■ まとめ
バグが減らないときは、件数ではなく形と中身を見ます。新規が減っているかを確認し、減っていなければ、作り込み・テスト設計・仕様・環境のどこに原因があるかを切り分けます。
分類して数え直すだけでも、見えている絶望の半分は消えることがあります。まずは分けるところから始めてください。