バグを発見した際に考える範囲

最近、バグを見つけた際に考える範囲は人によって異なるなーと気づきました。

どういう違いがあっただろう、と考えると色々浮かんできたので、自分の経験から発散してみます。

考える範囲

「テストの判定基準を満たしていないこと」のみを確認
　
バグが発生する条件や環境があることを確認
　問題が複雑な場合、1.から
　・バグ報告→原因が分からず→再現調査
　・バグ発見→以降再現せず→条件を変えて再現確認
など繰り返す内に、判定基準以外にも目をむき始めます。
　
　また、報告前に発生条件を特定できるかどうかは力量や状況によって違います。そういう人はあれこれ操作して、バグの原因となる条件に目星を付けてからバグチケットを作成しているように見えます。
過去にも同様のバグがないか確認
　バグが確定したとしても、
　・今回の開発 / 修正が影響して生まれたバグ
　・既存のバグ
　か切り分けます。
　
　また、既存バグであれば過去のテストを振り返り、
　・テストケースがない→網羅漏れ
　・テストケースはあるのに期待結果が違う→テスト設計ミス
　・正しいテストケースがあり、実行済み→実行ミスによる見逃し
　など、どのテストに原因があって、防げたかどうかを確認します。
バグの原因を考える
　仕様検討不足か設計時の検討漏れ、など作る過程でどこが原因だったかを考えます。
バグを見つけたテストが妥当だったかを確認
　単体テストからシステムテスト、システムテストの中でも色々な種類があり、それぞれ目的が異なるので、目的に沿って検出できたか確認します。
　もしNoなら、どこで見つかるべきだったかを確認し、そのテストへFBします。

考える範囲を広げること

　毎回これら全てを考えるべきだとは思いませんし、特定に時間をかけすぎることが妥当かどうかもチームによって異なるかと思います。
　個人的には色々な考えを巡らせることにはメリットがあると考えます。

修正確認の質を高める
　当たり前ですが、バグは修正されたことを確認するまでが大事です。
　バグ検出時点で原因などに考えを巡らせることで、修正方針に対して意見を伝えることができたり、修正確認の質が高まります。
バグの原因やテスト実行・環境構築のトラブル特定が早くなる
　毎回踏み込んで考えることで、製品のロジックや構造への理解が深まり、新たなバグを見つけた際も再現手順や条件の手札が多くなります。
　また、車載製品の評価の時に多かったのですが、なかなかテスト実行や環境が上手く組めず、機材も多いので手順or環境or製品のどこに原因があるか特定が難しいことがありました。こういった時に手札がないと絞り込むことができません。
楽しくなる
　これが一番メリットだと思いますが、詳しくなると考える幅が広がり楽しいです。

考える範囲を広げるには

　バグチケットの入力必須項目を決めると考える範囲の最低限の統一ができると考えられます。

　毎回チケット起票者に提供してほしい情報を検討して入力必須にすることで、一定標準化できると思います。

最後に

　途中、バグ分析の話になった気もしますが、ふわっとしていたことを書き出しました。
　まだ考える余地がありそうなので、適宜更新しようと思います。