バグ報告書（レポート）の書き方。不具合はテンプレートを作って記載しよう。

今回はこの点について言及していきます。

バグ報告書（レポート）とは

テストを通して不具合を見つけた場合、報告書（レポート）に纏めて報告する必要があります。

レポートとしてまとめる必要がある理由としては、
ゲームなどの開発でバグ（不具合）は数百、数千という件数が当たり前に発生し、
それらのバグを1つ1つ修正対応する必要があります。

当然ですが、
この膨大な件数を口頭だけでやり取りしていたのでは忘れや漏れが出てしまうため、
「バグ専用の管理ツール」等を使って、そこにレポートとして溜め置いていく形で管理をしています。

このバグ報告書（レポート）は以下のような流れで使用されます。
（不具合修正の詳細な流れについては本記事のテーマとは少し外れるため、別途記事でご紹介します）

バグ報告書（レポート）に必要な要件

バグは「必ず原因があって発生しているもの」なので、
その原因を明らかにした上で正確且つ漏れ無く不具合発生の起因を記載することが重要です。

レポートとして成立させるために必要なポイントとしては以下のような点があります。

報告書（レポート）の基本（5W1H ※業種問わない基本中の基本要件）

レポートの体裁としてマストとなる点ですが、
まずバグ報告云々の前に「報告書（レポート）の基本」という、
「業種問わず、そもそも人に報告する時にこれは守らないと伝わらないよ」というポイントを守る必要があります。

そのポイントというのは「5W1H」となります。

基本中の基本で特別なものでも何でもないですが、
5W1Hの情報を具体的に記載する事で初めて読み手に伝わるレポートとして成立します。

想定する読み手は常に「その件について全く把握していない人」が読むことを想定し、
予備知識なしでもレポートを読んだら内容が理解できるような記述になるように心がける事が重要です。
（バグの内容によっては4W1Hや3W1Hになることもありますが、必要な情報は網羅しましょう）

バグ報告において必要な観点

バグ報告において必要な観点は以下になります。

①バグ（不具合）の概要

ここでは不具合の内容が「ざっくりどういった内容なのか」を記載します。

詳細な手順などは後述で別途記載するので、
この「概要」では比較的簡易に記載して、
まずはどういった不具合内容なのかを読み手に知ってもらう事を目的とします。

②バグ（不具合）の発生に至る手順

ここでは不具合を発生させるまでの手順を細かく記載します。

上記の「概要」とは逆に、
省略は一切せずに手順を1つ1つ漏らさないように記載する事が重要です。

手順を書く際に注意する点として、
「1つあたりは短く」「分散させて」手順を書くように意識する事が大事です。

以下に悪い例と良い例を記載します。

「スマホゲームで画面Bという場所でボタンBを押すとエラーになった」というようなケースを例とします。

この手順の通りに実際に再現してみようと思った時に、
悪い例は端的に読みづらく、
良い例は1つあたりの手順がコンパクトで分散しているので読みやすいという点が分かると思います。

簡単な不具合であれば悪い例の方でも伝わることはありますが、
複雑な不具合ほど手順が長くなる＝長文になり伝わりづらくなるので、
「1つあたりは短く」「分散させて」を心がける事が重要です。

③バグ（不具合）の発生する頻度（手順通りに行えば必ず発生するのか、偶発的なのか）

バグの発生を確認した際、
「その不具合が手順通りに行って確実に発生するか」というのを数回試す事が重要です。
（3回程度は試しましょう）

よくあるケースとして、

このように、
発生する場合としない場合がある、というような場合、
不具合の条件を特定し切れていないと言えることになります。
（バグは必ず原因があって発生している為）

様々な条件が重ならないと発生しない複雑な不具合などは、
デバッガーがテストをする範囲では特定し切れない事もあります。

そういった時に、
「何らかの条件で発生する場合 / しない場合がある」
という情報があると、
実際に修正対応をするエンジニア側では
「もしかしたらプログラムのここに問題があるかも」
というようにあたりをつけて、バグの発生条件を特定するためのヒントになります。

デバッガー側で極力バグの発生条件を特定したいところですが、
それが難しい場合もあるので、
確実性があるか否かを「◯回中◯回発生」のように必ず記載するようにしましょう。

④バグ（不具合）を確認したversion

テストの対象が
コンシューマー（プレイステーションやswitchのようなTVゲーム）であっても、
スマホゲームであっても、
或いはwebサービス等であっても、
その開発物にはversionというものが存在します。

※新しい機能を実装したり、バグを修正したりする度にアプリやromなどのverが1.0.0→1.0.1→1.0.2のように更新されます

このversionを記載することによって、
「いつから起きているものなのか」を特定しやすくなります。

「どのverでも関係なく発生している」ということもあれば、
「1.0.0では発生していないが1.0.1では発生している」というようなケースもあり、
後者であれば、
「1.0.1になる時に追加した機能などに問題があるかもしれない」というように要因の絞り込みが可能になります。

自分がどのversionで確認したのかは必ず記載するようにしましょう。

⑤バグ（不具合）を確認した端末

不具合が発生した時、
それが使用する端末が要因で発生している場合があります。

例えば、

などですね。

報告書（レポート）にその点が含まれていないと、
何の端末で確認したのかがわからなくなってしまう為、
不具合を確認した端末は必ず記載するようにしましょう。

⑥本来期待されるべき動作

上記までの不具合に関して、

本来どういった動作や表示となるべきなのか、
この点を記載しておく事で、
読み手は「本来こうなるべきであるという点を認識した上で、不具合の内容を理解する事ができる」
というメリットがあるので可能な範囲で記載するようにしましょう。

（正解がわからない場合は仕様を策定する企画陣に確認するなどで、レポートとしての精度が上がり、これをエンジニアが見た時に修正の方向性が伝わりやすくなります）

バグ報告書（レポート）のテンプレートを用意しよう

上記までのレポートの内容を記載するにあたり、
毎回ゼロから記載するのは効率がよくありません。

記載するバグの内容自体は毎回違うものの、
「型（ベース）」は同じなので、
その「型」に当てはめる事でレポートを作成する時間を短縮する事が可能です。
（書き忘れなどの防止効果も望めます）

その「型」のことを「テンプレート」と言います。

上記までの必要事項をもとに以下のようなテンプレート作成しておくことをオススメします。

実際にバグ報告書（レポート）を書いてみよう

今回はこちらのyoutubeの動画の中の「サービス終了と表示されてしまう不具合」を例にしてみます。

こちらのバグをもとに報告書（レポート）を記載してみます。

上記の動画を見た範囲での記載なので、
実際の詳細とは異なる可能性や推察の部分があります。

一部推察の部分もありますが、
報告書（レポート）にまとめると上記のような形になります。

（前提条件として記載されている ”サーバー云々” については少し耳馴染みがないかもしれませんが、不具合が起きる大前提としてこういった設定が必要であるという事で「アップデートにあたってこういった設定が必要である」という程度にご理解いただければと思います）

今回はバグ報告書（レポート）の書き方についてお話させていただきました。

5W1Hを基本として、
バグ報告に必要な上記要素を肉付けできればレポートとしての精度が上がりますので、
ぜひ実施いただければと思います。