ひとこと技術メモ：バグ報告

～この記事は、中の人の主観が100%含まれています。～

受け入れテストレベルでバグ報告をする際は、以下の点に気をつける。

※「本当はこうなってほしい」は明らかなバグの場合（ウィンドウ右上の[×]を押しても画面が閉じない、等）は省略可。

システム開発マンはこの内容をすんなり書けるようだが、どうも慣れていない人は「どうなった」しか書けないみたい。

慣れてない人も受け入れテストに加えるなら、慣れている人が上記4点セットの報告テンプレートを作っておくといいかも。

たとえばこのブログ画面を受け入れテストしているとして、

メニュー項目を選択したら幅が広がる

という報告ではなく、

サイドバーのカテゴリーのプルダウンリストをクリックすると、サイドバーの横幅が通常より広がります。サイドバーの横幅はプルダウン選択有無問わず、一定としてください。

としたほうが、すんなり聞き入れてもらえる。
前者の書き方だと「どの画面ですか？」「どうするのが理想ですか？」と聞き返され、手戻りが発生し却って時間がかかる。

スクリーンショットや図示をする手間も惜しまなくてよい。
うまく作れば「どの画面で」「どう操作したら」「どうなった」の3点を1枚で説明できるから。

あと、プロダクトレベルならば、これは「バグ」なのか「要件定義漏れ/変更」なのかも示すとよい。
バグなら対応優先度もつける（修正できなければリリース不可なのか、軽微なのでリリース後でもよいのか）。
基本的に、対応優先度は「要件定義漏れ・変更」＜「影響低のバグ」＜「影響大のバグ」。

要件定義漏れ・変更は、発注側に責任があるからね。相手に無理は言えないよね。

追記

忘れてた。

「再現する環境」「再現性」「どのバージョン（バージョンという概念がなければ確認日時）」も必須レベル。

ブラウザアプリならOS・ブラウザ名、スマホアプリならAndroid・iOSのバージョンや端末名。
100%起きるバグでなければ、「体感3割の確率で」とか添えておく。
バージョンは入れ違いになったとき用に必要。こちらがバグ報告をするとき、先方はすでに見つけていて修正作業をしているかもしれない。