「困った」バグレポートの数々から得た「正しい」レポートのための教訓とは

2012年7月18日(水)
森崎 修司

今回は、バグレポートの典型的な問題パターンを紹介します。ここで紹介するパターンは、バグ票ワーストプラクティス検討プロジェクトが収集中の「困った」バグレポートとして挙げられたものを参考にしています。プロジェクトは継続して困ったバグレポートを収集していますので、こちらのアンケートフォームから情報をお寄せください。

それでは、具体例を交えて問題のあるパターンの典型例を見てみましょう。

このバグレポートはいったい何を言いたいのか

システムテストの開始直後

テストエンジニアA:
このシステムでは、連携システムXからの日時のデータのタイムゾーンが他のサブシステムのタイムゾーンと違っていて、ここにバグがよく起こるんだよな・・。今回もそうかもしれないから、まずは、ここをテストしてみよう。

連携システムXを含めたテストの実施中

テストエンジニアA:
ほら、やっぱり。連携システムXからの送信データが過去日付だってエラーが出る。実際にはほぼ同じ時刻なのに・・。今回もこの考慮を忘れてるじゃないか。こういうのを何回もやらされるこっちの身にもなれよ。レポート書くか・・。

図1:テストエンジニアAさんの作成したバグレポート(クリックで拡大)

テストエンジニアA:
これくらい書いとけば少しは反省するだろう。タイムゾーンが統一されていないなんて、恥ずかしいことに気づいてくれればいいんだけど。

一方、バグレポートを見たプログラマBは・・

プログラマB:
なんだこのバグレポートは・・。結局、どの部分を修正したらこのバグレポートを「対応完了」としたらいいんだろう。いろいろ書いてあるけど、最初の連携システムXのところかな??

問題の起こりやすいパターンを意識しよう

困ったバグレポートを大別すると、以下のような4つのパターンに分類できました。

  • バグレポートによってプログラマの反省を促そうとする(冒頭のバグレポートの例)
  • 説明が不十分
  • モチベーションを下げる
  • 必要のない情報が多い

これらのパターンに気をつけるだけで、不適切なバグレポートを書いていないかを簡単にチェックできます。

個別の紹介に入る前に、全体として重要な考え方を示しておきたいと思います。

バグを発見することと報告することは別の作業であり、両方が必要

最初に意識すべきことは、バグを発見することと報告することは別の作業であり、どちらかのスキルがあるからといってもう片方も同じように上手になるわけではありません。発見しにくい致命的なバグを発見できるスキルや経験が身についたからといって、うまく伝えられるようになるかといえば、必ずしもそうではないでしょう。

同様に、うまく伝えられるようになったからといって、バグをやすやすと見つけられるようになるかというと必ずしもそうではありません。バグを報告するにもスキルが必要であり、学ぶことによって改善していくことがあるという意識を持つことが大切です。

では、続いて「説明が不十分」のパターンから具体例を交えて順番に見ていきましょう。

静岡大学

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

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

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