上手な不具合報告で、開発者と良い関係を!

handshake01
こんにちは、ヒューマンクレスト 磯部です。
今回はテストの基本中の基本、不具合報告について書きたいと思います。

ここで不具合報告というのは、テストを実行した結果NGが出た際に開発者などへ出す報告のことです。現場によってインシデント、バグ票、チケット、などなど、様々に呼ばれています。
不具合報告の精度次第で、この後の原因解析や修正までがスムーズになることもあり、書き方ひとつで開発者の信頼を失うこともあります。おろそかには出来ない一方で、不具合発見から報告までは出来る限り短い方が望ましいので、スピードも求められます。

そんな不具合報告を上げる時に気をつけている点をまとめてみました。テストエンジニアのみなさまには、「当たり前」という点も多々あると思いますが、参考にして頂ければと思います。

件名を判り易く

読む側が最初に目にする箇所ですので、件名に誤った内容を記載していると先入観で理解が阻害されます。正確かつ簡潔を目指しましょう。

件名は「現象」を記載して、「発生条件」は記載しない方が無難だと思っています。発生条件は後の解析によって追加されたり変更されたりすることがままあるからです。「Win7で〜〜〜のエラー」という件名にしておいて、後から Win8.1でも発生していたということが判ったというようなケースでは、最初に記載した件名が一人歩きして誤解を生むことがあります。

また、本文を全て書き終わった後に、最後に件名が本文と整合しているかどうかは必ず確認します。

言葉は正確に、具体的に

○○画面、○○ボタンなどと要素を記載する場合は、画面上の文言を正確に書きます。
ソフトウェアによっては、画面上に似たような別のボタンがあったり、同じ機能のボタンが画面によって別の名前になっていたりすることがあります。それ自体がUX上問題だという点は置いておいて、不具合報告の際にはまずは事実を正確に伝えることが大切なので、面倒でも画面をしっかり確認します。
また、「送信」「通信」「機能」「実行」など一般的な言葉は、読む人によって解釈が違ったりします。「○○機能を実行したらエラーになった」といった書き方だと、どんな操作を行ったのか伝わらないことがあります。「○○.exeを実行したら〜」「○○画面の○○ボタンをクリックしたら〜」など具体的な記載を心がけています。

期待する結果、実際の結果を分ける

不具合報告をする時だけでなく、「いまどんな結果を期待しているのか」「実際の結果はどうなのか」はテストエンジニアとして常に意識しておくべき点です。アドホックテストのように、期待する結果がはっきり定義されていない場合でも、「不具合だ」と感じる点があったら文章にしてみる癖をつけておくべきです。

特に、実際の結果が不具合なのか仕様なのか自信がない場合に、このあたりが混乱しがちです。実際の結果だけを記載して「これは仕様でしょうか」といった聞き方をすると、どこに疑問や不自然さを感じているのか伝わらないことがあります。
まずは、期待する結果と実際の結果を書いた上で、「こういう理由でこの結果を期待していますが仕様について認識違いがあるでしょうか。」といった表現で仕様を確認すると良いです。

相手の立場に立って環境条件や再現手順を書く

読む側が再現するために必要な情報を全て記載しましょう。
不具合報告を受け取って修正しようとする開発者は、ほとんどの場合、まず手元の環境で再現を試みます。そのために必要な情報は、特定のデータに依存する問題であればデータを示すID、状態遷移に依存する問題なら実行手順など、ケースバイケースですが、相手の立場に立って想像力を働かせることが大事です。

再現条件を明確にした上で報告できればベストですが、実際の案件ではなかなか理想通りにはいかないと思います。発生する条件がはっきりしない場合は特に、「発生しなかった」時の条件も記載します。発生が間欠的(発生したり、しなかったりする)な場合は、○回試行中○回発生といった発生頻度も記載します。この情報は、手元の環境で再現する際に、何回程度試行してみれば良いかの目安になります。

時系列をはっきりさせる

発生日時は必ず記載するべきです。可能であれば、時:分:秒まで記載しましょう。

サーバー側のログを確認する場合は、正確な時刻が判ると解析の助けになります。
いつまでは正常だったか、いつから発生しているかが特定できるような情報も有用です。例えば「昨日の○時頃の時点では同じ操作でも現象は発生せず、本日の○時頃に試した際に発見した」という情報で、昨日から本日にかけて何か変更していないかといった調べ方が出来ます。

前後関係などが複雑な場合は、箇条書きにしたり、表にしたりして判りやすい記載を心がけています。

まとめ

不具合報告について、普段から気をつけていることを書いてみましたが、いかがでしたでしょうか。

開発者とテストエンジニアの接点のひとつでもあり、お互いに協力して問題を解決できれば一体感も得られます。ぜひ、協力して、品質向上に役立てましょう!

このエントリーをはてなブックマークに追加