パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

エンドユーザーからプログラマーに的確に伝わるバグ報告の書き方」記事へのコメント

  • by Anonymous Coward on 2020年11月17日 15時27分 (#3925487)

    エラーが出た。動かない。……それじゃ分からんというの。

    「どの画面でどんな操作をしたら、何が起きた。」とか、
    「エラーメッセージの○○が表示された。」とかなら、まだ調べようがある。
    何が起きていて、何をしたいのか明確に説明して欲しいものです。

    Windowsの場合、必要なデータを可能な限りバックアップして、Windowsをクリーンインストールしなおせなんて回答がよくあって、もめる原因になる。でも、コンポーネントストアや、ユーザープロファイル、システムプロファイルあたりが死んでいると、システムの修復ができないことも多い。

    • by Anonymous Coward on 2020年11月17日 15時48分 (#3925499)

      > 何が起きていて、何をしたいのか明確に説明して欲しいものです。

      それができないから、それを因数分解する人がフロントSEといわれる人なわけです。はい。
      ガチなエンドユーザーは仕事をするためにソフトを使っているだけで、
      ソフト自体には興味ないので、そのソフトの挙動についていろいろと求めるには限界がある。

      親コメント
      • by Anonymous Coward

        >ガチなエンドユーザーは仕事をするためにソフトを使っているだけで、

        もしそうだったとしても
        ・実務上期待される動作(今まで動いていた動作のあらまし)
        ・実際に起こった挙動
        を報告するのは出来ると思うんだよね

        • by Anonymous Coward

          出来たら苦労しないのよ。
          老若男女問わず、情シス経験者でもない限り問い合わせ1回目ではまずその情報は出てこない。
          出てきたら感動して1日は他人のことなのに自慢するレベル。

      • by Anonymous Coward

        ソフトの挙動について求めてはいないんだ。
        あなたの挙動について求めたいんだ。

    • Bit別冊の「GNU Emacsマニュアル」の障害報告の節を読んだときに目から鱗がポロポロ落ちた記憶があります。

      日本語訳はあちこちにありますが、例えば↓
      https://flex.phys.tohoku.ac.jp/texi/emacs-jp/emacs-jp_238.html#SEC263 [tohoku.ac.jp]

      親コメント
      • Emacsは最新版の和訳文書があるので、それを紹介してくれ
        https://ayatakesi.github.io/emacs/27.1/html/Bugs.html [github.io]

        52 バグの報告

        Emacsでバグを見つけたと思ったときは、それを報告してください。それをfixすることは約束できませんし、それがバグであると常に認める訳ではありませんが、もちろんそれについて知りたいのです。追加したいと考える機能についても、同じことが言えます。以下のセクションは、有効なバグレポートを作成する助けとなるでしょう。

        Known Problems  既知の問題とバグについて読む方法。

        Criteria  本当にバグを見つけたのか?

        Understanding Bug Reporting  バグを報告する効果的な方法。

        Checklist  良いバグレポートのために従うべきステップ。

        Sending Patches  GNU Emacsにパッチを送る方法。

        52.3 バグレポートの理解

        バグがあると判断したときは、それを報告すること、そして有用な方法で報告することが重要です。もっとも有用なのは、Emacsを起動するシェルコマンドから、問題が発生するまでに、何のコマンドをタイプしたかの正確な記述です。

        バグレポートのもっとも重要な原理は、事実を報告することです。仮定や口頭の説明は、詳細な生データの代替にはなりません。事実の報告は簡単ですが、多くの人は事実のかわりに仮定の説明をしようと懸命に努め、それを報告するのです。その説明がEmacsが実装されている方法にたいする仮定にもとづく場合、それらは使い道がありません。その一方で事実の欠落により、わたしたちはバグについての実際の情報を得られないでしょう。実際に問題をデバッグして、推定を超える説明を報告したい場合、それは有用です
        — しかし、どうか生の事実も同様に含めてください。

        たとえば、C-x C-f /glorp/baz.ugh
        RET
        とタイプして、ファイルをvisitしたとき、そのファイルが偶然大きい(とあなたは知っている)ファイルで、Emacsが‘I
        feel pretty
        today
        ’と表示したとします。バグレポートにはすべての情報が必要になります。あなたは問題がファイルのサイズにあると仮定して、“大きなファイルをvisitしたら、Emacsが‘I
        feel pretty today
        ’と表示します”、などと報告すべきではありません。これはわたしたちが“推測説明(guessing
        explanations)”と呼ぶものです。ファイル名に‘z’があるという事実が、問題の原因かもしれません。もしそうなら、あなたの報告を受け取ったとき、わたしたちは大きなファイルで問題の再現を試み、それらのファイル名にはおそらく‘z’が含まれておらず、問題を確認できないでしょう。名前に‘z’が含まれるファイルをvisitしてみるべきだと、推測できる方法はありません。

        C-x
        C-f
        のではなく、“ファイルをvisit”とさえ言うべきではありません。同様にテキストを入力する方法では、“その行に3文字あるとき”ではなく、“RET
        A B C RET C-p
        とタイプした後”と書いてください。

        可能なら、すぐにバグを再現するためにemacs -Q(Emacsは初期のカスタマイズなしで開始されます。Initial Optionsを参照してください)でEmacsを呼び出して、バグを発生させるステップを繰り返してみてください。この方法でバグを再現できたら、あなたの個人的なカスタマイズをバグから除外できます。バグレポートは、Emacsをemacs
        -Q
        で開始したことから始まり、バグを再現させる正確な一連のステップを続けるべきです。可能ならバグを再現するのに必要な、正確なファイル内容を報告してください。

        emacs
        -Q
        では再現できないバグもいくつかあります。結局は再現するのが難しいバグもあります。そのような場合、何を行なったかを報告すべきです —
        が、前述したように、どうか最初にバグを発生させた生の事実を固持してください。

        報告したい複数の問題がある場合は、どうかそれらを個別のバグとしてそれぞれ報告してください。

        52.4 バグレポートのためのチェックリストには、レポートに含めるべき事項と、不要な事項がリスト形式でまとめられている。
        https://ayatakesi.github.io/emacs/27.1/html/Checklist.html [github.io]

        親コメント
        • Emacsは最新版の和訳文書があるので、それを紹介してくれ
          https://ayatakesi.github.io/emacs/27.1/html/Bugs.html [github.io]

          情報ありがとうございます。現在まで和訳され続けているとは知りませんでした。ご教示と、そして翻訳をされている方々に感謝します。

          親コメント
        • by Anonymous Coward

          バグ発生前の操作を完全に覚えてるわけないんだから、推測説明以外では報告のしようがない。
          正確な操作ログが欲しいんだったらEmacsで勝手に保存しとけよ。

          バグを修正できない言い訳を並べてるようにしか見えんわ。

          • by Anonymous Coward

            そしてEmacsにキーロガーが仕込まれていたと祭りになるのですね。

      • by Anonymous Coward

        このコメントはただ茶々を入れてるだけなんだが、

        IMEをオフにすることは含めなくてよいのだろーか

    • by Anonymous Coward on 2020年11月17日 16時17分 (#3925512)

      エラーが出た。動かない。……それじゃ分からんというの。

      近年はそうとも言えんのですよ

      マジもんで
      「何もしていないのに壊れた」
      が発生しますので

      ええ、原因は強制自動アップーデートでございます

      # アップグレードしますか はい/後で なんてちゃちなもんじゃねぇ

      親コメント
      • by Anonymous Coward

        # アップグレードしますか はい/後で なんてちゃちなもんじゃねぇ

        コメントアウトにコメントするのはなんだけど、出勤したら画面が黒いままでうんともすんとも言わないって連絡が来るんだよね。
        「ずっとくるくるがまわってる」ってのもある。

    • by Anonymous Coward on 2020年11月17日 19時02分 (#3925636)

      元サポートとしては、「そういうやり取り面倒だから情報収集ツール送ってくれ たらすぐ取るよ」と思ってしまう。
      基本的にエンドユーザは当然ながら、SEの言うことですら頭から信じてしまうと 調査は迷走する。
      表面に出てくる現象は氷山の一角でしかなく、信じられるのはlogのみ!
      なので情報収集ツールの実行をお願いされたら、めんどくさがらずに素直に従っ てくだしあ。

      親コメント
      • by Anonymous Coward

        Microsoft「だからテレメトリーデータを取らせてね。フィードバックHUBで再現データを送れるようにするしね。」

        • by Anonymous Coward

          そして再現しようとすると出ないのはお約束
          #Windowsに限らんけどあるあるネタ

    • by Anonymous Coward

      よくあるのが「エラーが出た。自分は何もしていない」ってやつだな。
      何もしてないわけ無いだろ、と。

    • by Anonymous Coward

      「エラーが発生しました」としかメッセージを出さないソフトウェアもあるからなぁ。
      そうじゃなくてエラーメッセージを書けよって言うからスクリーンショット送ってやったら黙ったわ。

      • by Anonymous Coward

        経験的にはネットワークやファイルI/Oまわりは、エラーメッセージが雑になりがちな印象がある。

        「ネットワークの接続に失敗しました」→ 実際には接続は成功していて、その後の処理でエラー
        「ファイルが見つかりません」→ 実際には存在していて、読み込み権限はあるが書き込み権限がない

        後者は一見「ファイルが存在するのに見つからないと表示される」というエラーハンドリングの問題に簡単に行き着くように思えるが、
        「(ユーザが)別のディレクトリを見ている」という典型的な失敗例が先行してミスリードを起こす。

海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs

処理中...