バグレポートでテストエンジニアとプログラマが持つ“認識の違い”を埋めるには

テスト終了後にバグレポートの項目を見直す

論文での調査をみると、バグレポートの項目の中には報告者と開発者で考えが一致するものと一致しないものがあることがわかります。

何が大事な項目かは、報告者と開発者で共有できている情報の豊富さ、報告者と開発者のスキル、対象ソフトウェアやプロジェクトの特徴に依存します。前のページの例では、開発者が挙げた役に立つ情報として「スタックトレース」や「スクリーンショット」が出ています。論文の調査対象はオープンソースソフトウェアであり、分散環境において役に立つ情報が挙げられていると考えることができそうです。もし調査対象が対面でのコミュニケーションが頻繁にとれるようなプロジェクトであれば、結果も異なってくるでしょう。

テストが終わってリリースできたら、もう一度バグレポートを見直してバグレポートの項目を改善していくことをお勧めします。組織で標準のものがあれば、すぐに項目を増減することは難しいかもしれませんが、不便がある中でいつまでも同じものを使うことは健全ではないでしょう。標準化の担当の方にも要望を出しつつ不便を減らしていきます。

冒頭の例のように役に立っているかどうかをテストエンジニアとプログラマの間で比較する方法は大きな手間をとらずに実施できます。その他の改善にむけた具体的な方法をみていきましょう。

複数のバグレポートに共通した質問をみつける

（1）バグレポートに記入してほしい情報が項目として設けられているか、また、（2）必要のない項目が存在し続けていないかを確認しましょう。バグレポートのやりとりをみていると、バグの再現や症状を確認するために、よく聞き直されている内容がみつかることがあります。

例えば「ミドルウェアやOSのバージョンは？」「毎回再現するのか？」「以前のバージョン（ビルド）では起こっていたか？」といったやりとりがあるならば、「バージョン」という項目や「再現性」という項目を追加することで、これらのやりとりを減らすことにつながります。

選択肢は適切に選ばれているか

同様に、削除した方が効率化につながる項目もあります。標準化にこだわりの強い組織では、項目の削除は難しいことが多いのですが、意味のない項目を残しておくのは好ましくありません。選択肢式の入力項目で同じ選択肢が、ほとんど全てのバグで選択されているものを目にされたことはないでしょうか。

例えば、バグ修正の優先度合いを決めるために、「急ぎ」「普通」「急がない」という選択肢を持つ「緊急度」という項目があるとします。ほとんど全てのバグに「急ぎ」が選択されている場合には、項目「緊急度」を使って優先順位を決めることができないため、選択肢の選び方の基準を定義し直すか、「緊急度」という項目を削除することを検討します。

項目が多すぎる、また歴史的経緯で定義されている項目でなぜ必要なのかよくわからない、という場合には、項目を以下のように分類し整理することをお勧めします。

そもそもバグレポートにはどのような項目が必要か

バグレポートの項目は、「修正」「管理」「振り返り・改善」の3つに大別できます。

「修正」は、バグの再現や修正に必要な項目であり、バグの症状や再現方法といった項目が含まれます。

「管理」は、複数のバグ修正を円滑に進めるために必要な項目であり、検出日時、バグのステータス、修正担当者、修正確認者（修正が完了したと判断した人）、優先順位、重要度といった項目が含まれます。

「振り返り・改善」は、プロセスや将来の開発作業を改善したり効率化したりするための項目であり、混入原因、検出工程（検出作業項目）といった項目が含まれます。混入原因が偏っていれば、その原因を防止するためのテストやレビューを強化する等の改善策をとります。

3つの目的毎に、先ほど述べたような必要な項目、不要な項目、選択肢の見直しといった作業を実施します。

ここまでがバグレポートの項目の改善です。最後に、テストを実施する前の事前合意を紹介しておきます。