こんにちわ、アイスリーデザインの荒澤です。
最近、寒くなったり、暖かくなったり寒暖の差が激しいですね。風邪を引かないよう、体調管理には気をつけていきましょう。
さて、今回はバグレポートについて書いていきます。そもそもこれは、テスト担当者が開発者に向けてバグ報告をするためのもの。テスト担当者の方なら『そんなこたぁ知ってるよ！』と仰る方もいらっしゃるかと思います。最近では、テスト担当者以外の方もバグレポートを書くようになってきました。
さて、自分が書いているバグレポートは本当に良いものと呼べるのでしょうか？その振り返りのために、目的、そしてどう書くのかにフォーカスして今回の記事を書いていきます。
目次
目次
1. なんのためにバグレポートを書くのか
そもそも、バグレポートは何のために書くものなのでしょうか。
簡単に言うと、テスト工程中に開発者に「テスト実施中に期待していない結果がここにあったよ?」とテスト担当者が教えるものになります。
そのため、問題の現象を再現できるように調査をし、開発者がスムーズにバグ修正ができるようなレポートを書く必要があります。
また、開発者がそのレポートをもとに修正をしますので、できるだけ問題の切り分け等も行ない、詳細に情報を共有する必要もあります。
内容が曖昧であったり、意味不明なバグレポートは開発者を困惑させ、
結果的に自分が意図していなかった場所が修正されていたり、
バグの発生場所が特定しにくくなったり...などといった大変コストパフォーマンスの悪い状態になる可能性があります。
2. バグレポートに何を書くのか
では、バグレポートには何を書けばよいのでしょうか。
今回参考図書として『現場の仕事がバリバリ進む ソフトウェアテスト手法』より、ポイントを確認します。
◯要約して書く
まずは、問題の内容をダラダラと書かない事が大切です。
的確に問題のポイントをビシッと簡潔に書くと、開発者も何が問題なのか理解しやすくなります。
そのため、再現手順を記載すると、どこのコードで問題が起きているのか、
開発者側がいちいち探すことに時間をかけずに修正することができます。
◯正確に
「かもしれない」「たぶん...」と言った曖昧なレポートは価値が下がり、良いレポートとは言えません。
バグレポートは正確に、そして事実を伝えることが大切です。
◯ニュートラルな立場で
もし、同じようなバグが複数あっても、開発者を責める様な記述は避けましょう。
それよりも、クリティカルなバグを見つけていくことが重要です。
■[おまけ]デバックの手助けをする
出来る限り、開発者の手助けになるような情報をレポートに書くと良いです。
例えば、以下の項目が上げられます
・問題の切り分け
→コードの問題なのか、ブラウザの問題なのか、端末の問題なのか...。
・エラーログやエラーメッセージ
・ダンプ情報
しかし、テスト担当者の仕事はあくまでバグの再現手順などを共有するまでです。
3. バグレポートのフォーマット
バグレポートには「これを絶対書かなければいけない！！」という決まりは存在しません。
ただ、バグレポートのフォーマットを作成しておくと便利です。
例として、弊社では以下5項目「画面/URL」「現象/手順」「期待する結果」「機種/OS/ブラウザ」「エビデンス」をバグレポートに記載しています。
こうしたフォーマットを用意しておくことで、
時間短縮に繋がり、効率的に起票できるのではないでしょうか。
4. まとめ
今でもバグレポートを書いた時、開発者から『もっと詳しい情報を教えてほしい。』とリクエストをいただくことがあります。そういったことから、『じゃあ、次はこの情報も書くようにしよう！』と反省点を活かすようにしています。完璧なバグレポートを書くことは難しいですが、毎回できる限りの情報を開発者に共有することはできます。
よりよいバグレポートが作成できるよう、一緒に頑張っていきましょう。
