バグチケットの書き方

チケットに書く内容

バグの内容。何が起こったのかを書く

不具合の再現手順。とりあえず箇条書きで並べればOK

不具合が発生する環境の情報。システムのバージョンとか構成情報とか

受け入れ条件。期待していた動作を書く。「どのような状態になったらOK」という話を正確に伝えろ

（以下、↑上のページを読んだメモです）

例えば、

「花火大会で発生した事故」のバグチケット

筒に発射火薬を入れ、花火玉をつめ、落とし火を入れた。

そうしたところ、花火が横に射出され、観客席に飛び込んでから爆ぜた。

バグは「筒が横に倒れていた」こと

不具合は「花火が横に発射される」こと

受け入れ条件は「花火が上に発射される」こと

チケットのタイトル

どんなタイトルがいいのか？

→ バグによって「起こったこと」を一言で書く。

これをタイトルにすると、書いてある内容のイメージがしやすくなる。

例：花火の玉が横に射出されたバグチケットのタイトルを考える場合

観客席で花火が爆発した

→これは「連鎖した結果」なので微妙。

「けが人が出た」「救急車が来た」というバグチケと変わらない

花火がおかしい場所に飛んだ

→これは情報量が足りてなくて惜しい。

「おかしい場所」ってなんだ。どうおかしいんだよ。

だから、発生したその「おかしい」事象を客観的に表現しろ。

花火の玉が横に射出された

→わかりやすい。発生した不具合の要点を捉えている。

つまり「何が起こったのか」を書くと、タイトルを読んで何が起こるのかがイメージしやすくなっていいのかも

花火の筒が横に倒れていた

→これは「不具合の原因」なので微妙。

横に玉が発射されるという不具合を指摘できていない

バグの報告には必ずしも原因が含まれている必要はない。バグの調査は対応を担当した人の仕事なので特に気にしなくてよい。あるとバグ対応する人が助かるというレベル

バグの原因は筒を横に設置するような設計になっていたのかもしれないし、間違えて筒を横に設置してしまったのかもしれない

バグ報告っていうのは、開発者がいま取り組んでいる作業に割り込むものだ。だから開発者は殺気立つ。そして、それが高品質なバグ報告であれば心がなごむ。雑なバグ報告は殺意を高めてしまう。

現場に修羅を発生させないためにも、作法にのっとったバグチケを起こせ。