バグレポートでテストエンジニアとプログラマが持つ“認識の違い”を埋めるには
今回はバグレポートにおける記入項目の改善と、テストエンジニアとプログラマがテスト前に行う事前合意について紹介します。どちらも、本連載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サイトで論文や資料が公開されています。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- プログラマとテストエンジニアにバトル勃発!正しいバグ票の書き方とは?
- JUnitの利用
- 「困った」バグレポートの数々から得た「正しい」レポートのための教訓とは
- eBPF FoundationとLF Researchがクラウドネイティブで注目される「eBPF」に関する調査レポートを公開
- エンジニアのスキルを伸ばす“テスト駆動開発”を学んでみよう
- エンジニアの業務を効率化する生成AIによる「プログラミング支援」
- やさしい「Apache」と厳しい「GPL」、IoT標準化に最適なライセンスはどちらか
- やさしい「Apache」と厳しい「GPL」、IoT標準化に最適なライセンスとは
- やさしい「Apache」と厳しい「GPL」、IoT標準化に最適なライセンスはどちらか
- eBPF Foundation&LF ResearchがeBPF技術の進化とオープンソースエコシステムへの影響を調査したレポート「eBPFの現状」日本語版を公開