2年ほど前に社内用に書いたエントリーだけど、いいこと書いてたので一部修正して公開します。
はじめに
もともと私自身の頭の整理をするためにこのエントリーを書きました。
初めて私とテストされる方や新人のエンジニアは特に読んでいただけると嬉しいです。
私と仕事をしたことがあるエンジニアのみなさま、バグ票（チケットやIssue)のやりとりをしていて「何かやたらこのチケットにリナさん食い下がってくるなー、こだわってるなー」と思うことがあるはずです。
チケットについて突っ込まないとき
普段、チケットを起票するときには原因が何となく予想できていることが多いです。
例 表記ゆれ データベース登録時のエラー JavaScriptのエラー 変数の型間違い などなど
ある程度のパターンがわかっている場合は、「なおしました」と書いてもらうか、あるいは書かなくても修正していただいてチケットを確認します。
チケットに突っ込むとき
時々、全く予想つかないバグが出ることがあります。
その場合はある程度腑に落ちる説明をお願いしています。 理由は、
- 二次被害を抑えるため（今起こっている内容を回避する方法はわかるけど、原因を正しく理解していないと、根 本的なバグを残したままということがあります。
- 他の案件のテストでも、同様のことが起こった場合に過去の経験からバグの解決ができたり、誰に聞けば解決できるか思い出したりできますのでとても重要です。
例：
■バグの現象： 登録画面で誤った入力をした場合にバリデーションメッセージが表示されず、404エラーの画面が表示された。 ■バグの原因： ・バリデーションは入っていたが、バリデーションに引っかかっていたときの画面遷移先が間違っていた。 ・バリデーションメッセージが表示されなかった。
このように、1つの現象に２つバグが含まれる場合、2つとも修正されずに手前の修正（この場合、バリデーションメッセージを表示する）だけされることがあります。
わたしの場合、
- 登録ができていない
- その後の挙動がおかしい
の両方が納得できたときにはじめてチケットをCloseするようにしています。
バグの原因が報告時点で二つとも指摘できればよいですが、現象だけで判明（または予測）できないことも多いです。
ですので、「気持ち悪い」「変な動き」と思った部分が説明を受けて納得できると、Closeすることができます。
うちのエンジニアも良いこと言ってた
バグって１個出てきたらそれを修正して終わりではなくて、必ず同じようなバグがないかを確認する必要があります。これはエンジニア側も常に意識しておいてほしい。
で、「こういう原因でバグでした」という情報があると、同じような箇所を確認できたり、「こういう修正をしました」という情報があれば、その修正ならばこのケースは考慮できてるかな？とか確認できるので、どう修正したかを伝えるのは大事です。
おわりに
つらつらと書いていますが、単に私のこだわりだったり我儘だったりわかってないだけ、ということも多々あると思います。
バグ票は私（テスター）とエンジニアの活動を幸せにするためのコミュニケーションツールだと思っております。
思い込みの部分もあると思いますので、優しいツッコミお待ちしております。
