こんにちは、とのの（@tonono2587）です。
最近自分がどんな仕事をする人なのかが気になったので、少しずつ書いてみようかなと思いました。

今回のテーマ：不具合報告

「テスター」「デバッガー」っぽい仕事といえばバグ探し的なものをイメージするかと思います。
それは確かに仕事の一面ですが、わたしが初めて(難しい〜！)と思ったのは「不具合報告」でした。
目に見えるわかりやすい成果物がでるという点では、それっぽい仕事ではないでしょうか！
というわけで、「不具合報告」では何をしているか考えます。

「不具合報告をしてください」

バグ票/バグレポート/不具合レポート/チケット…いろんな呼び方があるとは思いますが、
何かしらの形式で見つけたバグをエンジニアさんへ報告します。
宛先はエンジニアさんでない場合もあるかもしれないし、改修確認も含めて報告かとは思いますが、
いったんここではレポートを書くことについてのみ考えます。

書きます

これもまた様々なテンプレートやツールがあったりなかったりするでしょう。(それしか言ってないな)
ツールがなんであれ、テンプレで何が用意されていても、
「いつどこで何が起きているか（+どうしてほしいか）」を書くようにしています。
これを書きやすくするためのテンプレなので、書きたいことさえ抑えていれば項目名に惑わされることはないのです。。
惑わされた者は語るのです。。

具体的に

『ソフトウェアテストの教科書』には以下の項目を主に記述するとありました。

検出日
検出者名（不具合報告者名）
検出された環境・手順
再現率
ランク（影響の大きさ）

検出日や検出者名は使っているツールによっては勝手に入れてくれたりするのであまり意識しなくてもよさそうです。
ただ、わたしは普段スマホアプリを見ることがおおいので、
「いつ」起きているかを残すためにそのときの「アプリバージョン」を書くようにしています。
あとからみたときに比較しやすくておすすめです(^^)v

それと忘れていけないのが「タイトル」です！！（要約/概要的なもの？）
レポートは一覧で多数を一度に眺めることが多いので、「画面名」と「何をするとどうなる」みたいななるべく中身がすぐわかるよう気をつけます。
"いつどこで何が起きているか"が自分なりに腹落ちしてからはそこまで迷わずかけるようになってきたんですが、
長すぎず、言いたいことをまとめるのがめっっっっちゃ難しかったです(T_T)

最後に（+どうしてほしいか）ですが、なんのためになおすのか、最終的に何を実現したいのかは、
エンジニアさんというより自分にとって必要な情報になるので整理してから書くようにしています。

2019-10-16追記(最後って言ったのに)
どうしても困ったときはスクショを貼る！
「どこの画面で」とかが一段とわかりやすくなったりします。
でもスクショはあとから検索しづらいし、書きたいことを書いた上での補足的につかうのがいいかもと思います。

書きません

「詳細に書きすぎて逆に言いたいことがわからん」とならないようにだけ気をつけます。
書きすぎているときは文が長くなりがちなので、「。」がつかないなと思ったら要注意かもしれません。
箇条書きをつかうと嫌でも区切れるので整理するヒントになります。

"書きすぎ"といえば他には
「○○を入力してエラーアラートが出ずに▲▲▲が起きる」場合があったとき、
不具合レポートに書くのは"▲▲▲が起きる"部分ではなく
"エラーアラートが出ずに"であることを忘れないようにしたいです。
エラーアラートが出てくれれば▲▲▲は起きないはずだからです。
発生手順の中に別の不具合が含まれているときなども同様です。
いろんな不具合が絡み合っている(ように見える)ときは、落ち着いて細かく分解し、ひとつずつ書くようにします。

あとこれはもう言わずもがな、
あまりに感情的なこと、いわゆる「余計なこと」は書かないように！

"バグ票"で検索して頭に出てくるこのサイトとかは読みやすかったです。
プログラマとテストエンジニアにバトル勃発！正しいバグ票の書き方とは？ | Think IT（シンクイット）

書きたいことが整理できていれば、それらは書くスペースも時間もない！！