「効率的なバグ報告をする方法」記事へのコメント

効果的に報告をしたつもりでも

[Anonymous Coward]

受け取る相手に寛容さが皆無な場合は悲劇にしかならない。

「このファイル(相手もアクセス可能)を読み込んで、こーやってあーやって操作すると、こんなメッセージを吐きました。メッセージから推測すると、これが原因ではないかと思うのですが」

という私の報告に「あんたのファイルが悪いんだろ(文章は当然違うが、文意は同じ)」と返事が返ってきたときには、さすがにキレた。

ファイルがどうのという前に、せめて「再現出来

効果的な報告と思っていても……

[Anonymous Coward]

それは本当にそのファイルが悪かったんじゃなくて？

この説明だと、本当に仕様外のファイルを読ませて仕様外の操作をした結果、仕様外だっつーのっていうエラーが表示されたのを、「エラーだ！」と騒ぎ立ててバグ報告をして、向こうに「だから仕様外だって言ってんだろ！」と呆れられた、というシチュエーションも想像できてしまいます。

バイナリファイルをc

Re:効果的な報告と思っていても……

[Anonymous Coward]

それは本当にそのファイルが悪かったんじゃなくて？

例えて言うなら「Photoshopでデータを読み込んで、ツールパレットのとある機能を選択した瞬間に落ちる」という感じ。

• データの読み込みは正常終了
• 他の機能は使える

という状態。どう考えても、その機能自体にバグがあるとしか考えられなかった。

むしろ余計な推測を挟まれると気分を害する人も居ますし、推測が的外れだった場合にはプログラマに小ばかにされるだけですし。

小ばかにされても結構。それで結果的にこっちの仕事が進むなら。「バグではなく仕様です」と言い切っても構わん。他の手を

Re:効果的な報告と思っていても……

[tix (7637)]

この件で開発者の態度がどうだったかはぼくにはわからないのでコメントしませんが、原因の推測については少し気になったので。

どう考えても、その機能自体にバグがあるとしか考えられなかった。

だとしたら、推測をバグレポートに含めることに害はないかもしれませんが、そうする意味もありませんよね。

バグレポートに原因の推測を含めないも意味がない理由は、

• 明らかでないことは、間違っていて判断の邪魔になるかもしれない
• 明らかなことは書かなくてもわかる

からです。バグレポートに原因の推測を含めないほうがいい理由は、原因の推測を書くことで報告者が安心してしまって、開発者が必要としている情報を書き落とす可能性があるということでしょう。

なので、やっぱりバグレポートはなるべく推測を排除して書いたほうがいいと思います。

// 以前ぼくもとあるソフトウェアに関して、「原因の憶測」を付けたバグレポートを書いてしまったことがありますが、たぶん意味はなかったでしょう。害にならなかったみたいなのでまあよかったですが。

--
鵜呑みにしてみる？

Re:効果的な報告と思っていても……

[Anonymous Coward]

では元ネタのまとめを参考に、自分のバグレポを振り返ってみました。

バグ報告の最初のねらいはプログラマに自分の目で故障を分からせることである。彼らのところに行って失敗するところを見せることができないなら、彼ら自身で失敗させることができるような詳細な指示書を与えよう。

ソフト、ハードのセットアップは彼ら(私がバグレポをした相手)が行ったものです。したがって環境はすべて把握しているはず。基本的にユーザーが環境を変更することは許されていないし、実際していませんでした。そういう環境下で、特定のファイルを読み込み、特定の操作を行うことで確実にフリーズする、という内容でした。

確かに蛇足だったかもしれない推測は、裏で動いてたシェルのコンソールに出力されていたメッセージを全文引用し、その上で自分の考えを書き添えたものです。

最初のねらいがうまくいかなくて、プログラマ自身では失敗が確認できなかったら、バグ報告の次なるねらいは何がおかしくなるのかを記述することだ。全てを詳細に記述しよう。何を見たのか、どうなるべきだと思うのか述べよう。エラーメッセージを書き留めよう。特に数字が含まれているものは。

彼らが確認できたのかどうかすら判りませんでした。これではその先に進めません(藁

ホントに最初のコメントの内容(「お前のファイルが悪い」)としか書いてなかったんですよ。ま、電子会議室上での文字データだけのやり取りの話なので、バグレポの内容がどうの以前にコミュニケーション能力に問題あり(私もその一言で頭に血が上ったんで、多分双方とも)、ということではないかと。

Re:効果的な報告と思っていても……

[wosamu (4952)]

>ソフト、ハードのセットアップは彼ら(私がバグレポをした相手)が行ったものです。したがって環境はすべて把握しているはず。基本的にユーザーが環境を変更することは許されていないし、実際していませんでした。そういう環境下で、特定のファイルを読み込み、特定の操作を行うことで確実にフリーズする、という内容でした。

つまり動作環境に関しては報告しなかった、ということですよね？
こういう～だから～はず（今回だとセットアップしたのは彼らだから動作環境は把握しているはず）みたいなのは報告を聞く側としては嬉しくないでしょうねえ。
異常動作したファイルというのは開発側に提供されたのでしょうか？

>(私もその一言で頭に血が上ったんで、多分双方とも)
なんにしろ短気すぎでは。

Re:効果的な報告と思っていても……

[Anonymous Coward]

行間が読めなかったのなら説明するが、彼らは同じ社内にいる管理者、すなわちrootで、こっちは一般ユーザー、しかも設定変更すら許されていないただのアプリユーザー。

セットアップすべてを行った彼らに、いちいち動作環境を報告する必要があるか？マシン名だけで十分だろ。ファイルを提供したのかって？まさか今時各個人がリムーバブルメディアでデータを持っている、とか思ってる？当然サーバー上のファイル名を教えたが、それじゃ不足だとでも？

俺がムカついたのは、バグレポは俺の本来の仕事じゃないにも関わらず

Re:効果的な報告と思っていても……

[Anonymous Coward]

>多分双方とも

違うと断言してもよいよ（ｗ

Re:効果的な報告と思っていても……

[kaho (2741)]

>バグレポートに原因の推測を含めないも意味がない理由は、
>
>
明らかでないことは、間違っていて判断の邪魔になるかもしれない
>
明らかなことは書かなくてもわかる
>
>からです。

開発者の立場からするとそうなのだろうな、ということは参考になります。

ある実行環境のバグを再現するためにプログラムを書いて報告する際に、バグが
現れたソースから徐々に問題なかった部分を削っていってできるだけシンプルな
ソースにして送ったことがありましたが、その際には完全にピンポイントでは
報告できないが問題なかった部分はこれとこれだからサンプルコードに含まれる
あれかこれに原因があるのではないか、とメールを書いたことがありました。

他にもあるファイルを読み込ませると異常な動作をすることが再現できても
秘密の保守のためなどでそのファイルを渡すことができない場合、推測でも
参考になるだろうと期待して報告することはありましたが、それも邪魔なので
しょうか。反論ではなく開発者の立場から考えたらどうなのだろうと。

--
kaho

Re:効果的な報告と思っていても……

[tix (7637)]

あ。ぼくは開発者ではないので、過度に参考にしないでくださいね。 #99924 [srad.jp] では自信を持った口調で書きすぎました。すみません。ぼくも「そうなのだろうな」というレベルの理解しかしていません。開発者の人の意見が聞きたいですね。

データが秘密のため開発者に渡せないというのは、開発者にとっても報告者にとっても もどかしい状況ですが、そういう状況にどう対処するというノウハウって何かあるのでしょうかね。やっぱり報告者に推測してもらうしかないのでしょうか。

// でも、それができない状況も多々ありそうですし。報告者に正しいバグの原因がわかるというのは、稀な状況のような気がします。

もちろん、報告者が開発者に渡せるような秘密でない（でもちゃんとバグが再現する）テストデータを作ってあげることができれば一番いいのでしょうが。

--
鵜呑みにしてみる？