PR

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

2012年8月1日(水)
森崎 修司

今回はバグレポートにおける記入項目の改善と、テストエンジニアとプログラマがテスト前に行う事前合意について紹介します。どちらも、本連載1回目2回目の、バグレポートを書く上での留意点よりももう少し大きな枠組みとなります。

まず、記入項目の改善の必要性を示す調査結果を示します。調査は、テストエンジニアが役に立つと思うバグレポートの情報とプログラマが役に立つと思うバグレポートの情報が一致しているかを調べたものです。

標準が決まっているからそれに従う、昔からこの形式を使うことが決まっている、といった理由で今のバグレポートの項目を使っているならば、見直しによる改善のチャンスがあるかもしれません。

バグ報告者と開発者の間で役立つと思われる情報の比較

表1は、「What Makes a Good Bug Report?」という論文で、オープンソースソフトウェアの開発とバグレポートに関わっている人を対象に、以下の項目でアンケートを実施して結果をまとめたものです。

  • (a) 報告者が入力している情報と開発者が使っている情報
  • (b) 報告者が入力している情報と開発者が最も有益だと思っている情報
  • (c) 報告者が有益だろうと思っている情報と開発者にとって有益な情報

表1:報告者と開発者との間の比較
(背景色がある情報は報告者と開発者の順位が一致しているもの)

順位 (a)報告者が報告している情報と開発が使っている情報の比較 (b)報告している情報と開発者にとって有益な情報の比較 (c) 報告者が役立つと考えている情報と開発者が役に立つと考えている情報
報告者 開発者 報告者 開発者 報告者 開発者
1 再現方法(98%) 再現方法(97%) 再現方法(98%) 再現方法(83%) 再現方法(78%) 再現方法(83%)
2 現象(96%) 現象(95%) 現象(96%) スタックトレース(57%) テストケース(43%) スタックトレース(57%)
3 期待する動作(94%) 期待する動作(89%) 期待する動作(94%) テストケース(51%) 現象(33%) テストケース(51%)
4 プロダクト名(94%) スタックトレース(89%) プロダクト名(94%) 現象(33%) スタックトレース(33%) 現象(33%)
5 バージョン(91%) テストケース(85%) バージョン(91%) スクリーンショット(26%) 期待する動作(22%) スクリーンショット(26%)

出典: N. Bettenburg, S. Just, A. Schroter, C. Weiss, R. Premraj and T. Zimmermann: What Makes a Good Bug Report? Figure 3から一部抜粋

アンケートはApache, Eclipse, Mozillaを対象に、(a), (b), (c)それぞれについてバグ報告者と開発者466人に回答してもらったものです。パーセンテージは、報告者の何パーセントが役に立つと回答したかを表しています。1人が複数回答することができるため合計が100%を超えます。

例えば、(a)の報告者の回答として「再現方法」がありますが、アンケートに回答した報告者のうち98%が報告していると回答したことを意味しています。表では、このパーセンテージが大きいもの上位5項目を記載しています。

「(a)報告者が報告している情報と開発者が使っている情報の比較」では、上位3位(再現方法、現象、期待する動作)が一致しており、回答した報告者、開発者の割合も類似しています。適切な項目が設定され、それに従った情報が提供されていることを示しているといえます。

「(b)報告している情報と開発者にとって有益な情報の比較」では、一致しているのは1位だけでした。開発者が有益な情報と考えている情報の1位は「再現方法」であり、開発者の83%が回答していますが、2位の「スタックトレース」は57%の開発者が回答としており、1位と比較して割合が小さくなっています。他にも報告者の96%が「現象」が有益と考えていますが、開発者は33%しか有益と考えていないという結果が得られており、報告者と開発者との間でギャップがあることを示しています。上位5位には「再現方法」と「現象」以外には共通する項目がありません。

「(c)報告者が役立つと考えている情報と開発者が役に立っていると考えている情報の比較」では、両者共に「再現方法」と回答しています。また、上位5位には項目「テストケース」「現象」「スタックトレース」が同一順位ではないものの報告者、開発者の両方の結果に含まれています。

この調査から何がいえるのでしょうか。次のページで具体的にみていきます。

*: N. Bettenburg, S. Just, A. Schroter, C. Weiss, R. Premraj and T. Zimmermann: What Makes a Good Bug Report?, Proceedings of the 16th International Symposium on Foundations of Software Engineering, p308-318(2008). 著者のWebサイトで論文や資料が公開されています。

静岡大学

2001年、奈良先端科学技術大学院大学 情報科学研究科 博士後期課程修了。情報通信企業において、サービス開発やシステムインテグレーションに従事し、企画、設計、実装、開発管理、品質向上を実践する。奈良先端科学技術大学院大学 情報科学研究科 助教などを経て、2011年4月より現職。不具合情報の分析、ソフトウエアレビュー、ソフトウェア計測、実証的ソフトウエア工学を研究の柱としている。
研究グループのWeb:http://ese.inf.shizuoka.ac.jp

連載バックナンバー

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています

バグレポートでテストエンジニアとプログラマが持つ“認識の違い”を埋めるには | Think IT(シンクイット)

Think IT(シンクイット)

サイトに予期せぬエラーが起こりました。しばらくたってから再度お試しください。