ソフトウェアテストの小ネタ AdventCalendar2017（3日目）
僭越ながら、3日目を@mhlycこと私リリカルが努めさせていだたきます。
qiita.com前回はオムそば氏の記事でした。「市場バグを引き起こした優秀なデータたち」という記事で、次にテストするときに試してみたいネタが載っていてテンションが上がりました。
エンジニアに「は？」とキレられたバグ票ワースト5
さて本題です。
テストを生業にしている方は、バグ票、チケット、障害連絡票など呼び方は様々だとは思いますが、いずれにせよテストでバグを見つけた時にそれを報告するレポートを作ると思います。
今回はそんなバグ票の中で、僕が過去にやらかしてきた選りすぐりのワーストプラクティスをお届けします。ぜひ反面教師にしていただいて、有意義なエンジニアライフを送るのに役立てていただきたいです。
では第５位から。
第５位：再現手順が書かれていない
「バグです」と報告したはいいものの、再現手順を書いていなかったせいで「で、どうしたらこのバグが出るんですか？」と聞かれてしまいました。
基本的なことですが、バグの再現手順はできるだけ書いた方が良いです。ちょっと面倒ですが、操作を省略してしまうと読み手には伝わらなくなりますから、なるべく操作手順は飛ばさず全部書きましょう。
第４位：再現手順の通りに実行しても再現しない
今度は再現手順はきちんと書かれているのですが、同じ手順で実行しても再現しないというものです。
「本当に同じ手順でやってます？最初にこれ、次にこれ、最後にこれ、ですよ」
「本当にやってますって！全部同じ手順ですよ」
「環境は？OSとバージョンは何でしたっけ」
「あっ…」
「あっ…（察し）」
これもよくある話ですが、実際にテストをした環境を書いていなかったために再現させることができませんでした。OSだったりブラウザだったり、アプリケーションのバージョンなどの環境情報は忘れずに記載しましょう。テンプレート化しておくのも良いです。
第３位：そもそも説明が意味不明
そもそも日本語として意味がわからないというものです。
例えば、「〜の処理をするとバグになる」とだけ書いてあって、色々と説明が足りない。その処理はどの画面で行う何の操作のことを言っているの？「バグになる」ってどういうことを言ってる？などなど…
テストしているとプロダクトにはどんどん習熟していきますから、何も考えずに書くと前提となる情報が不足しがちです。また、自分の中での呼称と周りのメンバーの認識が合っていないこともあります。一度書いた後に、「これは新人エンジニアが読んでもわかる文章だろうか？」というように見直すことをおすすめします。
あまり書き方に慣れていないメンバーのバグ票は、何度か添削すると書き方が良くなります。（私の場合は入社１年目の時にこの辺の書き方を叩き込まれました）
第２位：個人的な感覚だけで指摘されるのはちょっと…
よくあるUIや画面周りの、「見づらい。」「わかりづらい。」「使いづらい。」などの指摘です。こういう系のバグ票は、読んでもエンジニア側からすると「なんで？」と思いますし、少し極端ですが「あなたがそう思うだけでは？」と思われてしまうこともあります。
なので、こういった感覚的な話をするときは「色が重なっている」とか「マニュアルに〜の時の操作手順が載ってない」とか、「表示まで〜秒かかる」というように事実や数値をベースにした説明にすると理解しやすくなります。自分が見づらいと思ったのはなぜか？どうしてわかりづらい／使いづらいと思ったのか？という理由を探して、その理由をバグ票に書きましょう。
第１位：バグじゃない
これは最悪です。いわゆる「指摘ミス」というやつです。
「バグだ！」と思って見つけて指摘したものの、「そもそも前提となる操作をしていなかった（操作ミスだった）」とか「そういう仕様であり、ユーザの使い方としても困るものではない」などです。当たり前ですがこの指摘ミスを連発すると、どんなに温厚なエンジニアであっても怒りますし、時間も無駄にしてしまいます。指摘ミスはなるべく避けなければなりません。バグを報告するときは仕様の確認を入念に行いましょう。
とはいえ、あまり消極的になりすぎるのも考えものです。「仕様がそもそも不親切」というような、いわゆる「仕様バグ」につながる場合もあります。
きちんと仕様を確認した上で、それでも違和感を覚えるようであれば指摘して、エンジニアに相談してみると良いでしょう。
（確か「ソフトウェアテストの鉄則」の本とかJSTQBのシラバスにも似たような話が書いてあった気がします）
たかがバグ票、されどバグ票
テストしていると多くのバグを見つけることがあります。そのような状況で丁寧にバグ票を書くのは正直しんどい時もあります。
ただ、ここできちんとしたものを書くか、テキトーに書いてぶん投げるかでその後かかるコストは大きく変わります。
たかがバグ票と侮らず、きちんと相手に意図が伝わるバグ票を書いて、エンジニアと円滑なコミュニケーションをとっていきましょう。
