開発サイドから見るバグ報告の話

こんにちは株式会社イメージ・マジックのsoenoです。

私はフロントエンド側でバグを受け取る側にいます。
いざバグが上がってくると手一杯になり伝えられない報告について。
もらうと助かる報告とその理由などについて書いてみようかと思います。

まず不具合の発生時に報告を上げる側は以下のような思いを抱いているのではないかと思います。
・壊れているので直してほしい。
・クレーム来てるから早く動いてほしい。
・細かいことはわからないけどとにかく何とかして。

急いでほしい、早く結論が知りたい。
そんなときほど初期に上がる報告が重要です。
開発側で報告を受けたとき、いろいろと調べるポイントがあります。
素敵な報告をいただくと調べなくてはいけない箇所が減ったり、
うっすらと見当がついたり、もしくは重点的に確認するべき場所を決定できます。

ではもらってうれしい報告を手軽に書く方法について考えてみます。
あってほしい情報や、必要な項目について抜けなく上げるために
作文などでなじみのある５ｗ１ｈに照らし合わせて考えました。
５ｗ：　いつ、どこで、だれが、何を、どうした。
１ｈ：　どのように

報告時に書く５ｗ１ｈを言うと以下のようになります。

・いつ（When）
内容：バグ発生時刻（特にサーバー周りのバグの時に重要）
理由：記録を確認するときに膨大な情報の中から探す場合、時刻がわからないと探しきれないことがあります。

・どこで（Where）
内容：ネットワーク接続環境など。社内で接続しているかそれとも社外か。遅い回線ではないか。
理由：ネット回線のスピードによる挙動の場合そのスピードでないと再現しないことがあります。
対処する場所、対処可能な部署が違うこともあり得ます。

・だれが（Who）
内容：バグ発生時の環境、ブラウザ、ブラウザバージョン、端末(pc?smartphone?)、OS（windows?mac?linux?…）
理由：特定のブラウザのみで発生する動きがあるので、そのブラウザしか再現しないことがあります。

・なにを（What）
内容：ウェブでいうとどのページの(url等)どの要素に対して操作を行っていたか
理由：ページとどの要素かがはっきりしていると違うページの違う要素を延々調べなくて済むようになります。

・なぜ（Why）
内容：そもそも何のためにその操作をしたか。
理由：操作の意図ですが、想定した操作外での不具合の把握でしょうか。
バグ取りというよりはサイト改修、改善時に知っておきたいところです。

・どのように（How）
内容：バグ発生のための手順
理由：手元の環境で再現するかどうかはとても重要です。壊れていないものを直すためには
どうしたら壊れるのか、どこが壊れるかもしれないのかなど、上の５W総出で類推することになります。
特徴的な動作や、何か心当たりやひらめきがないと難しいということもあります。

追加でもう一つ5w1hでは足りなかった要素として”hope”を足します。

（英語的に正しいかの検証はしません。）

・どうなってほしかったか（Hope）
内容：正しく動いていたらどうなるか
理由：バグと仕様との判断と、一見正しく動いているように見える挙動の際に何が問題になっているかを特定します。

何か特殊な状態があればそれも追記してあるとなおいいです。
例として思いつくものを上げると
・同一画面を複数ブラウザで開いていた。
・ブラウザで戻るボタンを押してのフォーム入力。
等々

この報告を私が読む場合、下に書いた順番になります。
０、特殊な操作、状態の報告
１、どのように（How）
２、どうなってほしかったか（Hope）
３、なにを（What）
４、だれが（Who）
５、いつ（When）
６、どこで（Where）

順番は個人の手法、サーバー担当かフロント担当かで違ってくると思います。
特に抜けて困るのは１、２、３番。
サーバー側は加えて5番。（多分）

早く回答してほしい、今すぐ着手してほしい。
そういうときほど初期の報告が大切です。
そんなこと言ってもちゃんと書いても遅いじゃん。
という意見もあるかと思います。
ですが、ちゃんと書いていなければきっともっと遅かったはず！
というわけでもらってうれしい報告について書きました。

最後に、こちらの記事は一個人としての意見ですのでご注意ください。
フロント周りやってますのでサーバーあたりに抜けがあるのではないかと思います。
開発にもいろいろあります。自分のケースによりあうものを参考にするといいと思います。
（web上に既にきれいに書かれているものもあります。）