「バグを報告したんだけど、余裕があれば直すって言われちゃった…」
QAとしてテストをされている方なら、一度はこんな経験があると思います。
もちろんお仕事なのでリソースが限られてて、めちゃめちゃお忙しいのも肌で感じて理解してるんですが、、、
正直、検出した問題をスルーされたような気分になって、こんなバグを報告した自分には価値がないのでは…オレはQAに向いてないんだ…きっとそうだ…チクショー…とメンタルにダメージを蓄積する方もいるかもしれません（若い頃の私）
さて、
QAエンジニアとして、重要な役割のひとつが「テスト」です。
このテストから生まれる主なアウトプットが「バグレポート」ですね。
これは検出したバグを修正していただくための重要な通信手段になります。
なにより、バグが修正されなければ品質は上がりません。。。
バグレポートはお手紙です。QAからの直訴状です。
（直訴状って言っちゃうと、修正を見送られたQAは切腹しなきゃいけませんが…）
バグレポートを書く際に注意すべき点はいくつかありますが、（レポートのフォーマットだったり、伝わりやすくするためにスクショや動画を添付するなど：この辺はいつか書きたい）
特に重要だなと常々思っているのが、「そのバグレポートは誰宛なのか」 です。
バグレポートは文字通り「お手紙」であり、
QA担当者の「このバグを修正して欲しい！」という意志を伝えるツールです。
それは、誰に宛てられ、その人が何を修正すべきかを理解できるように書かれているかどうかが問われます。
ちょっと具体的にイメージ
- 単純に機能としての不具合：担当エンジニアさん本人に宛てて書く
- デザインとの差異：デザイナーさんを思いつつ書く
- せっかくあんなに素敵なデザインなのに、実機ではヘンな見栄えになっててやりきれない…
- エッジケースでユーザーが不利益を被る可能性がある：PMさんに宛てて書く
- 「このバグのせいで、どんなユーザーがどのように困るのか」を具体的に説明し、その影響がどのようなユーザーや環境に及ぶのかを明確にすることが重要になります。
- 場合によっては、端末やブラウザのシェアのデータを添えることも。（8.7%って、ユーザーさんxx人もいるのか…など想像しやすい）
修正されなきゃ意味がない（とも言い切れないけど）
「報告した数 / 修正された数」は、バグ修正率として可視化でき、それは「品質を向上させた数」を示す一つの指標となります。
つまり、修正されてこそバグレポートの意味があると言えそうです。
しかし、すべてのバグレポートが可視化できるわけではありません。
テストはシステムの健康診断のようなもので、システム全体の状況を把握するためにも、可視化できない報告も非常に重要ではありますね。
まとめ
バグレポートを起票する際は「誰に刺すか」を明確にイメージして、
「どう書けばあの人に刺さるだろう…」とその人が理解しやすく、かつ具体的な修正行動を取れるような形で書くことを心がけることが大切です。
それにより、少しでも品質を向上させることができたら嬉しいですね！
（補足）この記事はChatGPTに主題と具体的にアレコレ入れて生成されたものを大幅に加筆修正しました
それでは！良いバグレポートライフを！
（この記事を読んだ知り合いのエンジニアさんに「いや、あなたのレポート、わかりにくいけどね…」って言われるんじゃないかとビクビクしながら筆を置きます）