とあるプロジェクトで不具合の検出傾向を調べた際、大量のバグレポートを確認して気になる表現がありメモを書き起こしてみました。

前提

• 自分はプロジェクトの途中にテスト設計者の立場で参画

• テスト実行者は全員テスト業務の経験が1ヶ月程度

• BTSに入力項目が用意されており、基本的な報告内容の抜け漏れはない

気になった内容と所感

• 不具合の説明が抽象的
  例：◯◯機能で計算された数値がおかしい
  
  「おかしい」の詳細が明記されていない（計算結果のUI？計算結果？）
  ドキュメントなど、問題だと判断した比較材料を提示することで開発者の調査を円滑に進められるようにしたい。

• 1つのバグレポートに2つ以上の事象を記載
  例：ボタンAかボタンBを選択するとアプリが強制終了する
  
  同じ強制終了でも、ボタンによって根本原因が異なる場合もある。
  開発者がどちらか一方の原因について調査や修正を失念する可能性も考慮して、バグレポートを分けて起票したい。

• 不具合の発生頻度が不明
  例：アプリの強制終了が発生する場合がある
  
  100%発生しない不具合は「10回中3回発生」など頻度を明記する。
  重要度が高い不具合かつ発生頻度が低い場合、動作ログを取得するといったアプローチも検討したい。

• 不具合の回避手段があるか不明
  例：◯◯操作をすると画面が真っ黒になる
  
  真っ黒の状態で画面の操作や遷移ができるのか、フリーズして操作を受け付けない状態なのかにより深刻度が変化する。事象のエビデンスを取得しつつ、周辺的な確認も忘れないようにしたい。

• エビデンスを見ても問題箇所を特定できない
  例1：無加工のスクショが添付されている
  例2：長時間の動画が添付されている
  
  スクショは問題箇所を赤枠で囲むなどすることで、どこで問題が発生しているか一目瞭然となる。
  動画の場合は問題を把握するために「最初から最後まで視聴が必要か」「◯分◯秒で問題が発生している」など備考欄などで開発者に伝えられるようにしたい。
  これらの工夫により僅かであるがコミュニケーションコストの削減を期待することができる。
  また、システムがハードと接続している場合、システムとハード両方の状態が分かるエビデンスを取得するようにしたい。

• バグレポートに重要度が設定されていない
  BTS(Jiraでした)にフィールド自体存在しなかったので、プロジェクト運営側の問題となる。
  
  不具合分析や修正の優先順位を考慮する上で必要な情報となるので、カスタムフィールドを追加してもらい重要度を付与したのだけれど、「バグレポートが1000件以上あって大変でした」という話を同業者が集まるワークショップで話したらドン引きされたのはまた別のお話。

最後に

バグレポートの内容に焦点を当てた話でしたが、環境を振り返るとレポートのレビューがされてないプロジェクトなことも質が低いと感じる表現が出てくる要因の1つかもしれないと思いました。個人のスキルのバラツキをカバーできるような体制もあるといいですよね…。（遠い目）

この記事を反面教師に、自身でバグレポートを起票する際は分かりやすく手戻りがない内容を心がけたいです。