バグ票の改善観点の紹介と、やりやすいところからの改善のおすすめ

これはソフトウェアテスト Advent Calendar 2017の14日目の記事です。
この1年、バグ票ワーストプラクティス改善プロジェクトというコミュニティで活動して、得たこと、感じたことを書こうと思います。

そもそもバグ票はなんのために書くのか?

バグ票の一番大事な目的は、バグを直してもらうことだと思っています。テスト実施者がバグを見つけ、それを開発者に伝えてバグを直してもらう、そのためのコミュニケーションツールですね。

バグ票のどういう点が問題になりやすいのか?

先日、ソフトウェアテストの小ネタ Advent Calendar 2017の記事である、リリカル氏のブログ記事「エンジニアに「は?」とキレられたバグ票ワースト5」を見ていただくとよく分かりますが、バグ票はよくテスターと開発者の間で問題になります。
・再現できない
・そもそも何がもんだいなのかわからない
・テスターと開発者、または、複数社またがる開発だと開発会社間などで
 やたらとコメントのやり取りばかりが続く etc
色々パターンはありますね。

バグ票改善観点のご紹介

そんな問題の起こりやすいバグ票を改善するためのヒントとなる本を紹介します。

Bug Advocacy: A BBST Workbook (English Edition)

Bug Advocacy: A BBST Workbook (English Edition)

コミュニティが主催/担当したワークショップで何度か紹介してますが、
こちらは、Cem Kerner, Rebecca L. Fiedler らが2015年7月下旬に出版した書籍で、著者が大学で行った講義の内容をまとめたものになります。
講義資料や、実際の講義のビデオもこちらのサイトから見られますので、興味のある方はぜひどうぞ。

おすすめポイントは、バグ票改善のヒントとなる「RIMGEN」の観点を学べることです。
RIMGENとは、バグ票の記載内容を改善するための6つの要素の頭文字をつなげたものです。

  • Replicate(再現性):再現できるか
  • Isolate(独立性):単純な手順となっているか、1件/レポート となっているか
  • Maximize(発端性):最悪なことが起きるバグの兆候をみつけているか
  • Generalize(普遍性):プロダクトに対するバグの影響範囲を識別できているか、そのバグは他の環境や条件で発生することはあるか
  • External(第三者性):プロダクト利用時にバグの影響範囲を開発者やテスト担当者、開発組織外の視点から識別できているか
  • Neutral(中立性):困惑させるような推測や思い込みなどがないか

※日本語訳は、つけてみたものの、自分でもしっくりきてないところがあるので、何かよい訳があればコメントいただけると助かります。

バグ票の見直しを行う場合や、バグ票の書き方について教育を行う場合に参考にできると思います。

バグ票が、このRIMGENの観点にそって書かれていない場合には次のような問題が起こると考えています。
まず、大きな問題として「関係者間の信頼関係が崩れる」ということがあげられます。
もう少し細かく分類すると

  • 再現不能なバグとして却下される
  • 修正されるべきバグにフォーカスが当たらない
  • バグの内容を理解するのに時間がかかる
  • バグが非現実的、不合理として却下される

ということがあげられます。

バグ票の改善をやりやすいところから始めよう

上であげた問題と、RIMGENの観点、改善ポイント、改善難易度をマッピングしてみた図です。

図の通り、観点によって改善のやりやすいもの、やりにくいものが存在します。
個人的なおすすめは、比較的取り組みやすい「書き方で防げる問題」の対処から始めることです。
可能であれば、開発者とテスターに集まってもらい、
何が書いてあればお互い困らないかを話して、その場でフォーマットを決めてしまうとよいと思います。

ワークショップで、困ったバグ票のサンプルを提示し、それを改善するためのフォーマットを作るという試みをしましたが、
だいたい、どこでも「ファクト・事象」「再現手順」「期待する動作」はフォーマットの内容として挙がってきました。
それだけ、多くのバグ票関係者が困っているところであり、逆にここが改善されると効果の大きいところなのだと思います。
再現手順欄がなければ、欄を作る。
欄があっても書いてくれなければ、理由をヒアリングして対処を打つ、などやりやすいところから着手していくと
テスターと開発者の間で伝わるバグ票に一歩ずつ近づけるはず、と思って活動してます。

まとめ

バグ票の目的は、バグを直してもらうことです。そのためには伝わるバグ票を書くことが必要です。
紹介したRIMGENの観点を使って、やりやすいところから改善することで、お互いに伝わるバグ票を書きましょう!