様々な会社で経験してきた内容です。
読み手(開発者)によって求める情報は様々なので、事前に内容の認識合わせをするのが理想的です。
はじめに
不具合起票に必要な内容ではなく、どういったことを気をつけると良いのかを理由と共に紹介します。
不具合に書くべき内容については、有識者に事前に確認しておきましょう。
タイトルだけで事象がわかるように記載する
開発者が不具合チケットのタイトルをみて、
「あ、あの箇所が怪しそう」
とすぐに修正作業に取り掛かることもあります。
そのため、タイトルと不具合画像だけで「どのような不具合かわかる」ことを意識しましょう。
冠に画面名を記載するなどして、パット見でわかるように工夫するのもオススメです。
少しNG例を見てみます
例1) ○○画面で△△ボタンを押下した際の動作がおかしい
遷移先がおかしいというのが「どうおかしいか」がこの表現だと伝わりません。
ボタンを押した際の挙動として、遷移先が異なるのか、表示崩れがあるのか。
タイトルからどのように直せば良いのかわかる内容になっていると良いです！
例2) ○○画面で△△ボタンを押下すると遷移先が××となっている
これはNGということではないですが、「遷移先が××になっている」がどう不具合なのかが伝わりづらいです。
開発側の認識が「△△ボタンの遷移先が××」だとしたら、
「いや、そりゃそういう実装しているからね」
となってしまいます。
遷移先が違うということをはっきりと記述しましょう！
不具合画像を添付する
添付については殆どの場合「必須」と思ってOKです。
タイトルをわかりやすくつけることにも関係していますが、
不具合チケットを1から10まで読む開発者は正直言うと稀です。
不具合内容を素早く理解するには、シンプルなタイトルと添付画像が重要です。
場合によっては画像ではなく動画にしたり、不具合次第ではログを添付しましょう。
ログについては開発者側で仕込んでいるログもあれば、端末から収集できるログまで様々です。
この辺はプロジェクトによっても様々なので、
「ログを添付する際はどのようなログが必要か」を確認してみましょう。
添付画像を編集する
ちょっとした表示崩れや情報の多い画面ですと、未編集画像だと「どこがおかしいのか」が伝わりづらくなります。
シンプルで良いので、添付画像は赤い枠で囲ったり、矢印を使ったりして目立たせる様にすると良いです。
曖昧な表現は避ける
「〜だと思う」
「何かおかしい」
といった内容はなるべく避ける様にしましょう。
「〜だと思う」というのは、自分の憶測が入ってしまっています。
不具合起票では「事実」を書きましょう。
そのため、「だと思う」の内容は確定の情報にして起票すると良いです。
「何かおかしい」という表現については、何がどうおかしいかがわかるのが不具合チケットなので避けましょう。
ただし、QA側で確認できない場合や時間がかかってしまう内容の場合には、
その旨を記載したり口頭でフォローすると良いです。
情報過多にしない
たまにあるのですが、「あれもおかしい！ついでにここもおかしい！」
と情報が多すぎる不具合チケットを見かけます。
その不具合に必要のない情報は避けましょう。
また、1つの不具合チケットに複数の不具合を記載されているパターンもありますが、
同じ不具合だと思っても実際はまったく別の不具合ということは往々にしてあります。
QAとしてもチケットの管理もしづらくなりますし、不具合の修正確認する時も大変です。
基本的には1つの不具合表は1つの不具合で管理する様にし、不具合をしっかりと追える様に管理するのがおすすめです。
特定の条件がある場合は明記する
不具合の発生に特定の条件がある場合は、必ずその旨は記載しましょう。
例えば、iOSでは起きないけどAndroidでは起きる。
という場合はその旨をしっかりと明示します。
不具合チケットには発生端末を書くことが多いですが、「iPhone(X.XX)」しか記載がないと
Andoridは見てないだけなのか、そもそも発生しないのかがわからないです。
不具合が発生した際は「他の端末(環境)でも起きるか」を確認するのが理想的ですが、
それに当てはまらない場合もありますので、こういった特定条件は明示するように日頃から意識すると良いです。
「発生したものだけ記載する」といった不具合起票のルールとするのもオススメです。
その他細かいポイント
丁寧な表現にする
開発している方、仕様を決めている人達、修正確認するテストエンジニア、
不具合チケットは様々な人が見ることがあります。
当たり前ですが、「丁寧な表現」で不具合表を書きましょう。
こんな初歩的な不具合だして！少しくらい確認してくれよ！
と思うこともあるかもしれませんが、
グッと我慢して丁寧に、親切な不具合起票を心がけましょう！
同じ表現を避ける
不具合の詳細を書く場合、タイトルとまったく同じ内容の人がいますが、
なるべく私は避けています。
極論まったく同じであれば詳細を書かなくても良いと思います。
タイトルと詳細が同じになってしまう場合は、
詳細はもう少し細かい内容を書くか、タイトルをシンプルにするか
どちらかを見直してみましょう。
なるべく憶測をかかない
憶測の情報がノイズになるから書かないでほしいという方もいらっしゃいました。
そのため「開発者に伝えたい憶測の情報」は不具合チケットに書くことはせず、
口頭やチャットでのコミュニケーションでフォローする場合もあります。
もちろんそういう人ばかりではないと思いますので、
不具合チケットの備考やコメントにさらっと書くくらいが丁度良いと思っています。
おわりに
不具合起票はテスト活動の中でも難しい業務です。
最初の頃はどういった内容をかけば良いかわからないですし、
テンプレートに当てはまらない不具合が出た場合などは頭を悩ますと思います。
その場合でも、相手に何を伝えたいのかを最優先に考えて起票すると、
少なくとも何が言いたいかわからない不具合チケットは回避できます。
また、慣れないうちは慣れている人にレビューをしてもらうのがオススメです。
不具合チケットを読むコストもありますし、不明点があった場合はQA側への確認のコストも発生します。
手戻りを考えたらレビューした方が良い場合もありますので、是非相談してみてください。
「ここまで情報は必要ない」「これはちょっと情報少なすぎ」
というプロジェクトや会社の文化による所の線引きも見てもらえるのもレビューの良さです。
とはいえ、こちらに工数がかかりすぎて品質保証の業務が疎かになるのは本末転倒ですし、
シンプルに「タイトルだけあればこっちでやるよ！」というプロジェクトもあります。
冒頭でも少し触れましたが、事前に不具合チケットのプロセスや粒度について有識者に確認しましょう。
